Lean Canvas: how to fill in every block, with an example

The Lean Canvas is a one-page business model template created by Ash Maurya and published in his book Running Lean (2010). He adapted it from Alexander Osterwalder's Business Model Canvas, swapping four boxes that describe an established company for four that describe a risky new idea: Problem, Solution, Key Metrics and Unfair Advantage. (Lean Canvas is a trademark of LEANSTACK. GrowthApp has no affiliation with them; we use the format because it works.)

The important word is assumptions. A business plan tries to be right. A Lean Canvas tries to be testable. Each box is a guess about who your customer is, what they struggle with, and why they would pay you, written down so that you can go and check it. When a box turns out to be wrong, you change it. Nobody grades the first draft.

That is why a Lean Canvas takes an afternoon, not a month. The time goes into the testing that follows, which is what the second half of this guide is about.

The standard layout has nine boxes. Three of them carry a smaller sub-box, which brings the count to twelve: Existing Alternatives sits inside Problem, Early Adopters inside Customer Segments, and High-Level Concept inside Unique Value Proposition. The right-hand side is about the market (customers, channels, revenue) and the left-hand side is about the product (problem, solution, metrics, cost). The Unique Value Proposition sits in the middle because it is the promise that connects the two.

Each box below links to its section.

The boxes are numbered because the order matters. Start on the right with the customer, then move left to the problem that customer has, then to a solution for that problem. Each answer depends on the one before it:

• Change the customer and the problem changes. Restaurant owners and restaurant staff do not share a scheduling problem; they have opposite ones.
• Change the problem and the solution changes. If the real pain is no-shows rather than the hours spent building the rota, you build an approval flow, not a faster spreadsheet.
• Change the solution and the channels, the revenue and the metrics all move with it.

This is why the advice is always "fall in love with the problem, not the solution". A founder who starts from the solution fills in the other boxes to justify it, and the canvas becomes a pitch rather than a set of hypotheses.

If you already have a solution in mind, that is fine. Write it in the Solution box, then cover it up and fill in the customer and the problem as honestly as you can. If the solution still fits when you uncover it, good. If it does not, you have just saved yourself months.

What goes in it. The specific group of people or businesses you are building for. Not a market ("restaurants"), a segment: who they are, how big they are, what they already do, what they can pay. You should be able to picture one person.

The common mistake. Describing the customer so broadly that nobody is excluded. "Small businesses" or "anyone who cooks at home" is not a segment, it is an audience, and you cannot interview an audience. Narrow is not a limitation at this stage; it is what makes every later box answerable.

Questions to ask yourself. Can you describe one specific person who is your ideal customer? Where do these people gather, online or offline? Do they have the money and the authority to pay?

Rota Kitchen's answer:

Owner-operators of independent restaurants with 8–30 staff, most of them part-time.

• Not chains: they already have workforce software from head office.
• The owner builds the schedule personally, usually on Sunday night.

Notice what the two bullet points do: they say who is out (chains) and name a behaviour (builds the schedule personally) that you could check by asking.

How you would test it. Go and find ten of them. If you cannot find ten people who match the description, the segment is either wrong or too narrow to build on. If you can, ask each one what they did last week about the problem you think they have. Their answers fill in the next three boxes.

What goes in it. The slice of your customer segment that has the problem worst and is already trying to solve it. They are the people who will put up with a rough first version because the alternative is worse. Every segment has them; the box asks you to name what marks them out.

The common mistake. Treating early adopters as "the enthusiastic ones" or "people who like new apps". Enthusiasm is not the signal. The signal is that they have already spent money, time or effort on a workaround. Someone who has done nothing about the problem is not an early adopter, however friendly they are in an interview.

Questions to ask yourself. Who needs this most urgently? Who is most frustrated with what they use today? Who has already tried to fix it themselves?

Rota Kitchen's answer:

Owners who already moved the schedule off paper into a spreadsheet or a group chat and complain about it.

11 of the 14 owners we interviewed fit this. They are the ones who said "I'd pay to never do this on WhatsApp again."

How you would test it. Count. Out of the customers you interviewed, how many match the early-adopter description, and how many of those said something unprompted about wanting a fix? Rota Kitchen's "11 of 14" is a real piece of evidence. "Lots of owners are frustrated" is not.

What goes in it. The one to three problems your customer segment has, in order of severity. Problems, not features: "the owner finds out about a shift swap when someone doesn't show up" is a problem; "no approval workflow" is a feature described from the wrong end.

The common mistake. Writing down the problem you would like customers to have because your solution fixes it. The test is simple: could you have written this box before you had any solution in mind? If it reads like a brochure, start again from what customers told you.

Questions to ask yourself. Is this a must-have or a nice-to-have? What do customers do about it today? What does it cost them to leave it unsolved?

Rota Kitchen's answer:

1. Last-minute shift swaps happen in a group chat, and the owner finds out when someone does not show up.
2. Building next week's schedule takes 2–4 hours every week.
3. Nobody can see who is qualified for which station.

Evidence: 12 of 14 interviewees named no-shows after a swap as their top scheduling pain. Hours spent is self-reported, so treat it as a ceiling.

The last line is the one to copy. It records where the number came from and how much to trust it.

How you would test it. Customer interviews, before you build anything. Ask people to tell you about the last time the problem happened, not whether they "have" it. Then rank: which problem came up first and most often? A problem that only surfaces when you prompt for it is not your top problem. GrowthApp's interview module exists for exactly this step: you upload the recording and get the findings summarised beside your canvas, so the Problem box is built from what people said rather than from what you remember them saying.

What goes in it. How your customers deal with the problem right now. Direct competitors belong here, but so do spreadsheets, group chats, a cousin who helps out, and doing nothing. "Doing nothing" is usually your biggest competitor.

The common mistake. Listing the well-funded competitor you are afraid of and leaving out the workaround your customers actually use. Your real alternative is whatever the customer would keep doing if you did not exist, and it is rarely a startup.

Questions to ask yourself. Why might customers stick with what they have? What would it cost them to switch? What do you do that the alternative cannot?

Rota Kitchen's answer:

• Group chat plus a photo of the paper schedule
• Spreadsheet shared with managers
• Enterprise workforce suites (too expensive and built for chains)

How you would test it. You get this box free from the same interviews: every time someone describes the last time the problem happened, ask what they did about it. Then try the alternatives yourself. Building a schedule in a spreadsheet for an hour teaches you more about the competition than a week of reading feature pages.

What goes in it. The smallest set of features that addresses each problem in box 3, one line per problem. It is deliberately a small box. Ash Maurya's point is that the solution is the least important box to get right early, because it will change as you learn.

The common mistake. Writing the whole product. Three problems, three lines. If a feature does not map to a problem you wrote down, it does not belong here yet, however good it is.

Questions to ask yourself. Does each line solve a stated problem? Can you build it with what you have? Is it the simplest version that would work?

Rota Kitchen's answer:

• A weekly schedule the owner builds from last week's template in minutes
• Swap requests that need owner approval and check station qualifications
• Staff see their shifts in a simple mobile view — no app store install

Line by line, those match problems 2, 1 and 3.

How you would test it. Show, don't describe. A clickable prototype, a mock-up, even a paper sketch put in front of the people you interviewed. Watch whether they reach for it. Rota Kitchen tested a prototype with nine owners before writing a line of production code; what those owners said about the swap-approval flow is what promoted it to the bold line.

What goes in it. A single clear sentence that says why you are different and worth paying attention to, written in the customer's words. It should promise an outcome, not list features. It goes in the middle of the canvas because it is the bridge between the problem side and the customer side.

The common mistake. Jargon. "AI-powered workforce optimisation for the hospitality vertical" is a sentence no restaurant owner has ever said. If your value proposition would not survive being read aloud to a customer, rewrite it in the words they used in the interviews.

Questions to ask yourself. Can a customer understand it in five seconds? Does it say how you are different from the alternatives in box 4? Does it promise something specific?

Rota Kitchen's answer:

Know who is actually coming in tomorrow. Swaps go through you, not the group chat.

It names the outcome (knowing who is coming in) and the alternative it replaces (the group chat), in nine words.

How you would test it. Put it at the top of a landing page, or simply say it out loud at the start of your next five interviews, and watch faces. The test is not "do they like it" but "do they ask a follow-up question". Silence and a polite nod mean rewrite.

What goes in it. A short analogy that lets someone grasp the idea in a breath: "X for Y", or a comparison to something they already know. It sits inside the Unique Value Proposition box and exists mostly for the conversations you have before anyone reads the canvas.

The common mistake. Reaching for the most famous company you can think of ("Uber for restaurants") when the comparison sets the wrong expectation. The analogy has to be accurate, not flattering, and it has to be one your particular audience will recognise.

Questions to ask yourself. Does the analogy actually describe your model? Will the person you are talking to know the reference? Does it set the right expectation about size and shape?

Rota Kitchen's answer:

"The group chat, but the owner has the final say."

No famous company at all. It uses the thing every owner already has (the group chat) and states the one difference.

How you would test it. Say it to someone outside the industry and ask them to explain your business back to you. If what comes back is roughly right, keep it.

What goes in it. Something a competitor cannot easily copy or buy: insider knowledge, an existing audience, a partnership nobody else can get, network effects that get stronger with every customer. Ash Maurya's definition is strict, and most early canvases should leave this box thin or honestly weak.

The common mistake. Filling it with things that are merely a head start. Being first, working hard, having a nice design and being passionate are not unfair advantages; a competitor with money can match all four in a quarter. Pretending otherwise on the canvas hides the real risk from you.

Questions to ask yourself. Could a competitor replicate this with money? Does it grow stronger over time? Does it matter to the customer's decision?

Rota Kitchen's answer:

Still weak. Our co-founder ran a 40-seat restaurant for six years, which gets us into owner conversations fast. That is access, not a moat yet.

This is the box most worth copying from the example: it admits what it has (access) and what it lacks (a moat), which is what an honest canvas looks like.

How you would test it. Ask yourself what would happen if a well-funded competitor launched next month. Whatever survives that question is your unfair advantage. If nothing does, write that down and keep going; plenty of good businesses earn their moat later, from the customers they get first.

What goes in it. The paths by which you will reach your customers, from first hearing about you to buying. Free and paid, direct and through partners. Concrete channels you could start on this month, not categories like "social media".

The common mistake. "Word of mouth" and "content marketing" written down because they are free. Word of mouth is what happens after a channel works; it is not a channel you can start. The Channels box is a plan for the first hundred customers, not the first hundred thousand.

Questions to ask yourself. Where do these customers already look for solutions? What does one customer cost through each channel? Which channel can you test next week?

Rota Kitchen's answer:

• Local restaurant associations (two have agreed to a demo slot)
• Food distributors' sales reps, who visit every owner weekly
• Referral from owners in the pilot

Two of the three are specific to how restaurant owners actually get reached, and one already has a small commitment behind it.

How you would test it. Run each channel once, small, and count what comes out. One association demo slot, one distributor rep who agrees to mention you, one week of ads with a fixed budget. A channel that produces nothing at small scale rarely produces something at large scale.

What goes in it. The three to five numbers that tell you whether the business is working, chosen so that a change in the number would change what you do next. Ash Maurya suggests thinking in terms of the customer's journey: how many people acquire, activate, keep coming back, pay, and refer.

The common mistake. Vanity metrics: sign-ups, followers, page views. They go up and to the right and tell you nothing. A key metric is one you would be worried about if it stopped moving.

Questions to ask yourself. Does this number predict success or just describe activity? Can you influence it directly? How often would you measure it?

Rota Kitchen's answer:

• Weekly active schedules published
• Swap requests approved through the app (vs. chat)
• No-shows reported by owners per month

The second metric is the clever one: it measures whether the product has replaced the group chat, which is the whole value proposition.

How you would test it. Measure the metric before you have a product. Rota Kitchen can ask pilot owners today how many swaps happened in the chat last week and how many no-shows they had last month. That gives you the baseline the product has to beat.

What goes in it. What it costs to run the business at this stage: people, tools, hosting, the cost of getting a customer. Fixed and variable costs separately, so you know which ones grow with every customer.

The common mistake. Modelling the costs of a company you do not yet have. A three-year staffing plan belongs in a financial forecast, later. The canvas wants the burn rate for the next few months and the cost to serve one customer.

Questions to ask yourself. What is your monthly burn at this stage? Which costs are essential? Which costs go up with every customer, and which do not?

Rota Kitchen's answer:

• Two founders (unpaid until month 6)
• Hosting and SMS notifications
• One part-time developer from month 4

How you would test it. Get a real quote for each line. Hosting and SMS prices are public; a part-time developer has a day rate. If a cost line cannot be turned into a number with a source, it is a guess, and it should say so.

What goes in it. How you get paid: the pricing model, the price, and who pays. Subscription, per-transaction, one-off, licence. One model to start with, even if you can imagine three.

The common mistake. Leaving the price blank "until we know more", or picking one nobody has reacted to. A price is a hypothesis like every other box, and it is one of the cheapest to test. Guessing at it after launch is far more expensive than asking about it before.

Questions to ask yourself. What do customers already pay for the alternatives? Is the model simple enough to explain in one sentence? How predictable is the revenue?

Rota Kitchen's answer:

Monthly subscription per restaurant: $39/month, first month free. Tested price with 9 owners — 6 said yes at $39, 2 at $25, 1 no.

How you would test it. Do what they did: name a number in the interview and watch the reaction. Nine conversations produced a price, a rejection rate and a hint about a lower tier. That is more pricing research than most businesses do before they launch.

Here is the whole canvas in one place. Rota Kitchen is fictional: the company, the founders, the interviews and every number were written for GrowthApp's sample program dashboard, where you can see the same canvas inside the product. It is written the way a real one should read after a month of validation work.

Customer Segments. Owner-operators of independent restaurants with 8–30 staff, most of them part-time. Not chains: they already have workforce software from head office. The owner builds the schedule personally, usually on Sunday night.

Early Adopters. Owners who already moved the schedule off paper into a spreadsheet or a group chat and complain about it. 11 of the 14 owners interviewed fit this.

Problem. (1) Last-minute shift swaps happen in a group chat, and the owner finds out when someone does not show up. (2) Building next week's schedule takes 2–4 hours every week. (3) Nobody can see who is qualified for which station. Evidence: 12 of 14 interviewees named no-shows after a swap as their top scheduling pain.

Existing Alternatives. Group chat plus a photo of the paper schedule; a spreadsheet shared with managers; enterprise workforce suites, too expensive and built for chains.

Solution. A weekly schedule built from last week's template in minutes; swap requests that need owner approval and check station qualifications; a simple mobile view for staff with no app store install.

Unique Value Proposition. Know who is actually coming in tomorrow. Swaps go through you, not the group chat.

High-Level Concept. "The group chat, but the owner has the final say."

Unfair Advantage. Still weak. A co-founder ran a 40-seat restaurant for six years, which gets the team into owner conversations fast. That is access, not a moat yet.

Channels. Local restaurant associations (two have agreed to a demo slot); food distributors' sales reps, who visit every owner weekly; referrals from owners in the pilot.

Key Metrics. Weekly active schedules published; swap requests approved through the app rather than the chat; no-shows reported by owners per month.

Cost Structure. Two founders, unpaid until month 6; hosting and SMS notifications; one part-time developer from month 4.

Revenue Streams. Monthly subscription per restaurant at $39, first month free. Tested with 9 owners: 6 said yes at $39, 2 at $25, 1 no.

What makes this a good canvas is not that the idea is good. It is that almost every box says where its claim came from and how sure the team is. That is what lets them decide what to test next.

A finished canvas is a list of guesses in a tidy grid. The work that matters starts now, and it goes in the same order the canvas did.

1. Talk to customers before anything else. Interview people who match your Customer Segments box. Ask about the last time the problem happened, what they did, and what it cost them. Do not pitch. Ten conversations will change at least two boxes; that is the point, not a failure.

2. Decide what counts as evidence. Before each round of interviews, write down what you would need to hear to keep a box as it is. "12 of 14 named no-shows as their top pain" is evidence. "Everyone seemed to like it" is not. Being specific in advance is the only defence against hearing what you hoped to hear.

3. Research more, pivot, or proceed. After each round, look at the boxes you tested and ask one question: does the evidence support what is written there? Three answers are possible. Research more if you still do not know. Pivot if the answer is no: change the customer, the problem or the solution, and run the chain again from that box. Proceed if the answer is yes, and move to the next assumption. A pivot is not the canvas failing; it is the canvas doing its job cheaply, before you built anything.

4. Then size the market and price it. Once the customer and the problem hold up, the right-hand side of the canvas is worth the effort: how many of these customers exist, what they will pay, and how you will reach them. Doing this first, before you know the customer is real, produces confident numbers about nobody. Rota Kitchen's own market sizing, with real sources, is the worked example in our TAM, SAM and SOM guide.

In GrowthApp this loop is built into the steps. The Lean Canvas fills itself in as you work through customer, problem and solution, one module at a time. Interviews are uploaded and summarised beside the canvas. At the end of each discovery step a Confidence Check asks you to look at your evidence and choose: research more, pivot, or proceed. It is a prompt to think, not a score the app gives you. The AI assistant suggests improvements beside your text, and you accept, merge or reject each one; it never writes the canvas for you, because a canvas nobody thought about has validated nothing.

The two canvases share the same nine-box grid and five of the boxes: Customer Segments, Value Proposition, Channels, Revenue Streams and Cost Structure. The difference is the other four.

The Business Model Canvas (Alexander Osterwalder, 2008) has Key Partners, Key Activities, Key Resources and Customer Relationships. Those describe how an organisation operates. They are the right questions for a company that already has customers and wants to understand or redesign its model.

The Lean Canvas (Ash Maurya, 2010) replaces them with Problem, Solution, Key Metrics and Unfair Advantage, and adds the Existing Alternatives, Early Adopters and High-Level Concept sub-boxes. Those describe risk. They are the right questions when the business does not exist yet and the biggest danger is building something nobody wants.

When each fits.

• A new idea, a founder, a student team, a first product: start with the Lean Canvas. Its boxes are the assumptions most likely to be wrong, in the order most likely to hurt.
• An existing business, a corporate innovation team, a course or investor that asks for it: use the Business Model Canvas. Partners, activities and resources are real questions once a model is running.
• Many programs ask for both. Fill in the Lean Canvas first, test it, and translate into the Business Model Canvas once the customer and problem have held up. The translation is mechanical; the validation is not.

GrowthApp ships both. The Lean Canvas is where the work starts, and the Business Model Canvas is there for when a program or an investor asks for it.