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
Share this:
Filed under: Customer Development, MIPS Computers |
Steve, I’m working on a consumer internet product concept at the customer discovery phase. I’m hearing a lot of people say, “yes, I believe that would solve the problem and I would use that” (the app is free), which sounds like validation, but I’m concerned that this is what people say and not necessarily what they will do.
I’d like to see more coverage of how to validate problem and product hypotheses in light of non-intuitive situations like the one above. Other such situations might be:
– situations where no one realizes they have a problem e.g. Henry Ford’s alleged “if I listened to what people wanted I would have built a faster horse”
– situations where no one would admit they have a problem: e.g. heavily-advertised pharma products whose mention would surely get the post blocked by your spam filter
– situations where no specific problem exists e.g. pure entertainment products like video games and movies. How could the creators of Titanic or Grand Theft Auto framed their efforts in terms of a problem hypothesis?
Mark, you hit the nail on the head. I was thinking along the same lines and would love to hear Mr. Blank’s opinions regarding these situations.
Mark – thanks for the awesome summary of the grey areas with customer development. I hope Steve takes some time to either address these or outline some additional limitations to customer development and where it may or may not be practical.
Mark, I was thinking the same :
What does CustDev does for “situations where no one realizes they have a problem e.g. Henry Ford’s alleged ‘if I listened to what people wanted I would have built a faster horse’ ”
Thanks to Brent and Deena for underlining it !
Mark,
You’ve just listed the reasons why startups are not done by accountants with spreadsheets. It’s an art.
Customer Development is not a giant focus group. At best it is a way to inform an entrepreneurs instinct and reduce risk.
steve
It isn’t a survey either!
If you were to go back in time and do real Customer Development with these customers, what would that look like? Would you have come up with different requirements for the product, and how would you have sold to customers who saw the product as “wrong-endian” if you only included one byte order?
I’m wondering about this because it’s easy to make the conceptual distinction between deal-breaker feature gaps and nice-to-have feature lists, but especially for a hardware product with a high fixed development cost, it seems very difficult to iterate on an initial attempt at a minimum viable product.
Steve, great that you emphasized this. Many people seem to misunderstand customer development as a total random search through product/idea space guided by feedback from customer development process, whereas I see it more as a search through customer/market space.
[…] Blank gives us a very succinct definition of Customer Development: In a startup the role of Customer Development is […]
Steve, great post. One question: which “endianness” did the founders at this startup expect the chip would have? As a customer developer, you should initially gather founders’ hypotheses, not customers’ feedback. Thanks.
Tiago,
Best as I can recall the founders didn’t have an opinion on “endianness.” So rather than going out and validating their opinion on this and a few other critical technical issues they just outsourced the problem to a clueless marketer. They could have started with the hypothesis they needed both, and then they could have heard customers agreeing, but the next step should have been a “minimum feature set”-“product/market fit” conversation.
We might have ended up implementing both byte orders exactly as we did. But it would have been from a profound set of founders beliefs and a serious discussion of the business tradeoffs rather than a feature list.
steve
[…] Customer Development is Not a Focus Group « Steve Blank (tags: entrepreneurship startups) […]
I really enjoy the approach here. I’m a designer. Problem solving is at the heart of what I do.
I feel kind of douchey quoting Einstein here but it’s appropriate. He once said, “If I had 20 days to solve a problem I would take 19 days to define it”. I couldn’t agree more. I think defining the problem is more important than designing the solution. Without a good understanding of the problem you’re left to make subjective choices that could have &#@!-storm effect on those who end up building the solution, supporting it and using it. No bueno!
Products and services that find traction in the marketplace either feed a need-state very well, ride an unmistakable trend (but a far 2nd) or fall in the “hits-driven” (ex. movies) category. Entrepreneurs with vision essentially make a hypothesis, as Steve says, to fill a need state… and new products and services are born.
The “founders hypothesis” approach reminds me of experiences I’ve had creating and maintaining brands, particularly when trying to articulate value propositions, mission statements or truelines. Only from a solid understanding of the founders reason (hypothesis) for creating the business are these things born. If expressed well they become the motivation that helps employees align their ideas and goals with the organizations reason for being or the customers reason for using the product or service. The outcome of this is work that always adds value to the product or service.
Based on a clear need-state and hypothesis, I wonder what Steve’s example company’s value proposition or trueline would have been and if it would have aligned itself with their end solution?
[…] Customer Development is Not a Focus Group On first description, hearing the “get out of the building and talk to customers” precept of Customer Development […] […]
[…] bands take their built in audience and then branch into their own material. Huh…sounds like customer validation to […]
Not sure you did the wrong thing here–if you’re trying to get project commitments, you really had to support both-endian. And in the end the hardware difference is pretty minor.
That pretty much kills binary compatibility, however, which probably didn’t matter back then, because there were really no operating system ABIs.
in the beginning times for a startup it would be a little difficult I think to figure exactly out which customers we should be going for..
Hmmm. OK, customer development is NOT a focus group. Then WHAT it IS?
[…] is not a focus group: Customer Development is about Testing the Founder’s Hypothesis Any idiot can get outside the […]
[…] reminds us that Customer Development is not just collecting web metrics and it’s not about focus groups. I’ve written before that Customer’s own the pain, Founders own the vision, meaning that […]
[…] gerais para o produto, mas sim provar a visão inicial do empreendedor. Parafraseando Steve Blank, Customer Development não é um Focus Group. Segundo, além de testar a utilização do produto e suas features, o MVP também serve […]
[…] like to explore this more so we’ve taken the core pillars of customer discovery and development and designed our own customer discovery initiative. We’re calling it the Visionary Members […]
I’m a couple of months late discovering this site/post, anyway, excellent stuff.
Is this kind of like having a curve (the founders hypothesis) and then trying to find points (customers) that fit/approximate the curve; add more points and repeat; adjust curve slightly and repeat…
Whereas a focus group is like having a set of points and attempting to do a dot to dot.
Paul,
Hmm… never thought of it that way.
To me in a startup it’s the founders that decide where on the graph they will be searching.
A focus group limits the graph to be searched where existing customers needs are.
steve
Paul, I think your view of cluster of customers as some dots is a well-defined imagination and I think all Steve tells about startups is that even for few of dots i.e. focus groups, the founder hypotheses i.e. the optimized curve fitted on the most of dots remains unwavering.
[…] this article about minimum viable product is a great read for […]
Steve,
I’m a little behind in discovering your site and philosophy. Great work. I have a question about the product/market fit and MVP. I’m currently developing a widget product for e-retailers to make shopping social. I have two customers given the nature of the product. One-the retailers who presumably will pay later:) and secondly the consumers who come and visit the site who use the product. I have proceeded in attempting to find customer/product fit for both of them and it quickly becomes a 2 dimensional matrix losing all lean philosophy with it. In your experience how have you attempted to solve this?
[…] Validate Need for Minimum Viable Product (MVP) – For more visit Steve Blank’s blog. […]
It’s interesting that you mention your software engineers’ reaction to including both endians.
FWIW, the timing of this post, irrespective of my four years late reply, corresponds to about when I decided to stop developing in php in general, and in WordPress (which you seem to use) in particular (and honestly, I’ve written my fair chunk of the latter). So call me biased and somewhat still irritated.
Both of these decisions had everything to do with the mess involved with utf-8 vs utf-16 (both endian varieties) vs plain ASCII. As well as transliteration (which, incidentally, is done in utf-16 with ICU, meaning the debate rages on and you’re very far from the 25-years of questionable design you mention).
If half of what you say is true with respect to your responsibility, I can only say — in spite of how densely good your blog is otherwise — shame on you. Because you made the life of coders a hell in multitudes of programmining languages — in essence, I’ve learned the hard way since, nearly all of them — for more than one generation.