Plenty of teams have run a Lean Canvas. You get the core team and a few stakeholders in a room, draw ten boxes on a whiteboard, and fill them in starting with the problem: Problem, Customer Segments, Value Proposition, Solution, Channels, Revenue, Cost Structure, Metrics, Unfair Advantage. It is a quick way to get a business model onto a wall where everyone can poke at it.
We use it a lot at StronglyAI. What we have found is that on AI work, the standard canvas tends to skip over the two issues that cause the most projects to stall. This post covers what those two issues are, and the change we make to catch them: a feasibility row.
Where AI projects tend to stall
The Lean Canvas was built for products whose main risk is whether the market wants them. It assumes that once you commit to building the solution, you can build it. For ordinary software that holds up well enough. For AI it often does not, which leaves two gaps the canvas was never meant to cover.
Will it work well enough to matter?
With AI you usually cannot say whether the model is good enough until you put real time and real data into finding out. The canvas has no box for that, so teams glide past it and learn the answer much later, after a lot of money has gone in.
Will anyone actually use it?
A model can hit its accuracy target and still go unused because the people it was built for do not believe the output, cannot spot when it is wrong, or have nothing to fall back on when it fails. The ten standard boxes do not prompt anyone to raise it.
So the aim of our version is modest. Keep what works about the Lean Canvas and add just enough to bring feasibility and trust forward to kickoff, where they are cheap to deal with, rather than launch, where they are not.
What we change
We did not want to rebuild the canvas from scratch. People already know it, and the problem-first order is worth keeping. So our version holds onto most of the original, reworks three boxes, and adds a feasibility row. The boxes we leave alone are Problem, Customer Segments, Channels, Revenue (or Outcomes), Customer Metrics, and Business Metrics. They behave the same whether or not there is a model involved. Three boxes get reworked.
Problem + why AI
Make the team say out loud why this needs ML instead of rules, a heuristic, or a person. A fair share of "AI projects" are data or process problems in disguise - and the first hour is a better time to find that out than the first quarter.
Value proposition: source of value
Say where value comes from - accuracy, speed, scale, or cost. A proposition that leans on near-perfect accuracy is a very different project from one where a rough first draft a person cleans up is plenty.
Unfair advantage
It rarely sits in the model now - foundation models catch up fast. Aim it at what holds over time: data you own, distribution you have, workflow you are wired into, and feedback loops that build as the product runs.
The feasibility row
The main change is four boxes built for AI work, grouped together so they read as one row beneath the canvas. Each one asks something the original canvas cannot.
The Lean Canvas, with three boxes reworked for AI - plus a feasibility row underneath.
Top problems, and why this needs ML over rules or a person.
ReworkedThe smallest thing that could work.
Where value comes from: accuracy, speed, scale or cost.
ReworkedData, distribution, workflow, feedback loops.
ReworkedWho it is for, and the early adopters.
The numbers that show users get value.
Path to your customers.
Build and run costs, including compute and data.
The outcome the business cares about.
How value is captured.
Do we have it, are we allowed to use it, how fresh and clean is it, what does labelling cost?
Build, buy, fine-tune or prompt? And the riskiest assumption that sinks it if wrong.
How we measure model quality, and what level makes it worth shipping. Kept apart from business metrics.
Failure modes, tolerable error, bias, what happens when it is wrong, regulatory angle.
Data does more than anything else to decide whether an AI project works, and the standard canvas gives it nowhere to live - which is why we put it at the front of the row. Feasibility and approach names the technical bet and the riskiest assumption, turning a vague worry into something the team can go and test. The "good enough" bar tells you whether the model is doing its job, kept apart from business metrics on purpose, because you need that answer sooner. And risks and guardrails keeps one thing in view: with AI, being confidently wrong often costs more than being slow.
Fill in the feasibility row before the solution
One change to how you run the session matters more than the rest, and it is a small one. Have the team work through Data, Feasibility, and the "good enough" bar before they touch the Solution box.
Moving those boxes up front shifts the talk from "here is what we will build" to "here is what would have to be true for this to be buildable, and here is how we would check it." That shift is what separates a real AI canvas from a Lean Canvas with some AI words pasted on.
The rest of the session stays the same as the part that makes the Lean Canvas work in the first place: short rounds of quiet writing, reading sticky notes aloud and dropping the duplicates, dot voting once the group is big enough to need it. The feasibility row fits straight into that rhythm. It just goes earlier.
A few caveats
Our version runs to fourteen boxes, which is about as much as a single wall can hold before it gets hard to read. That is the reason we keep the four new ones grouped as a row instead of spreading them around the board. If it starts to feel crowded, that is a sign to sharpen the answers rather than add boxes.
It is also worth saying what a canvas is for. It helps a team think; it does not validate anything. It brings assumptions to the surface, and then you still have to go and test them. The riskiest assumption in your feasibility box has to be checked against real data and real users. The canvas just tells you which one to check first.
And treat it as something you keep updating. The useful version is not the one from kickoff. It is the one you come back to week after week as you learn what the data can carry, where the model levels off, and whether anyone trusts what it produces. The wall should move as the project moves.
Try it on your next project
If you are starting an AI initiative, draw the standard Lean Canvas, rework the three boxes above, and add the feasibility row before anyone fills in the solution. The first time, you will probably hit a moment where someone asks whether you have the data to do this at all.
“That is a useful question to run into early, and a whiteboard is a much cheaper place to run into it than production.
We run this canvas in week one of every AI Primer.
The AI Primer is a three-week engagement that turns a vague mandate into a prioritized, defensible roadmap - feasibility and data readiness scored before you build, not after.
See the AI Primer