Scoping an MVP

The term minimum viable product was coined by Frank Robinson in 2001 and made popular by Steve Blank and Eric Ries, whose 2011 book The Lean Startup put it into everyday use. The idea is simple: build the smallest version of a product that lets you learn whether it solves a real problem for real people. The hard part is deciding what "smallest" means for your product.

For a small or mid-size business, an MVP is rarely a startup experiment. It is usually a first release of something the business already needs: a booking system, a customer portal, a field app for technicians. That changes the question from "will anyone want this?" to "what is the least we can build that does the job well enough to replace what people do today?"

1. Start from one user and one job

Write one sentence before any feature list: [this person] needs to [do this job] so that [this outcome happens]. For example: "A homeowner needs to book a service visit online so that our office stops spending mornings on the phone." If you need three sentences, you probably have three products, and the first release should pick one.

The sentence also tells you who to test with. If the user is the homeowner, the first release is judged by homeowners booking visits, not by how complete the admin screens look.

2. Map the whole journey, then slice it thin

Jeff Patton's book User Story Mapping (2014) describes a technique we use in almost every discovery: lay out every step a user takes from left to right, then list the possible features under each step, from essential at the top to nice-to-have at the bottom. Then draw a line.

The first release is a thin slice across every step, not one step done perfectly. A booking flow that lets people pick a time, pay, and get a confirmation, all plainly, beats a beautiful calendar with no way to pay. Engineers call the technical version of this a walking skeleton, a term from Alistair Cockburn, one of the authors of the Agile Manifesto: a tiny end-to-end build that connects all the main parts, which the team then fleshes out.

3. Sort features with MoSCoW

MoSCoW is a prioritization method used in the DSDM project framework. Every candidate feature gets one of four labels: Must have, Should have, Could have, or Won't have this time. The labels only work if you are strict about the first one.

• Must have: the release fails without it, and there is no workaround, not even a manual one.
• Should have: important, but the release still works without it for a while.
• Could have: welcome if time allows, and the first thing cut if it does not.
• Won't have this time: agreed and written down as out of scope, which stops it from creeping back in.

A useful test for every Must: if a person could do it by hand for the first few months, it is not a Must.

4. Replace features with manual work

Many features exist to save staff time at scale, which a new product does not have yet. Refund approvals can go to an inbox for a while. A monthly report can be an export that someone formats in a spreadsheet. A complex pricing engine can start as a short table someone keeps up to date.

Each manual workaround is a decision to postpone, not to cut. Write it down with the point at which it stops being acceptable, such as "automate approvals when we pass about twenty refunds a week."

5. Decide what you will measure before launch

Pick two or three signals that tell you whether the release works, and agree on them before launch, when nobody is defending their favorite feature. Good signals are behaviors: bookings completed without a phone call, orders entered in the field instead of on paper, time from request to approval. Then make sure the release can record them.

6. Watch for the scope traps

• Integrations that sound small. "It just needs to sync with our accounting software" can be a day or a month, depending on the other system's API.
• Roles and permissions. Every new role multiplies the screens and the tests. Start with as few as you can.
• Rare edge cases. Handle the common path well and route the rare cases to a person.
• Features for the demo. If it impresses in a meeting but no user asked for it, it can wait.

7. Fix the time, let the scope flex

The most reliable way to ship an MVP is to fix the date and the budget, and let the scope give. Keep the Must list small enough to fit with room to spare, build it first, and add Shoulds while the calendar allows. When the date arrives, you ship what is done and working, and the rest becomes the plan for release two.

Sources

• Eric Ries, The Lean Startup (Crown Business, 2011). The term MVP is credited to Frank Robinson of SyncDev, who first used it in 2001.
• Jeff Patton, User Story Mapping: Discover the Whole Story, Build the Right Product (O'Reilly, 2014).
• Alistair Cockburn on the walking skeleton; described in Crystal Clear (2004).
• Agile Business Consortium, DSDM Project Framework, chapter on MoSCoW prioritization.