How to scope an MVP around the one job customers hire it for.

A minimum viable product is not a cheap version of your vision. It is the smallest thing that reliably delivers the outcome your first customers care about, so you can learn whether they keep using it and paying for it.

Why it matters

Every feature you add before launch delays learning, adds bugs and creates things to maintain. Most of what tech founders plan for version one turns out to be unnecessary once real users arrive. Scoping tightly is the single biggest lever on how fast you learn.

Step by step

1. Write the one job. In one sentence: “When [situation], [customer] wants to [outcome] so they can [benefit].” Use the language from your validation interviews.
2. Map the essential path. List the steps a customer must take from first sign-in to getting that outcome. This is the spine of the MVP. Anything not on it is a candidate to cut.
3. Sort every idea into three lists. Must have: without it the job cannot be done. Should have: makes it better but customers can manage without. Later: everything else. Be ruthless; as a rule of thumb, if more than a third of the list is “must have”, look again.
4. Buy, do not build, the commodity parts. Use established services for payments, sign-in, email, analytics, support chat and hosting. Build only what makes you different.
5. Fake the back end where you can. Some steps can be done manually at first, by you or a teammate behind the scenes, then automated once you know they matter.
6. Define “done” for the MVP. Set a release date, a small group of named first users and two or three success measures, such as share of users completing the job in their first week.
7. Capture it on one page. The Product Execution Canvas helps you record the job, users, scope, measures and risks in one place.

MVP, MVB and the bar for quality

Minimum does not mean broken. The essential path must be reliable, secure and clear, or users will judge the idea by the bugs. Also remember that a product is not a business: the minimum viable business adds the way you charge, support and reach customers. Plan those alongside the build.

Worked example

LedgerLoop’s original plan had 31 features, including a client portal, bank feeds, a mobile app and practice analytics. The one job was: “When a quarterly deadline approaches, a practice manager wants every client’s documents collected without chasing, so partners can bill on time.” The essential path was: import client list, set deadlines, send automatic reminders with an upload link, see who is outstanding. That was seven features. Reminder scheduling ran on a simple timed job, and uploads went to an existing storage service. The MVP shipped in six weeks to the two pilot practices. The mobile app, which had been the team’s favourite feature, was never asked for.

Common mistakes

• Gold-plating features nobody has asked for.
• Building for every segment at once instead of the first customers you validated.
• Building commodity features such as custom login or billing systems.
• No release date, so scope keeps growing.
• Confusing minimum with poor quality on the essential path.
• Designing for edge cases first. Handle the common case well and deal with rare cases manually until they become common.

What to measure

• Number of features in the MVP versus the original wish list.
• Weeks from scope sign-off to first real user.
• Share of first users who complete the one job.
• Feature requests from real users that were on your “later” list, and those that were not.
• Manual steps still running behind the scenes, and the time they take each week.