On first description, hearing the “get out of the building and talk to customers” precept of Customer Development leads people to say, “Oh, I get it. Customer Development is all about gathering a list of what features customers want by talking to them, surveying them, or running “focus groups.”
It’s not.
One of the times I screwed this up it left a legacy of 25 years of questionable design in microprocessor architecture.
Little Indians and Big Indians
At MIPS Computers, my second semiconductor company, I was the VP of Marketing and defacto head of Sales. As the engineers were busy rearchitecting the original Stanford MIPS chip into a commercial product, one of my jobs was to find out what features customers wanted. One of the specific requests from our chip architects was to find out whether customers would want the chip to have data stored as big-endian or little-endian.
“Endianness” refers to the byte order of data stored in external memory. Data can be stored with the most significant byte at the lowest memory address – big-endian, or it can be stored with the least significant byte at the lowest memory address – little-endian.
Different computers used different endianness. The leading minicomputer of the day, the DEC VAX, used little-endian, as did microprocessors such as the Intel 8086 (used in the IBM PC) and the Mostek 6502 (used in the Apple II.) On the other hand, the Motorola 68000 microprocessor (used in the Sun and Apollo engineering workstations) and the IBM 360/370 mainframes were big-endian.
The term “endian” came from Jonathan Swift’s Gulliver’s Travels. In it the Lilliputians argue over how they should eat their hard boiled eggs. One group ate from the little end first – little-endians while the other ate theirs from the big end – big-endians. This turned into a dispute over the “right way” and led to war – just like it did for generations of computer architects.
Just Add Every Feature
As I surveyed potential customers on which version of “endiannes” they wanted, prospects who had their data on VAX minicomputers or IBM PC’s were unequivocal. “It has to be little-endian or we won’t design your chip into our systems.” And when I heard from those who had data on Sun or Apollo workstations or IBM mainframes, the answer was equally unambiguous. “It has to be big-endian or we’ll never adopt your microprocessor.” I still remember the day I talked to Ram Banin, the head of engineering of Daisy Systems (a maker of Electronic Design Automation workstations) and he said, “Steve, you’ll never make every potential customer happy. Why don’t you tell your engineers to build both byte-orders into your new chip?”
What a great idea. Now I didn’t have to decide or figure out whether one set of customers was more valuable than the other. I ran back to the company and said customers had told us, “We have to do both little and big endian.” The reaction from the chip circuit design guys was, “OK, we could do that. We can put both little- and big-endian in the chip, and it won’t cost us more than 1,000 gates.” The reaction from our software guys was a little less kind. “Are you out of your !? *x! minds? Do you understand you are doubling the amount of work you are going to make for generations of software engineers?
No, not really. I was just in marketing.
All I had done was proudly go out and get customer input. Isn’t that what I was supposed to do?
No.
Customer Development is about Testing the Founder’s Hypothesis
Any idiot can get outside the building and ask customers what they want, compile a feature list and hand it to engineering. Gathering feature requests from customers is not what marketing should be doing in a startup. And it’s certainly not Customer Development.
In a startup the role of Customer Development is to:
- test the founders hypothesis about the customer problem
- test if the product concept and minimum feature set solve that problem
This is a big idea and worth repeating. Customer Development is about testing the founder’s hypothesis about what constitutes product/market fit with the minimum feature set. Thereby answering the questions, “Does this product/service as spec’d solve a problem or a need customers have?” Is our solution compelling enough that they want to buy it or use it today? You know you have achieved product/market fit when you start getting orders (or users, eyeballs or whatever your criteria for success was in your business model.)
The time to start iterating the product is if and only if sufficient customers tell you your problem hypotheses are incorrect or point out features you missed that would cause them not to buy. If you’re lucky you’ll find this out early in Customer Discovery or if not, when no one buys in Customer Validation.
The Jury is Still Out
At MIPS I was out collecting feature requests.
We put both byte orders into the MIPS chip. It’s been there for 25-years.
Lessons Learned
- Startups begin with hypotheses about a customer problem or need
- Founders talk to customers to discover and validate whether the total solution solves that problem or addresses that need
- If, and not only if, there are no “buy signs” from the customer or customers repeatably point out missing features, does the product change
- Collecting feature lists and holding focus groups are for established companies with existing customers looking to design product line extensions
