[Excerpt] Earlyvangelists: The Most Important Customers of All

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 the features 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 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: 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.

In Web/mobile apps, where multi-sided markets (separate users and payers) are often found, earlyvangelists can be users or payers. But even as nonpaying users, these earlyvangelists are willing or eager accelerators of your viral growth.

In both physical and Web/mobile channels, earlyvangelists display these common characteristics:

• 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 homegrown 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.

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.

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.

MVPs for Web/Mobile Are Different

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.

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

In addition to using the business model canvas as a static snapshot of the business at a single moment, frozen in time, Customer Development uses the canvas as a 'scorecard' to track progress in searching for a business model.