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.)
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.
- 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