Define minimum viable product (MVP)

Define the smallest buildable version of a product that tests your core assumption and delivers real value to early users.

Workflow · Product DevelopmentRole · Product Manager●●● AdvancedUpdated 2026-07-31

The prompt

Copy and customize

prompt.txt
**Role:** You are a Product Manager defining the MVP for {product_name} to launch in {target_timeframe}.

**Context:**
MVP is the most misunderstood concept in product development. It is not the cheapest version of your full product — it is the smallest experiment that tests your core assumption about what makes your product valuable. Building the wrong MVP wastes time building features users don't need. Building the right MVP gives you learning that shapes everything else.

**Task:**
Apply step-back thinking: first identify the core assumption your product bets on (the one thing that must be true for the product to succeed), then define the MVP as the minimum needed to test that assumption with real users. Then scope the build.

**Input Available:**
- {product_name}: Product name
- {problem_being_solved}: The specific problem you are solving
- {target_user}: Who the MVP is for
- {core_hypothesis}: Your hypothesis about why users will find this valuable
- {available_team}: Team size and skills available for the build
- {target_timeframe}: When you need to launch the MVP
- {success_criteria}: How you will know the MVP succeeded
- {full_feature_vision}: What you eventually want to build (to inform what to defer)

**Output Format:**
1. Core hypothesis: The one assumption the MVP must validate
2. MVP definition: What is included and why (trace each feature back to the hypothesis)
3. Explicitly excluded features: What is NOT in MVP and when it will be addressed
4. MVP success criteria: Specific, measurable signals that would validate the hypothesis
5. User journey for MVP: What the user experience looks like end-to-end
6. Build scope: Feature list with effort estimates
7. Risk: What could go wrong with this MVP definition
8. Post-MVP roadmap based on what you learn

**Guardrails & Quality Control:**
- If a feature cannot be directly tied to testing the core hypothesis, it is not MVP
- Success criteria must be measurable, not just 'users are happy'
- MVP must deliver real value to real users — it is not a wireframe or internal demo
- If the MVP takes more than {target_timeframe} to build, it is not minimal enough

How to use

Run this prompt in four steps

  1. 1Validate the core hypothesis with 10+ user interviews before defining the MVP.
  2. 2Involve engineering in scoping — product managers consistently underestimate effort.
  3. 3Build in a review checkpoint at 50% through the build to catch assumption changes.
  4. 4Define your learning plan before launch — what data will you collect and how?

When to use

When to use this prompt

Use when starting a new product or major feature that has not yet been validated with real users.

Limitations · Worth knowing

This prompt has limitations you must understand.

An MVP defined without user research is just a guess with a framework. Invest in customer discovery before defining the MVP.