ТОП просматриваемых книг сайта:
The Startup Owner's Manual. Steve Blank
Читать онлайн.Название The Startup Owner's Manual
Год выпуска 0
isbn 9781119690726
Автор произведения Steve Blank
Жанр Экономика
Издательство John Wiley & Sons Limited
Develop the Product for the Few, Not the Many
In existing companies, the goal of traditional product management and marketing is to develop a market-requirements document (MRD) for engineering that contains the sum of all possible customer feature requests, prioritized in a collaborative effort among Product Management, Marketing, Sales, and Engineering. Marketing or Product Management hosts focus groups, analyzes sales data from the field, and looks at customer feature requests and complaints. This information leads to the adding of requested features to the product specification, and the engineering team builds them into the next product release.
While this process is rational for an established company entering an existing market, it’s folly for startups. Why? Startups aren’t small versions of large, existing companies where there’s plenty of customer knowledge and input. In established companies, the MRD process ensures that engineering will build a product that appeals to existing customers in a known market, where customers and their needs are known. On a startup’s first day, there’s limited—if any—customer input for creating a formal product specification.
In a startup, the first product is not designed to satisfy a mainstream customer. No startup can afford to build a product with every feature a mainstream customer needs all at once. The product would take years to get to market and be obsolete by the time it arrived. Instead, successful startups solve this conundrum by focusing development and early selling efforts on a very small group of early customers who have bought into the startup’s vision. These visionary customers will give the company the feedback necessary to add features to the product over time.
Earlyvangelists are willing to make a leap of faith and buy an early product.
Earlyvangelists: The Most Important Customers of All
Enthusiasts who spread the good news about your product to friends, family or co-workers are often called evangelists. But a new word is needed to describe the early adopters—the visionary customers—who buy unfinished and untested products, because they want to be “first,” whether it’s for the sake of gaining a competitive edge or winning bragging rights. We call these early adopters earlyvangelists. Unlike “mainstream” business or consumer-product customers who want to buy a finished, completed, tested product, earlyvangelists are willing to make a leap of faith and buy an early product from a startup. Every industry has a small subset of visionaries willing to take a leap of faith on an early product.
One of the mistakes that startup founders make is to give away or heavily discount early alpha/beta products to blue-chip customers. In single-sided markets (where the user is the payer) earlyvangelists will be happy to pay for early access to the product. If they won’t, they aren’t earlyvangelists. Their willingness to pay is a critical part of the customer discovery process. You’ll use it to test the entire buying process.
Figure 3.1 Earlyvangelist Characteristics
Earlyvangelists 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.