Ash Maurya
Running Lean
The essence of Running Lean can be distilled into three steps: Document your Plan A. Identify the riskiest parts of your plan. Systematically test your plan.
Customers don’t care about your solution. They care about their problems. — Dave McClure, 500 Startups
Stage 1: Problem/Solution Fit Key question: Do I have a problem worth solving?
A problem worth solving boils down to three questions: Is it something customers want? (must-have) Will they pay for it? If not, who will? (viable) Can it be solved? (feasible)
Stage 2: Product/Market Fit Key question: Have I built something people want?
Stage 3: Scale Key question: How do I accelerate growth?
Before product/market fit, the focus of the startup centers on learning and pivots. After product/market fit, the focus shifts toward growth and optimizations.
In a pivot experiment, you attempt to validate parts of the business model hypotheses in order to find a plan that works. In an optimization experiment, you attempt to refine parts of the business model hypotheses in order to accelerate a working plan. The goal of the first is a course correction (or a pivot). The goal of the second is efficiency (or scale).
Even though you may need to raise seed funding sooner, the ideal time to raise your big round of funding is after product/market fit, because at that time,
both you and your investors have aligned goals: to scale the business.
Build-Measure-Learn
With that knowledge, I spent a day building a demo. It was a teaser landing page with a table of contents, a title, and a stock book-cover image
While encouraging, writing a book for just a dozen or so readers wasn’t indicative of a problem worth solving. So I left the teaser page up and announced the book with a “coming this summer” launch time frame on my blog in March 2010. My readers helped spread the message (channel testing). Then I went back to running my company. By June, I had collected 1,000 emails (potential prospects), which made writing the book a problem worth solving for me. My rationale for this was at least covering my costs using a simple back-of-the-envelope calculation.
I took the table of contents and turned it into a slide deck with the same outline and a few bullet points under each topic. I announced a free Running Lean workshop in Austin, Texas and got 30 people interested.
Based on the success of the first workshop, not only did I run more workshops, but I also started charging for them (getting paid is the first form of validation). With each workshop, I continually tweaked the slide deck content for better flow and doubled pricing until I hit some resistance.
Uncertainty: The lack of complete certainty, that is, the existence of more than one possibility. Risk: A state of uncertainty where some of the possibilities involve a loss, catastrophe, or other undesirable outcome.
Devote 20% of your time to setup, 80% to conversation. The stacked flow allows me to pace the conversation and leave all the information on the screen. It usually takes me three to five minutes to walk through my model; then I shut up and listen. I have found that leaving the complete canvas open in front of people always evokes a reaction because people can visualize the entire model and they always have an opinion.
I specifically want to know: What do they consider to be the riskiest aspect of this plan? Have they overcome similar risks? How? How would they go about testing these risks? Are there other people I should speak with?
The Problem team The Problem team is mostly involved with “outside-the-building” activities such as interviewing customers, running
usability tests, and so on. The Solution team The Solution team is mostly involved with “inside-the-building” activities such as writing code, running tests, deploying releases, and so on.
Challenge yourself to find the simplest thing you can do to test a
A formula for crafting a falsifiable hypothesis is: Falsifiable Hypothesis = [Specific Repeatable Action] will [Expected Measurable Outcome]
Stage 1: Understand the problem Conduct formal customer interviews or use other customer observational techniques to understand whether you have a problem worth solving. Who has the problem, what is the top problem, and how is it solved today? Stage 2: Define the solution Armed with knowledge from Stage 1, take a stab at defining the solution, build a demo that helps the customer visualize the solution, and then test it with customers. Will the solution work? Who is the early adopter? Does the pricing model work? Stage 3: Validate qualitatively Build your MVP and then soft-launch it to your early adopters. Do they realize the unique value proposition (UVP)? How will you find enough early adopters to support learning? Are you getting paid? Stage 4: Verify quantitatively Launch your refined product to a larger audience. Have you built something people want? How will you reach customers at scale? Do you have a viable business?
Here is how you view them based on risks: Product risk: Getting the product right First make sure you have a problem worth solving. Then define the smallest possible solution (MVP). Build and validate your MVP at small scale (demonstrate UVP). Then verify it at large scale.
Customer risk: Building a path to customers First identify who has the pain. Then narrow this down to early adopters who really want your product now. It’s OK to start with outbound channels. But gradually build/develop scalable inbound channels — the earlier the better. Market risk: Building a viable business Identify competition through existing alternatives and pick a price for your solution. Test pricing first by measuring what customers say (verbal commitments). Then test pricing by what customers do. Optimize your cost structure to make the business model work.
The pivotal turning point for me occurred when I realized: “Life is too short to keep building something nobody (or not enough people) want.”
Prepare yourself to interview 30 to 60 people. As a rule of thumb, prepare to interview 30 to 60 people over a four- to six-week period, which means talking to two or three customers a day, with some time built in for iteration.
Product risk: What are you solving? (Problem) How do customers rank the top three problems? Market risk: Who is the competition? (Existing Alternatives) How do customers solve these problems today? Customer risk: Who has the pain? (Customer Segments) Is this a viable customer segment?
Customer risk: Who has the pain? (Early Adopters) How do you identify early adopters? Product risk: How will you solve these problems? (Solution) What is the minimum feature set needed to launch? Market risk: What is the pricing model? (Revenue Streams) Will customers pay for a solution? What price will they bear?
You want to build just enough of the solution (or a proxy, like screenshots, a prototype, etc.) that you can put in front of customers for the purpose of measuring their reaction and further defining the requirements for your minimum viable product (MVP).
Content precedes design. Design in the absence of content is not design, it’s decoration. — Jeffrey Zeldman, A List Apart (Happy Cog Studios)
Usually the right price is one the customer accepts, but with a little resistance.
Your MVP should be like a great reduction sauce — concentrated, intense, and flavorful.