Running Lean Summary: The Method, Step by Step

Running Lean, by Ash Maurya, is a systematic process for stress-testing a business model before you build it. You capture your riskiest guesses on a one-page Lean Canvas, rank them by what could kill the business first, and then retire that risk through staged customer conversations — moving from problem/solution fit to product/market fit to scale.

Quick Answer: Document Plan A on a Lean Canvas, identify the riskiest assumptions, and systematically test them with customers — problem first, solution second, product last. The goal isn't to defend your idea. It's to find the parts that are wrong while changing them is still cheap.

Why You Document the Business Model Before Building

You document the model first because the most expensive mistake in a startup is building something nobody wants, and a written model is the cheapest way to expose that risk early. Ash Maurya opens Running Lean with a blunt premise — life's too short to build something nobody wants — and the entire method is engineered to prevent exactly that outcome.

Most founders begin with a solution they're excited about and reverse-engineer a business around it. Running Lean inverts that instinct. It asks you to write down your current best guess — "Plan A" — not because Plan A is right, but because a guess you can see is a guess you can test. An unwritten plan hides its own weak points; a written one puts them where you can attack them.

The reframing that makes this work is Maurya's insistence that you love the problem, not your solution. Founders who fall in love with a solution defend it against evidence. Founders anchored to a problem stay free to change the solution as many times as the evidence demands, which is usually more than they expect.

This is also the cleanest distinction between Running Lean and the broader Lean Startup movement it builds on. Eric Ries's The Lean Startup supplies the philosophy — validated learning, build-measure-learn, the pivot. Maurya supplies the operating manual: the specific artifacts, the order to test in, and the interview scripts. If you want the full landscape of foundational reading, our guide to the best lean startup and validation books maps how these titles fit together.

The Running Lean Method at a Glance

The method moves through three stages, each with its own artifact, its own test, and a clear exit gate you must pass before advancing. Skipping a gate doesn't save time — it just relocates the failure to a more expensive moment later.

Here is the arc, from first sketch to a model worth scaling:

The takeaway: each stage answers a different question, in order — does the problem exist, does the solution resonate, does the product deliver, does growth repeat? Testing them out of sequence is the most common way founders waste months, because every stage inherits the noise the previous one was supposed to filter out.

Step 1: Capture Plan A on a Lean Canvas

The Lean Canvas is a one-page snapshot of your entire business model, designed to be filled in minutes and revised as you learn. Maurya adapted it from Alexander Osterwalder's Business Model Canvas, deliberately swapping the four blocks that matter least to an early-stage startup — Key Partners, Key Activities, Key Resources, and Customer Relationships — for four that carry the real risk: Problem, Solution, Key Metrics, and Unfair Advantage.

The nine blocks are Problem, Customer Segments, Unique Value Proposition, Solution, Channels, Revenue Streams, Cost Structure, Key Metrics, and Unfair Advantage. Each is a hypothesis, not a fact. The point of writing them down is not to be right on the first pass — it's to make your assumptions visible and comparable so you can see which ones are load-bearing.

Maurya recommends a specific order of attack rather than filling the boxes left to right, because the blocks depend on each other. For a step-by-step walkthrough of that sequence, see our guide on the order to fill a Lean Canvas. A few disciplines make the exercise honest:

• Sketch it fast. A canvas should take minutes, not a workshop. Perfectionism here is procrastination in disguise.
• Write one canvas per customer segment. Different segments have different problems; blending them hides the differences that matter.
• Treat it as a living document. Date each version. You will revise it repeatedly, and the trail of revisions is a record of what you learned.

The output of this step is not confidence. It's a complete, falsifiable model — a target you now spend the rest of the process trying to disprove.

Step 2: Rank the Riskiest Assumptions First

Once Plan A exists, you rank its assumptions by risk and attack the most dangerous one first, because not all wrong guesses are equally fatal. A mispriced feature is survivable; a problem nobody actually has is not. Maurya's central discipline is to identify what could kill the business soonest and test that before anything else.

The instinct most founders fight is the urge to test what's easy or what they're confident about. That feels productive and proves nothing. The assumptions worth your attention share two traits: they're important (the business fails if they're wrong) and uncertain (you don't yet have evidence either way). The overlap of those two is where you point your first experiments.

For most new products, the riskiest assumption isn't whether you can build the solution — engineers usually can. It's whether the problem is real and painful enough that people will change their behavior to solve it. That's why the method sends you to problem interviews before you write a line of production code. Ranking risk correctly is what makes the whole sequence efficient: you spend your scarce early weeks buying down the risk that would otherwise sink you.

Step 3: Run Problem Interviews, Then Solution Interviews

You retire risk through staged customer conversations, and the staging is the point: problem interviews come before solution interviews, which come before building anything. Each conversation type has a different job, and running them out of order produces confident, useless answers.

Problem interviews test whether the problem on your canvas is real, frequent, and painful — before you show anyone your solution. You ask people to walk you through how they handle the situation today, what they've already tried, and where it hurts. You are listening for existing workarounds and money or time already being spent, because those are behavior, not opinion. Crucially, you do not pitch. The moment you describe your solution, you contaminate the data with politeness.

Solution interviews come only after the problem is confirmed. Now you put a lightweight demo or mockup in front of the same kind of people and watch their reaction to whether this specific approach resonates. You're testing the Unique Value Proposition and the shape of the solution, not the existence of the problem — that's already settled.

The connective discipline across both is to seek disconfirmation, not applause. This is the same principle at the heart of Rob Fitzpatrick's The Mom Test, and it pairs naturally with the broader sequence in our complete guide to startup idea validation. A few rules keep the conversations clean:

• Ask about the past, not the future. "What did you do last time?" beats "Would you use this?" every time.
• Talk less, listen more. Your job is to learn, and you can't learn while you're talking.
• Chase specifics. Vague enthusiasm is noise; a concrete story of a real incident is signal.

Step 4: Advance Through Stage Gates, Not Calendar Dates

You advance from one stage to the next by passing evidence gates, not by hitting arbitrary deadlines, because time spent is not the same as risk retired. Each Running Lean stage has an exit condition, and moving forward before you've met it means building on unvalidated ground.

The three gates are sequential and non-negotiable. Problem/solution fit is reached when you have evidence that a specific segment has the problem and that your proposed solution resonates enough to act on. Only then do you build a minimum viable product. Product/market fit is reached when real users get value from that MVP and keep coming back — retention, not sign-ups, is the proof. Only then do you shift energy to growth. Scale is where you systematically amplify a model that already works.

The reason the gates matter is that each stage optimizes for a different question, and prematurely optimizing for the next one wastes effort. Chasing growth before product/market fit, for instance, just pours traffic into a leaky bucket — you spend money to acquire users who churn because the core value isn't landing yet. The gates keep your effort matched to the risk you've actually cleared.

What the Third Edition Adds: Demo-Sell-Build

The third edition of Running Lean sharpens the method with the Customer Factory model and a demo-sell-build sequence that pushes validation even earlier — you sell the offer before you build the product. Rather than build an MVP and then look for buyers, Maurya argues you should craft a compelling offer, demo it, and secure a real commitment first.

The Customer Factory is Maurya's way of visualizing your business as a system that turns strangers into engaged, paying customers through the pirate-metrics-style stages of acquisition, activation, retention, revenue, and referral. It gives you one connected picture of where customers enter, where they stick, and where they leak, so your experiments target the stage that's actually constraining growth.

Demo-sell-build reorders the classic build-first instinct. A demo is a mock of the outcome, not a working product. Selling it — asking for money, a signed letter of intent, or a genuine commitment — is the strongest possible evidence that demand is real. Only after someone commits do you build, now with a paying customer waiting rather than a hypothetical one imagined. It's the same logic as pre-selling: real commitment beats stated interest, and it surfaces the truth before you've sunk months into code.

Common Ways Founders Misapply Running Lean

The most common failure is treating Running Lean as a checklist to complete rather than a loop of genuine hypothesis-testing, which produces the motions of validation without the learning. Recognizing these traps is cheaper than living through them.

• Interviewing to confirm, not to learn. Founders who want a yes ask leading questions and hear one. The method only works if you're actively hunting for evidence you're wrong.
• Pitching during problem interviews. Describing your solution before confirming the problem replaces data with politeness. Keep the solution holstered until Step 3's solution interviews.
• Filling the canvas once and shelving it. A Lean Canvas that never changes isn't being tested. If your model looks the same after ten customer conversations, you probably weren't listening.
• Skipping to product/market fit. Building an MVP before confirming problem/solution fit is building on a guess. The gates exist precisely to stop this.
• Mistaking sign-ups for retention. Vanity metrics feel like progress. Product/market fit is proven by people coming back, not by people trying it once.
• Testing the easy assumptions. Validating what you're already confident about wastes your scarce early weeks. Attack the riskiest, most uncertain assumption first.

The unifying fix is to stay anchored to the problem and treat every canvas block as a claim you're trying to disprove. A validation workspace like Edmired can keep the canvas, the interview notes, and the evidence organized in one place, but the discipline — test the riskiest thing first, and let evidence move you — is what actually does the work.

Key Takeaways

• Love the problem, not your solution. Running Lean keeps you anchored to a real customer problem so you stay free to change the solution as evidence demands.
• Plan A is a guess made visible. The Lean Canvas exists to expose your riskiest assumptions on one page, not to lock in a plan you defend.
• Rank assumptions by what kills the business soonest. Test the most important and most uncertain guess first; ignore the assumptions you're already confident about.
• Sequence your interviews. Problem interviews confirm the pain before solution interviews test your approach — and both come before you build.
• Advance by evidence gates, not deadlines. Problem/solution fit, then product/market fit, then scale; each gate has an exit condition you must actually meet.
• Demo-sell-build pushes validation earlier. The third edition argues you should secure a real commitment to an offer before building the product behind it.
• Retention proves product/market fit. Sign-ups are vanity; users returning for the core value is the signal that the model works.

Frequently Asked Questions

What is the Running Lean method in simple terms?

Running Lean is a step-by-step process for testing a business model before building it. You document your current plan on a one-page Lean Canvas, identify the assumptions most likely to sink the business, and then test them through staged customer interviews — confirming the problem first, the solution second, and the product last. The aim is to find what's wrong cheaply.

How is Running Lean different from The Lean Startup?

The Lean Startup by Eric Ries provides the philosophy — validated learning, build-measure-learn, and the pivot. Running Lean by Ash Maurya provides the practical operating manual: the Lean Canvas, a specific order for ranking and testing risk, and concrete interview scripts. Ries explains why to work this way; Maurya shows you exactly how, week by week.

What is a Lean Canvas?

A Lean Canvas is a one-page business model with nine blocks: Problem, Customer Segments, Unique Value Proposition, Solution, Channels, Revenue Streams, Cost Structure, Key Metrics, and Unfair Advantage. Ash Maurya adapted it from the Business Model Canvas, replacing the blocks least relevant to startups with Problem, Solution, Key Metrics, and Unfair Advantage. Each block is a hypothesis to test.

What order should you test assumptions in Running Lean?

Test the riskiest, most uncertain assumption first — usually whether the problem is real and painful, not whether you can build the solution. Then move through the stages in order: confirm problem/solution fit through interviews, reach product/market fit with an MVP that retains users, and only then invest in scaling growth. The sequence prevents expensive, out-of-order mistakes.

Do you need to talk to customers to apply Running Lean?

Yes. Customer conversations are the engine of the entire method. Problem interviews confirm the pain exists, solution interviews test whether your approach resonates, and later validation confirms real users get value. You can analyze search demand and competitors alongside them, but direct conversations surface the behavioral evidence — what people actually do, not what they say — that the method depends on.