How to Decide What Goes Into Your MVP: A Founder's Guide to Scoping Version 1

Part 1: Choose the job and the person

An MVP is for learning, not for shipping less

Eric Ries defined the MVP as the version that gives a team the maximum validated learning about customers with the least effort. Agile Alliance lists common misreadings: treating it as only the smallest feature set, making quality so low that you can't read real usage, and ignoring feedback after launch.

So the question isn't "what's the smallest thing we can ship?" It's "what's the smallest thing that tells us if people will use this?"

Three steps before you list features

1. Start with your primary persona. Pick one. In a waitlist-built persona, this is the group that answered, tested and came back. Everyone else waits for V2.

2. Sort feedback into themes. For each theme, ask three things. How often did it come up? Did it come from the primary persona? Does it block the main job? A request repeated by ten off-target people is weaker than one from three of your best testers.

3. Write the job in one sentence. Use this format: For [persona], V1 helps them [do one thing] without [their main pain]. If you need an "and", you have two products.

One loop is easier to build and test

Code Huddle's Mile Matcher case study describes a running app that matches athletes by ability and turns progress into live races, ratings, milestones and streaks. The loop is easy to say: match, race, rate. Badges and leaderboards all feed it. The case study doesn't describe what was cut. It shows the shape of a product built around one clear loop.

Part 2: Cut the rest

Sort every feature with MoSCoW

MoSCoW sorts features into Must, Should, Could and Won't have. Dai Clegg created it in 1994. A Must is something without which the delivery counts as a failure.

Use this test for each feature: If we remove it, can the persona still finish the job? If yes, it isn't a Must. Required safety, legal obligations and technical dependencies still belong in the scope.

Be honest about "Won't have this time". It's the most useful list you'll write. Show it to the team, and to investors, so scope creep has to argue with it in public.

Break ties with RICE

When two features both feel like Musts, score them. Intercom's RICE method multiplies Reach, Impact and Confidence, then divides by Effort. Confidence is a percentage that discounts ideas with weak evidence. This is where your waitlist pays off: survey answers and demo reactions raise your confidence in some ideas and expose others as guesses. Intercom also says the score shouldn't be a strict rule. Dependencies can justify working on a lower-scoring item first.

RICE score = (Reach × Impact × Confidence) ÷ Effort. Use confidence as a decimal, such as 0.8 for 80%, and compare reach over the same period and effort in the same units. A lower score does not make an essential requirement optional.

Decide how you'll judge V1

Pick one number before you build. For example: of the people invited to test V1, how many complete the main job in their first week? Without a number, every launch looks like a success.

Mistakes I'd watch for

• Building for everyone. Michael Seibel's advice, as summarized in the linked Medium article, is to serve a small group that engages first.
• Letting the loudest voice win. Weight feedback by persona, not volume.
• Cutting quality, not scope. A rough product that works beats a polished one with ten half-working features.
• Ignoring what comes back. Plan the feedback loop before launch. Our Waitlist or MVP First? guide explains how to turn sign-ups into a feedback loop.

What to give a dev team

Share one page: your primary persona, the one-sentence job, the Must and Won't lists, the success metric and any hard constraints such as budget, deadline, compliance and integrations. A scope that fits on a page is easier to estimate and harder to inflate.

Frequently asked questions