Skip to content
Back to Idea Validation

MVP Scope

Define exactly what is in and out of the MVP — the smallest thing that tests your core hypothesis.

Why

MVP scope is the most over-used and under-defined term in product development. "Build an MVP" without a defined scope becomes "build everything we can in a month". A proper MVP scope is the smallest set of functionality that tests your single riskiest assumption — usually "will they use/pay for this?". Everything else is out. This is painful because it means cutting features you know users will eventually want, but including them delays the learning that tells you whether to build them at all. A 4-week MVP that tests the core hypothesis beats a 4-month MVP that builds the full vision — you learn 3 months sooner whether to pivot or proceed.

When

After fit scoring passes, before any engineering. Takes 1-2 days of debate + definition. Lock the scope before building.

How

1. State the single hypothesis the MVP tests
   - Not "build a changelog tool" — "devs will pay $15/mo to auto-generate changelogs"
   - Everything in the MVP must serve testing THIS hypothesis

2. List all features you imagine for the full product
   - Brainstorm freely — this is the vision, not the MVP
   - Group into: core (tests hypothesis), supporting (needed for core to work), future (not now)

3. Move features to MVP only if they pass 3 tests
   - Does the hypothesis fail without this feature? (if no, it is future)
   - Can we test the hypothesis without this feature? (if yes, it is future)
   - Is this feature needed for the core loop to function? (if no, it is future)

4. Define the MVP's core loop
   - The minimum sequence of user actions that tests the hypothesis
   - Example: "connect repo → push commits → see generated changelog → copy it"
   - Every step must be present; no step can be skipped

5. Define what is explicitly OUT
   - Write a "not in MVP" list: no auth (use magic links), no teams, no integrations, no settings page
   - This list is more important than the in-list — it prevents scope creep

6. Set a time box
   - Maximum 4-6 weeks for a solo dev!dev, 2-3 for a team
   - If it does not fit, cut more — the time box forces honesty about scope

Example

Product: an AI changelog generator.
Hypothesis: "solo devs will pay $15/mo to auto-generate changelogs from git commits."

Full vision features (20):
  AI generation, git integration, custom templates, team sharing, Slack/Discord publish,
  semantic versioning, release notes styling, multi-repo, changelog hosting,
  AI tone adjustment, export to PDF, API access, webhooks, custom branding, ...

MVP scope (passes 3 tests):
  - GitHub OAuth (needed for core loop) ✓
  - Connect one repo ✓
  - Generate changelog from commits (the hypothesis test) ✓
  - Copy-to-clipboard (needed to use the output) ✓
  - Stripe checkout at $15/mo (the hypothesis test) ✓

Explicitly OUT of MVP:
  - No custom templates (use one good default)
  - No team sharing, no Slack publish, no multi-repo
  - No API, no webhooks, no PDF export
  - No settings page (hardcode all config)

Time box: 3 weeks solo.
Core loop: connect repo → push → see changelog → copy → (pay $15 to keep using)

Common Problems

  • ⚠Defining the MVP as a smaller version of the full product — an MVP is a hypothesis test, not a feature subset; features that do not test the hypothesis are out regardless of size.
  • ⚠Including features because they are "easy to add" — easy features still take time, add surface area, and distract from the core loop; keep them out.
  • ⚠No explicit out-list —!out-list — without a written "not in MVP" list, scope creeps during building as each feature feels small and reasonable.
  • ⚠No time box — without a deadline, the MVP expands to fill all available time, and you learn later than you could have.

Best Practices

  • ✓Write the hypothesis as a testable statement before listing features — "devs will pay $15/mo" is testable; "devs will like it" is not.
  • ✓The out-list is more important than the in-list — review it daily during building; if you are building something on the out-list, stop.
  • ✓Set a hard time box and cut scope to fit — it is better to ship a smaller MVP on time than a bigger one late (you learn sooner).
  • ✓Define the core loop as a sequence of user actions — if any action is missing, the loop is broken and the hypothesis cannot be tested.