CHAPTER TWO

DEFINING AND TESTING THE STORY

The adoption of lean methodologies has been a huge advance for startups. For decades, countless startups failed after spending too much time on insular product development and too little time “in-market” discovering what their customers want and need. The new model pushes startups into the marketplace much more quickly. In fact, it might push them into the marketplace too quickly without maintaining some real discipline.

Contrary to popular wisdom, I still think that it's valuable to formalize your initial assumptions and hypotheses—and to write them down so you can take them out for a test drive before you spend lots of time and money trying to bring them to life. In this chapter, I'll explain how to more crisply define and test your story out before you start telling it to the world. I wish this school of thought had existed in 1999 and 2000 when we started Return Path. We probably would have saved ourselves a couple of years of our lives and several million dollars in burn if it had.

START OUT BY ADMITTING YOU'RE WRONG

Here is how a major enterprise might tell the story of their upcoming product release: “Our customers, who number x, have y problem, and they will pay z dollars for our solution. This is our plan for rolling that solution out and these are our cost and revenue projections for the next 18 months.”

Here, by contrast, is how a startup should tell its story: “We believe that x potential customers face y problem. Our proposed solution to y problem is solution z at a cost of q dollars—but we're also going to test the effectiveness of solutions a, b, c. Here is our plan for testing that hypothesis.”

A mature enterprise might tell its story in an 80-page document with multiple appendices, while a startup might tell its story on a single page or in fewer than a dozen slides. However, as significant as those differences in format are, the real difference is in the nature of the assumptions. To put it bluntly: traditional business plans assume that their assumptions are correct, and startup business plans assume that their assumptions are probably wrong.

As an entrepreneur, the story you start with is probably wrong. But until you start testing your underlying hypotheses, you don't know how you're wrong. Unlike enterprise managers, you don't have the luxury of decades of data from comparable initiatives or huge pools of resources from which you can draw. You're creating a new product or market, rather than placing a new product into a mature market. If you spend months in planning and development before sending your product into the market, the result could easily be a swing and a miss. Of course, if you go out to market a lot more quickly, the result could still be a swing and a miss, but you won't have burned through all your resources before your first at-bat.

That is the insight behind the agile and lean methodologies championed by Silicon Valley thought leaders like Eric Ries and Steven Gary Blank: the failure of early startup initiatives is predictable, so that failure should be built into the process rather than treated as a crisis when it happens. My only concern is that the past few years have led to an overcorrection. It's true: the first story you tell about your startup will probably be wrong. The problem is that many entrepreneurs have taken that as license to start with any old guess that occurs to them. Luckily, there's a middle ground: a process of formalizing and communicating hypotheses that doesn't take months of work and lead to hundreds of spreadsheets—and one that allows considerable flexibility in execution.

A LEAN BUSINESS PLAN TEMPLATE

The goal of a lean business planning process should be to produce three outputs. First is a single slide that you'll use to define your business model and your underlying hypotheses. Second is a short presentation for partners and investors. Third is your mission, vision, and values statement. Here, I'm going to focus on the first output: the internal slide.

My favorite template for startup business plans is the “Lean Canvas” that Ash Maurya presents in his book Running Lean. If you're really at the pure startup stage, it's worth reading the whole book, but one notable line from the book is, “your job isn't just building the best solution, but owning the entire business model and making all the pieces fit … the bigger risk for most startups is building something nobody wants.”

Maurya's Lean Canvas business plan is shown in Figure 1.1 and it's a simple road map to, as he says in the book, “systematically de-risk” each element of your business model. While the Lean Canvas uses some of the same criteria that I noted that I use above for vetting ideas, it's the place where you start to document the specifics of those criteria so you can go out and test the things that must be true in order for your business model to work.

Following is a section-by-section guide to test what must be true in each of the nine boxes of Maurya's Lean Canvas.

Problem

What problem are you trying to solve, and for whom? In Steve Blank's “Customer Development” model, defining your audience and your product come concurrently as you build a minimum viable product (MVP). Your solution needs to address a specific problem or pain point that affects a well-defined audience. You don't want to develop “a solution in search of a problem” (see sidebar). The assumption you're trying to test in this box on the Lean Canvas is that this type of person has this exact problem.

FIGURE 2.1 Maurya's Lean Canvas Business Plan

Solution

You can only describe your solution after defining your audience and their problems. This might seem a little backwards, but it insures against the danger of putting solutions ahead of problems and declaring that “everybody” will need what you have to offer, rather than forcing yourself to decide exactly who will buy what you're selling, and for how much. The assumption you're trying to test in this box on the Lean Canvas is that this exact solution is what solves the problem for the audience specified in the prior box.

Key Metrics

How are you going to test your hypotheses? What would need to happen to prove them right or to disprove them? Remember: revenue is a lagging metric of success. You need to define metrics further up the sales funnel—lead generation, sign-ups, and so on—or your data will come in too late. What you're trying to outline in this box on the Lean Canvas is the short list of metrics you will need to track up front to tell if your solution is taking root with your target audience.

Unique Value Proposition and Unfair Advantage

The idea is only one part of the story. Your story needs to encompass much more, including your team. What is the unique value of your solution? Marginal improvements usually aren't enough to base a startup on. What's the radical improvement that you're offering? And what advantage does your team offer?

Who else is competing in this space? How similar do their solutions look to what you're offering? What is your competitive advantage or your solution's unique value proposition? If you're offering only a marginal improvement over a well-established competitor, it's going to be much harder to get traction in the marketplace. Either innovate in a field without much competition— like the email deliverability business Return Path started working on 10 years ago when no one was focused on that value proposition—or offer such a large improvement over the competition that it essentially changes the nature of the game.

The assumption you're trying to test in this box on the Lean Canvas is a very honest assessment of your place within the competitive ecosystem in which you plan to operate.

Channels

In my view, this is probably the most important box on the Lean Canvas to test, because it's where the rubber meets the road—the go-to-market plan. How are you going to sell to your customers? (Or, as Ash Maurya asks in Running Lean, “what are your paths to customers?”) Are you going to engage in direct sales via e-commerce? Act as a technology provider and leverage another organization's sales force? Or are you running a business-to-consumer (B2C) business with a freemium model that depends on organic user growth? Whatever the answer (or hypothesis), state it here. The assumption you're trying to test in this box on the Lean Canvas is fundamentally how you will reach customers and derive revenue.

Customer Segments

When articulating the audience (or audiences) for your solution, be as specific as possible. While a strategic plan should certainly be aspirational, it can't be unrealistic. For whom is your solution a “need to have” rather than a “nice to have”? Is that audience large enough to build a business around? The critical item to get right here is the problem you're solving, and you can be quite vivid in your description of your archetypal customer and use case.

Customer segmentation not only helps you define your target audience, it also starts you on the road to quantifying your total addressable market (TAM), which is a critical element of your Lean Canvas to test. How many of your target customers are out there? How much do you think they'll pay for your solution? That's the beginning of your TAM. But if your TAM is $1 billion and there are four companies going after it, you are unlikely to see $1 billion in revenue any time soon.

Pay careful attention to indirect competitors or substitute products. These will eat away at the TAM, even if you don't think of them as a competitor. For example, if you were starting an airline running between New York and Washington, D.C., you'd look at Amtrak as a substitute product even though it's not an airline.

Cost Structure and Revenue Streams

The financial part of the Lean Canvas isn't about creating a profit-and-loss statement (P&L). It isn't about convincing someone to invest in your business. It's helping you articulate what the basic numbers will or should look like on your path from idea to functional prototype, or MVP.

On the revenue side, pull from your customer segmentation or TAM data. To prove out that you have a viable solution, how many customers do you expect to pay what price for your product? On the cost side, how many people will be working on the solution at what price, for how many weeks or months? What are your hosting or other technology costs to get to MVP?

With your hypotheses laid out, it's time to go test them. Hit them hard. Again, there's much more detail in Ash Maurya's Running Lean, but his test methodologies revolve around problem interviews (is there really a problem?) and solution interviews (if I build it, will you pay for it?).

This all may seem like an extraordinary investment for the sake of a single page, but consider what it gives you: a clear statement of your current hypotheses in a format that's easily testable. It brings everybody who is part of your founding team into alignment around the same goal: proving, or disproving, your business hypotheses, and responding to the results.