On this page
Key takeaways
- An MVP is the smallest complete product, not the smallest pile of features.
- Scope is decided by writing non-goals as carefully as goals.
- Design interfaces, data, and deployment together; 'later' is where launches die.
- Ship into a real environment early, then cut the second version from use.
Six weeks is roughly the median for a focused first release in our work. It is not magic. It is what happens when the scope is small, the operator is named, and the environment exists. Most delayed MVPs are not slow to build; they were never scoped.
What 'minimum' really means
Minimum viable is often read as minimum features. That produces a demo. What you want is the smallest system a real person can complete their real job in — from the first click to the outcome — including authentication, deployment, and a way to know when it breaks.
A demo with a database
- Impressive screens, no real data
- Runs on one laptop
- No login, no backups, no monitoring
- Nobody owns it
A minimum complete product
- One job done end to end
- Runs in a real environment
- Authentication, deploy, and observability included
- A named operator
The scoping method
- 01
Write the problem in one paragraph
Who has it, what they do today, and what it costs. If you cannot write it plainly, you are not ready to build.
- 02
Name the operator
The person who will use and run the system. Every later decision is easier when there is a face attached.
- 03
Draw the one job
From trigger to outcome, the single path that has to work. Everything off that path is a candidate for later.
- 04
Write the non-goals
What the system will explicitly not do in version one. This is the most valuable page in the document.
- 05
Design the whole system together
Screens, data model, integrations, and deployment. Skipping one does not save time; it moves the cost.
- 06
Cut, then cut again
Remove anything the operator could live without for the first month. Keep a list; it becomes the second cut.
Goals and non-goals in practice
| Idea | Goal or non-goal? | Reason |
|---|---|---|
| Customers can pay an invoice | Goal | It is the one job |
| Multi-currency support | Non-goal (v1) | One currency proves the loop |
| Admin analytics dashboard | Non-goal (v1) | The operator can use exports for a month |
| Email notifications on payment | Goal | Without it the loop is not complete |
| Team roles and permissions | Non-goal (v1) | One operator, one role |
| Backups and error monitoring | Goal | Complete means recoverable |
The non-goals page is not a list of things you will never build. It is a promise about what the first release will not pretend to be.
A six-week shape
What to build in week one, even if it feels boring
- Deployment. A pipeline that ships to a real environment on day three, not day thirty.
- Authentication. Retrofitting it is harder than including it.
- Observability. Logs and error tracking, so week five has evidence.
- Backups. A system you cannot restore is a prototype.
Warning signs your scope is too big
If you tick more than two, cut
- There is more than one primary user type.
- The plan mentions 'phase two' more than twice.
- Nobody can say who will operate it.
- An integration is required that nobody has tested yet.
- The launch date depends on a feature no user has asked for.
Appetite before estimate
Traditional planning asks how long a piece of work will take, which invites inflated guesses and endless scope negotiation. Shape Up [1] inverts the question: how much time is this worth? That time is the appetite, and the scope is shaped to fit it. Six weeks is an appetite, not a forecast.
Estimate-first planning
- Scope is fixed, time floats
- Every addition extends the date
- Debates centre on how long things take
- Risk is discovered late
Appetite-first shaping
- Time is fixed, scope flexes
- Additions displace something else
- Debates centre on what is worth including
- Risk is addressed first, in shaping
Steve McConnell's work on software estimation describes the cone of uncertainty: early estimates carry wide error bars that only narrow as unknowns are resolved [2]. Shaping is the act of resolving the biggest unknowns early, so the remaining work is predictable enough to commit to.
Slice vertically, not horizontally
A common mistake is building layer by layer: the whole database, then the whole API, then the whole interface. Nothing works until the last layer lands, and integration surprises arrive at the end. A vertical slice builds one thin, complete path through every layer first.
| Horizontal plan | Vertical plan |
|---|---|
| Weeks 1–2: database for everything | Week 1: one job, end to end, ugly but real |
| Weeks 3–4: API for everything | Weeks 2–3: widen the job, add the next path |
| Weeks 5–6: interface for everything | Weeks 4–5: harden, deploy, observe |
| First time a user sees it: week 6 | First time a user sees it: week 1 |
Alistair Cockburn called the first vertical slice a walking skeleton: a tiny implementation of the whole system that can be built, deployed, and tested end to end. Getting it running in week one is worth more than any amount of speculative design.
Story mapping the one job
Jeff Patton's story mapping [3] arranges work along the user's journey from left to right and by priority from top to bottom. The top row is the walking skeleton; everything below is refinement. It makes the cut visible: draw a line under the row you will ship.
| Journey step | Must ship (skeleton) | Ship if time allows | Later |
|---|---|---|---|
| Sign in | Email and password | Password reset | Single sign-on |
| Create an invoice | Amount, reference, due date | Line items | Recurring invoices |
| Customer pays | One payment method | Receipts by email | Multiple currencies |
| Operator reviews | List of payments and status | Search and filter | Analytics |
| Finance closes | CSV export | Accounting integration | Automated close |
Risk-first sequencing
Inside the six weeks, do the scary things first. Every project has a few unknowns that could sink it: an integration nobody has tried, a performance assumption, a regulatory question. Building the easy parts first feels productive and postpones bad news.
- 01
List the unknowns
Write down everything you do not know how to do or cannot control.
- 02
Rank by damage and likelihood
Which unknown, if wrong, would force a redesign?
- 03
Spike the worst first
A day or two of throwaway code that answers the question.
- 04
Record the answer
Turn each spike into a sentence in the scope document.
- 05
Then build the certain parts
With the risk gone, the rest is execution.
A definition of done that includes production
Done means
- The one job works end to end in a real environment.
- Authentication and authorisation are in place.
- Deployment is repeatable from a single command or pipeline.
- Errors and key events are logged where someone will see them.
- Backups exist and a restore has been tried.
- A named operator has used it unaided.
- The second-cut list is written down.
Planning the second cut
The first release is a hypothesis. The second cut is the answer. Decide, before launch, when you will review, what you will measure, and who decides. A cool-down period after the build [1], reserved for fixing what real use reveals, keeps the second cut from being squeezed out by the next big idea.
If you are hiring help
Whoever builds it, ask for the non-goals in writing before the first invoice. If you want a partner, look for a written scope, direct access to the people building, and a handover that leaves you able to run the system alone.
References & further reading
- 1Shape Up: Stop Running in Circles and Ship Work that Matters — Ryan Singer, Basecamp
- 2Software Estimation: Demystifying the Black Art — Steve McConnell, Microsoft PressSource of the cone of uncertainty discussion.
- 3User Story Mapping: Discover the Whole Story, Build the Right Product — Jeff Patton, O'Reilly Media
- 4The Lean Startup — Eric Ries, Crown Business
About the author
Product behaviour described here reflects what is implemented and tested; anything else is marked as planned. Code samples are illustrative.
All writing