are willing or eager accelerators of your viral growth.
In both physical and web/mobile channels, earlyvangelists display these common characteristics (see Figure 3.1):
They have a problem or need.
They understand they have a problem.
They’re actively searching for a solution and have a timetable for finding it.
The problem is so painful that they’ve cobbled together an interim solution.
They’ve committed, or can quickly acquire, budget dollars to purchase.
Think of earlyvangelists’ characteristics along a scale of customer pain. Earlyvangelist customers will be found only at the top of the scale—those who have already been looking for a solution, built a home-grown solution (whether in a company by building a software solution or at home by taping together a fork, a light bulb and a vacuum cleaner) and have or can acquire a budget. These people are perfect earlyvangelist candidates. They can be relied on for feedback and initial sales; they’ll tell others about the product and spread the word that the vision is real. Moreover, they can be potential advisory board candidates (more about advisory boards in Chapter 6).
Build a Minimum Viable Product (MVP) First
The idea that a startup builds its product for a small group of initial customers rather than devising a generic mainstream spec is radical. What follows is equally revolutionary.
The goal of the MVP is to build the smallest possible feature set.
On the day the company starts, there is very limited customer input. All the startup has is a vision of what the problem, product and solution seem to be. Unfortunately, it’s either a vision or a hallucination. The company doesn’t know who its initial customers are or what features they’ll want. One option is to start developing an entire full-featured first release of the product, with every feature the founders can think of. We now know this results in wasted engineering effort, time and cash, as customers don’t use, want or need most of the features developed without their input.
Another path is to put Product Development on hold until the Customer Development team can find customers who can provide adequate feedback. The risk here is lost time and no product for customers to provide feedback against. A third, more productive approach is to develop the core features of the product (incrementally and iteratively with agile engineering methods), with the feature list driven by the vision and experience of the company’s founders. This is a minimum viable product.
The goal of customer discovery is to test your understanding of the customer’s problem and see if your proposed solution will prompt him to use or buy the product based on its most important features alone. Most users want finished products, but earlyvangelists are the perfect target for the MVP. Tailor the initial product release to satisfy their needs. If no one thinks your MVP solution is interesting or sufficient, iterate or pivot until an adequate number say “yes.”
The shift in thinking to an incremental and iterative MVP as opposed to a fully featured first product release is important. Engineers tend to make a product bigger and more perfect. The MVP helps them focus the most important and indispensable features. Your goal in having an MVP is not to gather feature requests to change the product or to make the feature set larger. Instead, the goal is to put the MVP in front of customers to find out whether you understood the customer problem well enough to define key elements of the solution. Then you iteratively refine the solution. If, and only if, no customers can be found for the most important features of the MVP, bring customers’ additional feature requests to the product development team. In the Customer Development model, feature requests to an MVP are by exception and iteration rather than by rule. This eliminates the endless list of feature requests that often delay first customer ship and drive product development teams crazy.
Web/mobile businesses conduct customer discovery differently from those in the physical channel. They can reach hundreds or thousands more customers by combining online and face-to-face interactions. They place a greater emphasis on customer acquisition, activation, and referrals. Web/mobile minimum viable products can be developed faster and delivered earlier, accelerating the discovery process. When delivered, they can conduct more tests with customers, with more granular customer-response data. This results in a faster iteration of the problem statement, the proposed solution, and the MVP itself.
For web/mobile startups, here’s how the MVP is used in the discovery process:
Figure 3.2 Developing the Minimum Viable Product for a Web/Mobile Product
Use the Business Model Canvas as The Customer Discovery Scorecard
Often there’s a lack of a shared and clear understanding of the business model throughout the company. This customer discovery step uses Alexander Osterwalder’s business model canvas to diagrammatically illustrate how a company intends to make money. As shown in Figure 3.3 the canvas represents any company in nine boxes, depicting the details of a company’s product, customers, channels, demand creation, revenue models, partners, resources, activities and cost structure. (We described the business model canvas in detail in the Customer Development Manifesto.)
Figure 3.3 Business Model Canvas
In this phase you’ll develop a one- or two-page brief about each of the following boxes in the business model canvas:
Market Size: how big the opportunity is
Value Proposition, Part 1: the product/service, its benefits and minimum viable product
Customer Segments: who the customer is and what problems the product solves
Channels: how the product will be distributed and sold
Customer Relationships: how demand will be created
Value Proposition, Part 2: market-type hypothesis and competitive set/differentiation
Key Resources: suppliers, commodities, or other essential elements of the business
Key Partners: other enterprises essential to success of the business
Revenue Streams: revenue and profit sources and size
When you first draft your initial hypotheses your canvas begins to fill up, looking like Figure 3.4.
