The MVP, defined.
Also called: Minimum viable product · Core scope · Launch scope · First release definition
Deciding the smallest version of the product that delivers real value and tests the riskiest assumption, and cutting everything else.
The smallest thing that delivers real value and tests what you’re least sure of. Minimum and viable carry equal weight. Most teams under-cut the scope or over-build it; both waste money. There’s a worked canvas below, and a checklist you can run.
What an MVP really is
You take the product theme you’re building and strip it to the smallest version that still delivers genuine value and still tests your riskiest assumption. The phrase gets abused: an MVP is not the cheapest thing you can ship, nor a half-finished version of the full product. It’s the smallest complete thing that does a real job for a real user and teaches you what you most need to learn.
Both words carry equal weight. “Minimum” without “viable” ships something embarrassing that teaches you nothing except that people dislike rubbish. “Viable” without “minimum” is the full product wearing a humbler name. The skill is holding the tension between the two.
A worked MVP canvas
The clearest way to define an MVP is to fill five boxes honestly. Here is the proofing box’s, the one that ran in our pilot, so you can see the shape of a good answer rather than a generic template.
Notice the canvas does two jobs at once. It pins the smallest thing worth shipping, and it names the single question that thing exists to answer. If your canvas tests three assumptions, it is not an MVP yet; it is a small product.
Where teams get it wrong
- Shrinking the whole product into a tiny version of the full roadmap.
- Trying to test five assumptions at once.
- Shipping with no way to learn from it.
- Padding the scope out of fear of looking unfinished.
- Keep only what proves value; cut the rest, even things you intend to build.
- Pick the one assumption you are least sure of and answer it cleanly.
- Decide how you will capture insight before you build, not after.
- Hold the line. The discipline is the point, not the feature count.
How it fits the bigger picture
Define MVP is activity 04.10.07 in the framework: the seventh of eight Evaluate-stage activities. Behind it sit the product themes it chooses from. Ahead of it sits the business model that closes Evaluate, and then the whole Define stage, starting with the design brief, which turns the MVP scope into something to build.
What it can do
Cut a product to the smallest version that still does a real job and still tests what you’re unsure of. Protect the budget and the timeline from the slow creep of “while we’re at it.”
What it can’t do
It can’t make scope decisions you haven’t earned; an MVP cut without the validation behind it is just guessing with confidence. And it isn’t the final product; it’s the first one, and the feedback loop in Stage 10 decides what comes next.
See the full 10-stage process →
Try it yourself
Write your product’s one core promise. List every feature. Strike out everything whose removal doesn’t break that promise. Check that what’s left still tests your riskiest assumption. Whatever survives both cuts is your MVP. Everything you struck out goes in a dated backlog, not the bin.
Want a structured first pass? Start the Free Sprint → and the GPT will help you find the minimum.
Your MVP checklist
Project notes: one SKU, one capacity
▸ From the notebook · optional reading
The proofing box’s MVP came down to one capacity, ceramic and wood, no app. Holding that line was the hardest and best decision the team made.
3 min read · click to open
The team had chosen the Simple Essential theme: one heated proofing box at £149. Defining the MVP was really about resisting the pull to add “just one more thing” before launch.
The core promise was “a reliable overnight prove, every time, with no thinking.” We struck out everything that didn’t serve it. App connectivity and a phone readout: gone (they break the no-app positioning and ask you to think). A larger two-loaf-plus capacity: parked (a second set of ceramic tooling the team couldn’t fund yet). A second temperature preset: parked. Wi-Fi, accounts, all of it: never in scope after the Viability Sprint.
What survived was a single SKU: one capacity for two 1kg dough balls, the ceramic shell with wood cladding, a rotary encoder and a small OLED. The premium finish stayed because it is the whole reason a baker pays £149 for a counter object rather than buying a folding fabric proofer, and the gifting cluster wanted something display-worthy. Everything else went into a dated V2 backlog.
The riskiest assumption test was preserved too. The whole MVP existed to answer one question: will serious home bakers pay £149 for a no-app box that just holds the temperature? A single clean SKU answered it without the noise a range would have added. When the founder got nervous, weeks later, about “launching with just one thing”, I pointed him at the backlog. Focus, not loss. (The larger capacity launched in year two, exactly as planned, and sold well, precisely because the first product had proved the demand.)
— Evaluate stage, project notes, 2026
— Next in Evaluate → Business model diagram