Lean Canvas

Testing Product Assumptions

The Lean Canvas is a one-page model for making the riskiest assumptions behind a product visible, testable, and easy to change. It is useful before a team commits to a roadmap, architecture, or sizeable budget.

It is not a business plan and it is not a promise of what will happen. Treat each statement as a hypothesis that needs evidence.

The nine blocks

The order matters less than the conversation. Start with the customer and the problem, then work towards a solution. A technically elegant solution to a weak problem is still a weak product.

How to fill it in

1. Name a narrow customer segment

Avoid starting with “any business” or “all engineering teams”. Choose a group with a shared context, a recognisable trigger, and enough access for you to speak with them. Separate the user from the economic buyer where they are different.

2. Write the top one to three problems

Describe the outcome the customer is struggling to achieve, not the feature they requested. Rank the problems by urgency and frequency. Include how customers solve them today: spreadsheets, manual work, internal tools, or a competing product.

3. Make the value proposition specific

Use a simple pattern:

Help [specific customer] achieve [valuable outcome] without [important trade-off].

The value proposition should be understandable without a product demo. If it needs a long explanation, the segment or problem is probably too broad.

4. Propose the smallest solution

Describe capabilities, not a six-month feature list. Tie every proposed capability to a named problem. Keep uncertain details out of the canvas until customer evidence justifies them.

5. Add the route to customers

List plausible channels such as founder-led sales, partners, communities, content, or an existing product. A channel is an assumption too. A product that customers cannot discover or buy has no useful distribution strategy.

6. Define economics and metrics

Estimate the main costs and the event that represents delivered value. Useful early metrics are often behavioural: activation, repeated use, time to first value, conversion, retention, or a paid commitment. Avoid vanity metrics such as registrations without a meaningful follow-on action.

7. Be honest about unfair advantage

“Great team”, “first mover”, and “we will work hard” are not durable advantages. Possible examples include proprietary data, trusted distribution, a hard-to-recreate network, deep domain access, or a compounding learning loop. It is fine to leave this block blank while the product is young.

Worked example: an engineering dependency service

Imagine a team considering a service that helps engineering organisations understand ownership and risk across their software dependencies.

The canvas does not prove that this product should be built. It identifies what to investigate first: whether the problem is painful enough, whether the data can be connected safely, and whether customers will pay for the outcome.

Use it as a decision instrument

For a CTO, the most valuable output is not a polished canvas. It is a shared view of the assumptions that could invalidate the investment.

Use the canvas to:

• align product, engineering, sales, and finance on the same hypothesis;
• expose dependencies between customer demand, technical feasibility, and economics;
• choose the next evidence-gathering experiment;
• revisit the model when customer behaviour or market conditions change; and
• decide whether to build, buy, partner, or stop.

Keep a short evidence note beside each high-risk block. Record what was assumed, what was observed, and what changed. That turns the canvas from a workshop artefact into a living decision record.

Common mistakes

• Filling every box with certainty. Early canvases should contain explicit hypotheses, not invented precision.
• Starting with the solution. A feature list can hide the absence of a painful customer problem.
• Serving too many segments. Different segments often have different problems, buyers, channels, and economics.
• Ignoring existing alternatives. The real competitor may be a manual workaround or the decision to do nothing.
• Choosing metrics after launch. Define the behaviour that would count as value before building the measurement system.
• Treating the canvas as static. Update it when evidence changes; the ability to change direction is the point.

Downloads

Explore Next

• Build vs. Buy Decision Framework — A framework for deciding which capabilities should be built in-house.
• Budget Breakdown — A practical view of the cost structure behind technical work.

References

• Lean Canvas template — The original Lean Canvas template from LEANSTACK.
• Ash Maurya — The creator of Lean Canvas and author of Running Lean.