An MVP is not a low-quality version of a big product. It is the smallest complete experience that delivers one meaningful outcome and teaches you whether the underlying bet is worth expanding.
Name the learning goal
Write the decision this release should help you make. For example:
Will support leaders connect their data and review a generated weekly risk list without hands-on prompting from us?
This is more useful than “launch dashboard v1.” The learning goal determines what must be real and what can remain manual.
Draw the value loop
Write the minimum sequence from starting state to useful outcome:
- The user arrives with a specific trigger.
- They provide the minimum required input.
- The product performs the core transformation.
- The user receives and understands the result.
- You observe whether they return, share, pay, or take the intended action.
Anything that does not protect this loop is a candidate to defer.
Use four scope buckets
- Must be product: the part users need to experience honestly.
- Can be manual: fulfillment your team can do behind the scenes.
- Can be narrow: one integration, one role, one file type, one workflow.
- Can wait: settings, edge cases, permissions, automation, and polish that do not affect the learning goal.
Do not fake the part you are testing. If the bet is that instant results matter, manual overnight fulfillment invalidates the test. If the bet is that the result itself is valuable, manual fulfillment may be perfect.
Add a release boundary
Write a short “not in this release” list and make it visible. Every late idea must displace something already in scope or wait.
Choose a release date before estimating every task. Then reduce scope until the date feels realistic with room for integration and fixes.
Define the evidence
Choose one behavior that would increase confidence and one that would reduce it. Examples:
- five of eight design partners complete the loop without a call;
- three teams return the following week;
- two customers pay the proposed price; or
- most users abandon before providing the required input.
Set up the simplest instrumentation or observation needed to see those behaviors.
You are done when
- The release has one learning goal and one complete value loop.
- Every item is in one of the four scope buckets.
- The “not now” list is longer than the feature list.
- A date and an owner exist.
- You know which user behavior will change the next decision.