In a startup the search for a business model is chaotic, unpredictable and uncertain. Yet the Customer Development process uses a series of checklists to ensure that you walk through the Customer Discovery and Validation steps. In addition it explicitly calls for synchronization and confirmation of the steps by the entire team.
Surely a checklist and discussion gets in the way of progress in a fast moving startup? Here’s how using it helped E.piphany rather than hindered it.
Tell Them What You’re Hearing
When E.piphany was a small struggling startup in Mountain View, we had a weekly Friday afternoon beer and wine fest, no different than what hundreds of other startups were doing. (Insurance companies in the valley should check the accident rates for Friday traffic.) The company headcount was mostly engineers accomplishing the impossible on a regular basis while a few of us were outside the building trying to do what we would call today Customer Discovery and Validation.
A Checklist for Chaos
While all startups are chaotic, we had been through enough of them (E.piphany was my 8th) to realize that we could understand our potential customer better if we had a standard checklist and process of how to approach complex enterprise sales. These started with the business model hypotheses in Customer Discovery (who’s the customer, channel, pricing model, etc.)
Customer Hypothesis Checklist
I remember that for the first few weeks of the company, my partner Ben and I would give the usual rah-rah platitudes about how great things were going to motivate the engineers. Then one week Ben turned to me and said, “Why don’t you really tell them what you’re doing and what you’re hearing.” Uh oh. Thinking about all the ups and downs of sales in a startup and twists and turns in strategy and positioning I wondered if it would be demoralizing. “Do you think they can handle the truth?” We talked about it and realized our motto for our weekly meeting would be, “Don’t panic when we change the strategy. Only panic if we ask you to rearchitect the product.” (Today’s version would be “Don’t worry when we pivot the business model, only panic if we ask you to develop the product with a Waterfall methodology.”)
Sharing the Checklist
Soon after, our Friday’s meetings would start with me describing the highs and lows of the week: who we called on, what they said and what happened (essentially walking engineering through the series of checklists as we went through Customer Discovery and Validation. And what I had to report was mostly us getting a “not interested” or “we don’t get it” from a prospective customer.
Almost immediately the most unexpected things started happening at our Friday meetings.
Don’t Treat Them Like Mushrooms
First, I thought that not pumping up engineering every week would demotivate the team. Reality turned out 180 degrees from what I expected. Engineering was much smarter. When it became clear that my partner and I were not going to treat them like mushrooms (keep them in the dark and feed them sx!t) but let them know what was really going on, they engaged on a much different level.
You’re Explaining it Wrong
Second, as I was reporting on my sales calls a few of the engineers realized that I was describing technical professionals in large companies who were just like them. When I detailed how I was explaining the product, our own engineers said, “You’re explaining it wrong. Even I wouldn’t buy it from us if you told me that.” The first time I heard that I was speechless. Who the hell were these engineers telling me how to market and sell our product? My first instinct was to cycle through all the “my business card says I’m the expert here and you just write code.”
Then I realized – they were right. Our engineers were just like the customer, and if they didn’t think our product description made sense, no one else would. So in front of the entire company, I threw out our positioning and we started to discuss how to better articulate what we were doing. (I think we invented our meta-data architecture diagram that Friday.) It was great to realize that instead of just me trying to figure out customer feedback, that every Friday I’d have the collective wisdom of engineering engaged.
Confirming the Checklist
Synchronizing our Discovery and Validation had a third benefit. Engineering now felt that they had a stake in making the process better and took a great interest in that mysterious and elusive “customer.” Soon engineers were spending lots of time talking to customers. More importantly they had a vested interest in getting the process right.
Synchronizing the Discovery and Validation checklists with the entire company made us collectively smarter, faster and gave us a shared understanding of our objective – build great products that customers wanted.
Checklists and synchronization were part of the reason why we grew from $0 to $125 million in three years.
Lessons Learned
- Customer Discovery and Validation in any type of startup requires a series of checklists (see Appendix B of the Four Steps to the Epiphany)
- The checklists require the team to share their findings for confirmation and synchronization
Listen to the post here: Download the Podcast here
Share this:
Filed under: Business Model versus Business Plan, Customer Development, E.piphany |
Great blog post Steve. I’m on my fourth start up and your blog has become a staple for me to ready every week.
As I grow the new business your posts seem to be very timely and right on the money.
Thanks for sharing your knowledge and I look forward to learning more from your blog.
With more eyes turning to Lean recently, here’s a good read on checklists from the Lean space:
http://www.amazon.com/Checklist-Manifesto-How-Things-Right/dp/0805091742
Also important to note that you may have to create multiple checklists for different types of customers. If you work cross-industry or with small and large businesses, the influencers, the decision makers, and even how you describe the product may change since their needs are different.
A great example of Lean principles in a startup. You’ve use checklists to develop standard work, and presumably you can continuously improve that process.
The story also shows respect for your employees. Rather than seeing them as “mushrooms,” you proved that they are intelligent, capable, and worthy of your respect. I think it’s better to understand the management decision process than to “follow orders” and watch the ship run aground.
Great article!
Harvard Proffessor Youngme Moon advocates not giving customers exactly what they want.
“Take listening to your customers. They will always tell you how to improve, Moon explained, but will never to able to tell you how to be different. And usually what they will tell you about how to improve will be in ways your competitors behave that your customers claim they like. But what you really need to do to stand out from the crowd—as anti-intuitive as it sounds—is don’t give your customers exactly what they say they want. ”
She also says “Youngme’s thesis is that the way businesses are taught to compete is flawed. We’re encouraged to talk to our customers and add the new features they demand. We examine our competitors, figure out where they’re better than us and then we copy them. We find out what our weaknesses are, and fix them. We repeat, repeat, repeat, stuck on a treadmill of incremental innovation as we try to become better, faster, cleaner, cheaper, tastier – whatever it is that our customers tell us they want. The end result is entire product categories (bottled water, shampoo, detergent, cars, beer, operating systems, accounting software) stuffed with thousands of near-identical, micro-differentiated products that nobody can tell apart.”
I will still believe that listening to your customers is the key. The question is this: after receiving feedbacks from the customer, what is the company’s response?
For years, everyone complains about how unstable Windows is and how much the resource it demands. Microsoft is aware of those complains, but their next project just becomes bigger and ever confusing. The majority of computer suppliers (i.e., HP and Dell) all complains about the lack of features and hardware of ipad (i.e., no USB). However, all consumers wanted is a device that is easy to use without all the technical issues. Apple comes ahead of the rest of tech industry because they respond to what customers really want — simple usage and does what it intends to do. In a simple term, consumers want to know the benefits, instead of features … however, the the majority of companies still only focus on the features and ignores what consumers really want …. Of course, it is just my personal opinion.
Biggest complement I can give you, our engineers are quoting your book and pointing us to your website. You are helping us all solve important problems to realize the value from our innovations, thank you.
Hey Steve very good post,
How should this work if you only have an idea? Is it crucial to build a prototype as soon as possible or first try to understand your costumer trough surveys and then build something?
I’m thinking about a product that could have a great future if you can position it in a different way compared to the competitor. Its not a case of pure product development, so I’m wondering if it wouldn’t be better to pospone the prototype a little(!!!) and begin with understanding what people want.
Cheers and keep walking!
I did a google search on “don’t listen to customers” and it produced a lot of interesting reading about why you should not listen to customers when coming up with new product innovations. Famous examples are Apple and Facebook.
Here is an interesting blog post at from a Harvard Professor entitled “What is Customer Opinion Good For”.
http://hbswk.hbs.edu/item/6458.html
Hey John its true,
I read somewhere that Steve Jobs once said “Costumers don’t know what they want”. However I think that this can only be applied to big companies that can market their product. Its is hard for companies that are, in someway, trying to bootstrap themselves make this kind of aprouch, its like going all-in in the first round.
Facebook is a hard case to use as example, because, actually, they took something that existed in a rough way and expanded it first to a small market (college) what didn’t cost much money. Anyway, I think Facebook is an exception and that we should concentrate in what the costumet wants expecially if you are not an internet based venture.
Cheers
[…] En cada reunión semanal de los departamentos de la compañía hablamos de lo que funcionaba y no funcionaba. Y cuando encontrábamos a empleados que acumulaban información o encubian problemas […]
Your post has helped me to identify where I was going wrong. It is important to follow a strategy just like you have displayed. Taking a different approach is important, and taking things in strategic steps.