Skip to content
MVP

How to Scope an MVP Without Building the Wrong Thing

Most MVPs are too big, too slow and test the wrong thing. Here's how we scope products that launch in weeks and actually teach you something.

An MVP is not a small version of your final product. It is the fastest way to answer the one question that could kill your company. Founders who treat it as a 'lite' product end up building for months and learning very little.

This is the process we use to scope MVPs with founders before any design or code starts.

1. Write down your riskiest assumption

Every startup rests on a stack of beliefs: people have this problem, they will pay to solve it, they will choose you over the workaround they use today. List them, then ask which one, if wrong, makes everything else irrelevant.

That assumption is what your MVP exists to test. If a feature does not help test it, it is not in the MVP.

2. Define the one job your user hires the product for

Describe the core job in a single sentence, from the user's point of view. 'Send an invoice and get paid' is a job. 'Manage finances' is a category.

  • Map the shortest path from sign-up to that job being done.
  • Every screen that isn't on that path is a candidate for cutting.
  • Anything you can do manually behind the scenes for the first users, do manually.

3. Cut, then cut again

Settings pages, dashboards, notifications, multiple user roles and integrations are the usual suspects. They feel essential, but early users forgive a missing feature far faster than a confusing core experience.

A useful test: if you removed this and a user complained, would that complaint be good news? If yes, it can wait.

4. Design before you build

A clickable prototype costs a fraction of a built feature and surfaces most usability problems. Put it in front of five target users before a line of production code is written. You will change more than you expect.

5. Decide what 'working' means before launch

Pick the one or two numbers that prove or disprove your assumption, such as activation rate, repeat usage or paid conversion, and instrument them from day one. Without this, launch day turns into opinions instead of evidence.

A realistic timeline

With a tight scope, most MVPs we work on move from first call to a live product in roughly six to eight weeks: about two weeks shaping and prototyping, then four to six weeks building with a demo every week.

If your scope can't fit that window, that's usually a sign the MVP is trying to answer too many questions at once.

Written by Two CentsA design-first product studio helping founders design, launch and scale products. About the studio.

More Notes

Start a project

Got an idea? Get our two cents.

Book a 15-minute call. We'll talk through the idea and follow up with a written plan, timeline and a fixed quote.