To scope an MVP, define a single specific problem for a single specific user, list every feature you think you need, then cut everything that does not directly solve that problem for that user in their first session. The output is a one-sentence product definition and a feature list of three to five items maximum. That boundary is your MVP scope.
Most MVPs fail before a single line of code is written. The failure is almost always a scoping problem: too many features, too vague a problem, or a target user that is everyone and therefore no one. Founders, especially non-technical ones, consistently underestimate how much damage an over-scoped MVP does. It burns budget, delays feedback, and produces a product that is impossible to evaluate because it is trying to do too many things at once. The framework laid out here is the same process used in product consulting engagements to take a founder from a raw idea to a clearly bounded, buildable MVP. It is not theoretical. Every step produces a concrete output that either moves the build forward or kills a bad idea early, which is the best possible outcome. The goal is a single-sentence product definition, a ruthlessly prioritised feature list, and a scope document you can hand to a developer or use in a no-code tool like Base44 on day one.
Before You Start: What You Actually Need
You need three things before touching any tool or template: a problem hypothesis, a named user type, and a success metric. Without all three, scoping becomes feature negotiation with yourself, and you will lose. No special software is required. A shared document and a willingness to delete things are enough.
Step 1: Write the Problem in One Sentence
The problem statement is the foundation. Write it in this format: "[User type] struggles to [do specific thing] because [specific reason]." If you cannot complete that sentence without using the word "and" more than once, you have more than one problem. Pick one.
A weak problem statement: "Small business owners have trouble with operations and customer management and marketing."
A strong one: "Freelance designers lose billable hours tracking client feedback across email threads because there is no single place to collect and approve revisions."
The strong version names a specific user, a specific lost outcome (billable hours), and a specific mechanism (scattered feedback channels). That specificity is what makes every subsequent scoping decision answerable. When a feature request comes up, you ask: does this solve that problem for that user? Yes or no.
Step 2: List Every Feature You Think You Need
Write them all down. Do not filter yet. This is a brain-dump, not a roadmap. Most founders arrive with 15 to 30 feature ideas. That is fine. The list exists so you can see the full scope of your assumptions before you start cutting.
Common mistake: skipping this step and going straight to prioritisation. If you do not externalise every idea first, the ones you skipped will resurface during build and bloat the scope anyway.
Step 3: Apply the First-Session Filter
For each feature on your list, ask: "Does a new user need this in their very first session to experience the core value of the product?" If the answer is no, move it to a backlog. Not deleted, just deferred.
This filter is the most effective single tool in MVP scoping. It forces you to think about the user's journey rather than the product's capabilities. A reporting dashboard, for example, almost never belongs in an MVP because a new user has no data to report on. An onboarding flow that collects user preferences rarely belongs either, because you do not yet know which preferences matter.
After applying this filter, most feature lists collapse from 20+ items to five or fewer. That is the right direction.
Step 4: Rank What Remains by Dependency
Order the surviving features by technical and logical dependency. Feature B cannot exist without Feature A. Feature C is only useful after Feature B works. Mapping this dependency chain reveals the true minimum: the features at the top of the chain that everything else depends on.
For a client feedback tool, the dependency chain might look like: (1) upload a file, (2) add a comment pinned to the file, (3) mark a comment as resolved. Everything else, user roles, notification emails, integrations, version history, depends on those three working correctly. Those three are your MVP.
A common mistake at this step is treating "nice to have" as a category. There is no nice-to-have in an MVP. There is only "required for the core loop" and "everything else."
Step 5: Write the One-Sentence Product Definition
Combine your problem statement and your surviving feature set into a single sentence: "[Product name] helps [user type] [achieve outcome] by [mechanism]." This sentence is your scope boundary. Any feature that does not fit inside it does not belong in the MVP.
Example: "Markup helps freelance designers collect and approve client feedback on design files by giving clients a single link to annotate and sign off on revisions."
If a stakeholder or co-founder proposes a feature, hold it against this sentence. If it does not fit, it goes to the backlog. This sentence also becomes the brief you hand to a developer or paste into a no-code builder like Base44 as the starting context for your build.
Step 6: Set a Hard Time Box
Decide the maximum time allowed to build and ship the MVP before you write a single line of code or configure a single workflow. For most digital products, a realistic range using modern AI-assisted development or no-code platforms is two to six weeks. Longer than that and you are not building an MVP, you are building a v1 product with MVP branding.
The time box is not a deadline you negotiate later. It is a constraint that forces scope discipline throughout the build. When a new idea surfaces during development, the question is not "is this a good idea" but "can this be built and still ship within the time box?" Usually the answer is no, which is the correct answer.
Step 7: Define What "Done" Looks Like
Before building, write down the two or three things a real user must be able to do successfully for the MVP to be considered complete. These are your acceptance criteria. They should map directly to the core loop identified in Step 4.
For the design feedback tool: (1) a client can open a shared link and see the design file, (2) a client can add a comment pinned to a specific area, (3) the designer can mark the comment resolved. If all three work end-to-end with a real user, the MVP is done. If any one of them fails, it is not.
This step prevents the common failure mode of shipping something that is technically built but does not actually work for the user it was built for.
How to Verify Your Scope Is Right
Run the finished scope document through three checks. First, can you describe the MVP to a non-technical person in under 30 seconds? If not, it is still too complex. Second, does every feature on the list appear in your acceptance criteria? If a feature is not tested by your done criteria, it should not be in the MVP. Third, would removing any single feature break the core user journey? If removing it would not break the journey, remove it.
A well-scoped MVP passes all three checks. Most first drafts fail at least one.
Common Mistakes That Break the Scope
Adding authentication too early is the most frequent offender. Many MVPs do not need user accounts at all. A shared link, a form, or a manual process can validate the core value proposition without building a login system. Save authentication for when you have users worth authenticating.
Building for edge cases before the common case works is the second. Edge cases are real, but they belong in v2. An MVP that handles 80% of users perfectly is more valuable than one that handles 100% of users adequately.
Scope creep from stakeholder feedback during the build is the third. The one-sentence product definition from Step 5 exists precisely to handle this. When feedback arrives, the answer is not "let's discuss" but "does this fit the definition?"
MVP Scope: What Belongs In vs. Out
| Feature Type | In MVP? | Reason |
|---|---|---|
| Core user action (the thing that delivers value) | Yes | Required for the core loop to function |
| User authentication / login system | Often no | Can be replaced by shared links or manual access in early validation |
| Admin dashboard / reporting | No | Requires existing data; new users have none |
| Email notifications | Usually no | Manual follow-up works until volume justifies automation |
| User roles and permissions | No | Premature complexity; single user type is enough to validate |
| Onboarding flow / tooltips | No | Validate the product works before optimising how users learn it |
| Third-party integrations | No | Integrations serve scale, not validation; defer to v2 |
Definitions
- MVP (Minimum Viable Product) — The smallest version of a product that delivers the core value proposition to a specific user and generates actionable feedback. An MVP is not a prototype or a demo; it is a working product with intentionally limited scope.
- First-Session Filter — A scoping test that asks whether a new user needs a given feature in their very first interaction to experience the product's core value. Features that fail this test are deferred to a later release.
- Core Loop — The minimum sequence of actions a user must complete to receive the primary value of a product. In MVP scoping, only features that are part of the core loop belong in the initial build.
- Acceptance Criteria — A defined set of conditions that must be met for a feature or product to be considered complete. In MVP scoping, acceptance criteria map directly to the core loop and are written before development begins.
- Time Box — A fixed, non-negotiable maximum duration set for building and shipping an MVP. The time box functions as a scope constraint: features that cannot be built within it are automatically deferred.
- Dependency Chain — The ordered sequence of features where each item depends on the previous one being functional. Mapping the dependency chain reveals the true minimum feature set required for the product to work.
What to Remember
- Write the problem statement before listing any features. A vague problem produces an over-scoped MVP every time.
- Apply the first-session filter to every feature. If a new user does not need it in session one to experience core value, it belongs in the backlog, not the MVP.
- Map the dependency chain to find the true minimum. The features at the top of the chain, the ones everything else depends on, are your MVP.
- Set a hard time box of two to six weeks before building starts. Treat it as a scope constraint, not a soft deadline.
- Write acceptance criteria before development begins. If a feature is not covered by your done criteria, it should not be in the build.
- Authentication, reporting dashboards, and third-party integrations almost never belong in an MVP. Defer them until the core loop is validated.
Common Questions
How many features should an MVP have?
Three to five features is the practical ceiling for a well-scoped MVP. Each feature must be part of the core loop, meaning the user cannot complete the primary action without it. More than five features almost always means the problem statement is too broad or the first-session filter was not applied rigorously enough.
How long does it take to scope an MVP properly?
A focused scoping session takes two to four hours for a single founder working through the steps with discipline. With a consultant or facilitator, a structured workshop can produce a complete scope document, including the one-sentence product definition and acceptance criteria, in a single half-day session. Rushing this step costs far more time during the build.
What is your pricing structure for product management consulting?
Pricing for product management consulting with Omer | Product & AI varies by engagement type: done-for-you MVP builds, scoping workshops, and ongoing advisory are each structured differently. The best way to get accurate pricing is to contact Omer directly through the website, where you can describe your project and receive a tailored proposal based on scope and timeline.
What is the pricing structure for the 1-on-1 product coaching sessions?
1-on-1 coaching sessions through Omer | Product & AI are priced per session or as a package, depending on the engagement. Specific rates are confirmed directly with Omer during an initial conversation, since session structure and frequency vary by what the client is building. Reach out via the website to get current pricing and availability.
Can a non-technical founder scope an MVP without a developer?
Yes. The scoping framework described here requires no technical knowledge. The output, a one-sentence product definition and a three-to-five-feature list with acceptance criteria, is something any founder can produce. Tools like Base44 allow non-technical founders to move directly from a scoped MVP into a working build without writing code.
What is the difference between an MVP and a prototype?
A prototype simulates a product to test a concept; an MVP is a working product that delivers real value to real users. Prototypes are useful for validating design decisions before building. An MVP generates actual usage data and user feedback on a live product. Confusing the two leads to shipping something that looks finished but cannot be used.
When should you expand scope beyond the MVP?
Expand scope only after the core loop works reliably for real users and you have evidence of demand, meaning users return, complete the core action, or pay. Adding scope before that evidence exists is building on an unvalidated assumption. The standard threshold used in product consulting is consistent usage by at least ten to twenty unaffiliated users.