This Lean Canvas template turns an original hypothetical idea into a concise startup snapshot. Connect each proposed solution to a problem hypothesis, then choose a question that could change the next build decision.
Identify the customer and the other users
The hypothetical idea concerns club equipment returns. The proposed paying customer is the club coordinator; borrowers would use parts of the workflow.
The early-adopter hypothesis is narrower: coordinators who manually reconcile several loans each week. Shared sheets and manual messages are proposed existing alternatives to investigate, not findings from customer interviews.
Lean Canvas creator Ash Maurya's guide describes a snapshot of assumptions, distinguishes customers from users, and recommends independent team snapshots before reconciliation. It also advises leaving an unsupported unfair advantage blank. This club case is an original example.
Fill all nine blocks without inventing certainty
| Block | Working hypothesis |
|---|---|
| Problem | P1: the coordinator cannot tell which items are overdue. P2: the coordinator does not know whether a reminder reached a borrower. |
| Customer segments | Proposed payer: coordinator. Users: borrowers. Initial focus: coordinators manually reconciling multiple weekly loans. |
| Unique value proposition | Return records that are easy to reconcile before the next club meeting. This is a proposed outcome, not a guarantee. |
| Solution | S1: return-status view for P1. S2: a proposed acknowledgment mechanism for P2. |
| Channels | Begin with direct coordinator conversations; later acquisition approaches remain to investigate. |
| Revenue streams | Subscription hypothesis; willingness to pay and amount unknown. |
| Cost structure | Maintenance and communication-handling costs to investigate; no amounts supplied. |
| Key metrics | Completed loan reconciliations as a proposed outcome measure, rather than number of features built. |
| Unfair advantage | Blank until a defensible advantage can be supported. |
The canvas captures what the team currently thinks. A complete-looking page does not establish that the problems, buyer, or economics are correct.
Check the problem-to-solution link
Select P1 or P2 in the example:
| Problem hypothesis | Proposed response | Question still open |
|---|---|---|
| P1: uncertain overdue status. | S1: a return-status view. | What causes the records and returned equipment to disagree today? |
| P2: uncertain reminder receipt. | S2: an acknowledgment mechanism. | Is knowing receipt important to the coordinator's next action, and how is it handled now? |
S2 is an idea, not a functioning message service. Before designing it, establish whether P2 is an important problem and whether the proposed response would help.
If the team discovers that the records are already accurate but staff cannot access them at the right time, the next solution discussion may change. Keep the question open instead of building every feature in the initial sketch.
Compare independent founder snapshots
Choose Snapshot A to inspect the “more reminders” framing. Choose Snapshot B to inspect the “trustworthy return status” framing. Both are assumptions about the same hypothetical context.
The comparison should retain each snapshot's problem wording, proposed response, and open question. Reconciliation is a discussion about what needs testing, not a vote that makes one account true.
The example also shows “we work hard” as an unsupported advantage claim. Preserve that earlier wording in the comparison, but leave the current advantage field blank. Effort alone does not explain what would make this offer difficult to copy.
Choose the next conversation
The proposed discovery question is:
Describe the last time your records disagreed with the equipment that had actually been returned. How did you find the difference, and what did you do next?
It asks for a concrete account that could illuminate P1. Follow the person's actual process and alternatives. If the person has no such example, record that response instead of persuading them that the problem exists.
The next build decision should use what the team learns. The example has no customer responses, payment evidence, or product-viability score.
Create your own hypothesis snapshot
Create one complete, self-contained HTML Lean Canvas working copy.
Idea and current stage: [DESCRIBE]
Proposed paying customer, users, and early-adopter scope: [PASTE]
One to three problem hypotheses and proposed existing alternatives: [PASTE]
Unique value proposition and minimal solution ideas: [PASTE]
Channels, revenue hypothesis, cost categories, and outcome metrics: [PASTE]
Supported unfair advantage, or leave blank: [PASTE]
Independent team snapshots and disagreements: [PASTE]
Next discovery question and hypothesis it examines: [PASTE]
Show all nine Lean Canvas blocks in an original readable layout and
attribute the method to Ash Maurya. Distinguish payer, user, and early
adopter. Map solution ideas to problems without claiming validation.
Label alternatives as hypotheses unless actual research is supplied.
Let readers inspect problem/solution links and compare independent
snapshots without overwriting either. Keep unsupported advantage claims
in the history and leave the current field blank. Do not invent market
size, customer findings, pricing, traction, or a viability score.
Include a blank canvas and temporary notes. Identify missing customer,
problem, or next-question information before assembling a review.
Preserve notes across views, mark old output stale after edits, and ask
before resetting. No real messaging, payment, storage, or saved research.
Use text of at least 16px, labeled keyboard-accessible controls, and
a layout readable at 360px without horizontal scrolling. Put CSS and
JavaScript inline with no external dependencies. Return complete HTML.
Keep the disagreement visible for the discovery work
Before assigning a build task, have each founder explain what evidence would change their problem framing. Use those differences to prepare the coordinator conversation.
Share the two HTML snapshots through NOS before reconciliation, with the problem wording and next question visible in each. Ask the founders to compare their assumptions before agreeing on the coordinator conversation. Keep both snapshots beside the later discovery notes so the team can see which ideas the actual account supports.