Most MVPs fail before any code is written. They fail at the definition stage, when "minimum" quietly becomes "everything the founder mentioned, but rushed," and "viable" becomes whatever happens to survive the deadline. The result is a release that is neither small enough to ship quickly nor solid enough to prove anything — the worst of both.
Shaping a release that is genuinely minimum and genuinely viable is a discipline of its own, and it has surprisingly little to do with engineering velocity. The launches that go well are decided in the first couple of weeks, in a handful of conversations: what the release must prove, who it must prove it to, and what evidence would count. Get those right and the build phase is almost calm. Get them wrong and no amount of sprint discipline will recover the launch.
We build MVPs for clients regularly, and over time we have settled into a shaping process that front-loads those decisions. This post walks through it end to end: how we define viability, set scope, sequence the build, and decide — before writing code — what "launched" will actually mean.
What "Minimum Viable" Actually Means
The term has been stretched so far that teams in the same room often mean different things by it. So we start by pinning it down. Marty Cagan's classic definition of a minimum viable product is a useful anchor: the smallest possible product where people still choose to use or buy it, people can figure out how to use it, and the team can deliver it with the time and resources available. All three conditions matter. A product nobody chooses proves nothing; a product nobody can operate proves the wrong thing; a product the team cannot actually ship proves nothing on any timeline.
Cagan has also drawn a sharp line between a product that is viable and one that is merely minimal — a distinction worth keeping taped to the wall, because the industry's failure mode is almost always over-rotating on "minimal" and quietly dropping "viable."
The other anchor comes from the Lean Startup tradition. An MVP is not a small version 1; it is an instrument for learning. DORA's guidance on working in small batches describes an MVP as a prototype with just enough features to enable validated learning about the product and its business model. That framing changes the shaping conversation immediately. The question stops being "what features can we afford?" and becomes "what is the cheapest release that produces real evidence?"
Start From the Outcome, Not the Feature List
We open every MVP engagement with one question: what does the user need to accomplish for this product to have proven something? The answer becomes the spine of the release.
For an invoicing tool, the spine might be: a freelancer creates an invoice, sends it, and gets paid. For a logistics dashboard: a dispatcher spots a delayed shipment and reroutes it before the customer notices. One sentence, one user, one accomplishment. Every proposed feature is then tested against the spine. Features that serve that path go in. Features that serve a hypothetical future user — the agency with five seats, the enterprise with SSO requirements — go on a list we revisit after launch, ideally a backlog that is actually structured to help delivery rather than a parking lot of guilt.
This sounds obvious. In practice it is the hardest part of shaping, because every stakeholder arrives with a feature list, and feature lists feel like progress. The spine question converts the conversation from "which of these do we keep?" to "what does each of these prove?" — and most items turn out to prove nothing the spine doesn't already cover.
Set an Appetite Before You Design
Scope conversations go in circles when time is treated as an output. We borrow a tool from Basecamp's Shape Up: the appetite. In Shape Up's framing, an appetite is a time budget for a standard team size, and it inverts the usual logic — "Estimates start with a design and end with a number. Appetites start with a number and end with a design."
For an MVP this is clarifying. Instead of designing the release and discovering it costs five months, we declare the budget first — say, six weeks of build — and design backwards into it. The appetite forces trade-offs to happen during shaping, on a whiteboard, where they are cheap, rather than during week nine of the build, where they are expensive and emotional. It also gives stakeholders an honest frame: anything added to the release must displace something, because the time box does not move.
Scope by Narrowing, Not by Thinning
The classic MVP mistake is shipping all the features at low quality instead of a few features at real quality. Users forgive a missing feature; they do not forgive a broken one. A missing feature reads as "early product." A broken one reads as "broken product" — and early adopters, the exact people an MVP exists to convince, are the ones who hit it first.
So when the design exceeds the appetite, we shrink the release by narrowing its boundary, never by thinning what is inside it:
| Scoping move | What it looks like | What it costs |
|---|---|---|
| Narrow the audience | Serve freelancers only, not agencies | Some early demand goes unserved — measurably |
| Narrow the cases | One currency, one tax regime, manual exports | Edge users wait; the core path stays honest |
| Defer whole features | No client portal at launch | A visible gap users can understand and forgive |
| Thin the quality | Skipped empty states, silent errors, no loading feedback | The trust of exactly the users you need most |
The first three moves are legitimate. The fourth is the trap. Inside whatever boundary we choose, the work gets built properly — empty states, error messages, edge cases, the unglamorous 30% that separates a demo from a product. The goal is reliability without overengineering: no speculative architecture for the agency tier we cut, but no silent failures on the path we kept.
Sequence the Build Around the Riskiest Assumption
Once scope is set, order matters more than teams expect. The default sequencing — foundations first, risky stuff later — is exactly backwards for an MVP, because it spends the budget before testing the bet.
We sequence by risk instead:
- Name the assumption that kills the product if false. Usually it is demand-shaped ("dispatchers will trust an automated reroute suggestion") rather than technical.
- Build the thinnest slice that tests it. A vertical slice through the real stack, not a horizontal layer that demonstrates nothing until everything meets.
- Put it in front of real users early, even ugly, even behind a flag for five friendly accounts.
- Let the result reshape the remaining weeks. A slice that lands changes what "done" means for the rest; a slice that doesn't saves you from polishing a corpse.
This is the same logic that drives the shift toward smaller, smarter releases in mature products, applied at day zero. DORA's research on small batches points the same direction: decomposing work into units that can be completed and validated quickly is what makes course-correction possible at all.
Define "Launched" Before Building
An MVP needs a measurable definition of done that includes evidence, not just deployment. Ours has four parts, agreed in writing before the first commit:
- The core path works end to end for a named first cohort — real people, listed by name or segment, not "users."
- Instrumentation exists to see whether that cohort starts the path, where they stall, and whether they complete it.
- Someone owns watching the numbers, by name, for the first two weeks.
- A decision date is on the calendar — the day the team looks at the evidence and decides what it means.
The Lean Startup principles call this discipline validated learning — "a rigorous method for demonstrating progress when one is embedded in the soil of extreme uncertainty" — paired with innovation accounting, the practice of measuring progress against the learning goal rather than against feature count. A launch without measurement is just a deploy. The whole point of a minimum release is the learning, so the learning machinery is part of the minimum, and it is in scope even when a feature has to come out to make room for it.
The First Two Weeks After Launch
Launch day is the midpoint of an MVP, not the end. The two weeks that follow are where the investment pays out or quietly evaporates, and they go better with a little structure.
We keep the build team partially allocated — not rolled off — because the first cohort will surface small breaks and confusions that are cheap to fix immediately and corrosive to leave. We hold a short evidence review twice a week: what did the numbers do, what did users say verbatim, what broke. And we defend the decision date. The temptation in week one is to re-litigate the roadmap after every enthusiastic or grumpy email; the discipline is to collect, tag, and wait for the agreed moment to decide. The same delivery habits that keep longer projects healthy — visible status, small fixes shipped continuously, honest notes — carry the post-launch window too.
Three outcomes are possible at the decision date, and all three are wins compared to not knowing: the evidence supports the spine, so the deferred list gets re-ranked and the product grows; the evidence is mixed, so the next appetite goes to the sharpest unanswered question; or the evidence says no, and the company just bought that answer for six weeks instead of eighteen months.
Where to Start
If you are shaping an MVP now, you can compress most of this into a one-page document written before any build conversation:
- The spine — one sentence: who accomplishes what, such that something is proven.
- The first cohort — named people or a named segment who will run the path in week one.
- The appetite — the time budget, declared before the design.
- In and out — the narrowed boundary: audience, cases, features, with the deferred list written down.
- The evidence — what will be instrumented, who watches it, and the decision date.
If you cannot fill in the page, the project is not ready for engineers — and discovering that costs a morning instead of a quarter. If you can, build the smallest thing the page describes, build it properly, and let the first cohort tell you what the product wants to become.
