By Simon Sovič, Senior Product Manager

Scoping an MVP is one of the hardest product decisions you will make. Build too little and you learn nothing. Build too much and you waste months chasing assumptions. This guide walks you through a repeatable process for defining an MVP that is genuinely minimal, genuinely viable, and actually tells you something useful. If you follow each step, you should have a clear, defensible MVP scope document ready in under a week.

What You'll Need

  • A clearly defined problem hypothesis (who has the problem and why it matters)
  • At least 5 conversations with potential users or customers
  • A shared workspace your team can edit, such as Notion, Confluence, or a shared Google Doc
  • A prioritization framework, such as MoSCoW or RICE (both explained below)
  • Basic product analytics tooling to measure outcomes after launch (covered in Step 6)

Step 1: Write Down the One Problem You Are Solving

Before you list a single feature, write one sentence that names the problem, the person who has it, and why existing solutions fall short. This sounds obvious. In practice, most teams skip it and pay for that later.

A useful format is:"[Target user] struggles to [do X] because [root cause], and current solutions fail because [gap]."

Pin this sentence at the top of every planning document. Every feature you consider should trace back to it. If a feature does not directly reduce the friction described in that sentence, it does not belong in the MVP.

  • Keep the sentence to one problem. If you find yourself using "and" to join two problems, you have two MVPs, not one.
  • Validate the problem statement with at least five user conversations before moving forward. If users do not recognize the problem when you describe it, revise the statement, not the users.

Step 2: List Every Feature You Think the Product Needs

Give your team 30 minutes to individually list every feature they believe the product should have at launch. Do this before any group discussion. Group brainstorming tends to anchor on the loudest voice early.

Collect all the lists into one master list. Do not filter yet. You want everything on the table, including features that seem obvious and features that seem absurd. You will cut later, and cutting is easier when you can see the full picture.

  • Include non-functional requirements, such as load time, mobile responsiveness, or basic security. These are easy to forget and expensive to retrofit.
  • Tag each item with who suggested it. This helps during prioritization conversations.

Step 3: Apply a Prioritization Framework to Every Item

Take your master feature list and score every item using MoSCoW: Must Have, Should Have, Could Have, or Won't Have (for now). Run this exercise with your full core team, not just the product lead.

A "Must Have" item meets all three of these tests:

  1. Without it, the product cannot deliver the core value described in your problem statement.
  2. Without it, the product cannot function at all, or it would fail basic user trust (think authentication or data saving).
  3. There is no workaround that costs the user less than 60 seconds.

If an item fails any one of those three tests, it is at best a Should Have. Be strict. Most teams inflate their Must Have list by 40 to 60 percent on the first pass.

  • When your team disagrees on a category, that is a signal you have different assumptions about the user. Surface the assumption explicitly and decide which one you are testing with the MVP.
  • For a deeper look at how to structure these decisions over time, see this guide on How to prioritize features on a product roadmap.

Step 4: Map Each Must-Have Feature to a Specific Assumption

This is the step most teams skip, and it is why so many MVPs launch and teach the team nothing useful.

For every Must Have feature, write down the assumption it is testing. The format is:"We believe [user behavior] will happen because [reason]. We will know we are right if [measurable signal]."

If you cannot fill in that sentence for a feature, the feature is not testing anything. It is just a feature you decided to build. That is not necessarily wrong, but you should be honest about it rather than calling it a learning exercise.

  • Aim for no more than three to five core assumptions per MVP. More than that and your results will be too muddled to act on.
  • Rank your assumptions by risk. The riskiest assumption, the one that, if wrong, kills the entire business model, should be tested first.

Step 5: Define Done for Each Feature Before Development Starts

Scope creep rarely arrives as a dramatic pivot. It arrives as small expansions to features that seemed well-defined. The best defense is writing a concrete definition of done before a single line of code is written.

For each Must Have feature, document:

  • What the user can do when the feature is complete
  • What the user cannot do (explicit exclusions)
  • The acceptance criteria your team will use to sign off on it

Share this document with engineering before estimation. Disagreements about scope surface during estimation, not three days before launch.

  • Write exclusions in plain language. "The MVP will not support bulk imports" is clearer than "bulk import is out of scope."
  • If a designer or engineer says "while we're in there, we should also.." during development, log it in a backlog and do not act on it until the MVP ships.

Step 6: Choose Minimal Analytics Tooling That Covers Your Core Assumptions

Your MVP is only as useful as your ability to measure what happens after it launches. You do not need a full analytics stack on day one, but you need enough visibility to answer whether your core assumptions held up.

Here is a practical comparison of analytics tools commonly used at early-stage startups:

  • Mixpanel- Strong for event-based tracking and funnel analysis. Free tier covers up to 20 million monthly events. Best if your core assumption is about user activation or feature adoption flows.
  • PostHog- Open source, self-hostable, and free up to 1 million events per month on the cloud plan. Includes session recording and feature flags. Best for teams who want control over their data or need to ship experiments alongside analytics.
  • Amplitude- Powerful behavioral analytics with a generous free tier (up to 50,000 monthly active users). Best for teams tracking retention and engagement over time rather than one-time activation events.
  • Google Analytics 4- Free with no hard event limit, but built for web traffic analysis rather than product analytics. Useful as a baseline but not sufficient on its own for testing product assumptions.
  • Heap- Auto-captures all interactions by default, so you can retroactively define events. Useful when you are not sure what to track yet. Paid plans only beyond the startup tier.

For most early-stage MVPs, one tool is enough. Pick the one that maps to your highest-risk assumption. If your biggest question is whether users complete a core action, Mixpanel or PostHog will serve you well. If your biggest question is whether users return, start with Amplitude.

  • Before launch, set up at least one funnel or retention chart that corresponds directly to each assumption you listed in Step 4. Do not wait until after launch to decide what to measure.
  • Log your baseline expectation before launch. "We expect 30 percent of users who reach the dashboard to complete their first action within 10 minutes." Without a pre-launch expectation, you will rationalize whatever number you see.

Step 7: Run a Pre-Launch Scope Review

The day before you freeze scope for the sprint or development cycle, run a 30-minute review with the full team. Go through the Must Have list one more time and ask three questions about each item:

  1. Is this still necessary to test our highest-risk assumption?
  2. Has anything we learned in the last week changed our view of this feature?
  3. Can this be simplified further without breaking the test?

This is not a chance to add features. It is a chance to catch any inflation that crept in during the previous steps.

From experience, this review consistently removes one or two items that were added during the "definition of done" discussions but never formally approved. That alone usually saves a week of development time.

Common Mistakes When Scoping an MVP

  • Treating MVP as "version 1.0 with fewer features."An MVP is a learning tool. Version 1.0 is a product. The mindset difference changes every decision you make about what to include.
  • Letting the sales team define the feature list.Sales will ask for features that help close deals. That is useful input, but the MVP should test whether the core product creates value, not whether it can be sold to a specific prospect.
  • Skipping the assumption mapping step.If you build without mapping features to assumptions, you will launch, see mixed results, and have no idea what to do next.
  • Setting no timeline constraint.Without a fixed launch date, MVP scope expands indefinitely. Pick a date and treat it as a hard constraint. What fits in the time box is the MVP. What does not goes in the backlog.
  • Building the MVP in isolation.Show the scope document to two or three potential users before development starts. Ask them which part of the product they would use first. Their answer often reveals that your Must Have priorities are inverted.
  • Confusing quality with scope.Cutting corners on quality and cutting scope are different things. The MVP should do less, not do things badly. Buggy software teaches you about bugs, not about your product hypothesis.

If you are building out your product practice alongside the MVP process, the Product management for startups essential guide Covers how to structure your team and process for the long term.

FAQ

What is the difference between an MVP and a prototype?

A prototype is built to test design and usability. It rarely handles real data and is usually discarded after testing. An MVP is built to test whether the product creates enough value for real users to adopt it. You ship an MVP to actual users. You show a prototype to selected users in a controlled session.

How do I know when my MVP scope is too small?

If a user cannot complete the core action your product is designed to support, the scope is too small. The MVP must be functional enough for a real user to get real value, even if the experience is rough around the edges. If you need to personally assist every user through the flow, you have a demo, not an MVP.

How long should it take to build an MVP?

There is no universal answer, but many experienced product teams target six to twelve weeks for a software MVP. If your MVP is taking longer than three months, that is usually a sign the scope has expanded beyond what is needed to test your core assumptions. Revisit Step 3 and apply the Must Have test again.

Should I charge for the MVP?

In most cases, yes. Charging, even a nominal amount, is one of the most important tests you can run. Users who pay behave differently from users who do not. If you cannot get anyone to pay for the MVP, that is important information. Free users are easier to acquire but harder to learn from.

How do I manage stakeholder pressure to add more features before launch?

Show stakeholders the assumption map you built in Step 4. Ask them which assumption the requested feature is testing. If it is not testing a higher-risk assumption than what is already in scope, defer it with a specific note in the backlog. The Guide on building and managing a cross-functional product team Covers how to align stakeholders on shared priorities from the start.

Scoping an MVP well is fundamentally a discipline problem, not a creativity problem. The process above gives you a repeatable structure so that every decision is traceable back to a specific assumption and every cut can be justified without argument. Follow the steps in order and you will ship something that actually teaches you something worth knowing.

If you are looking for help applying this process inside your team, Get in touch with Simon Sovič For product management consulting tailored to early-stage startups.

Built with SuperDuperSEO — programmatic SEO content for SaaS, agencies, and indie hackers