“Minimum viable product” often gets interpreted as a preview of the full roadmap. A little onboarding, a little dashboard, a little automation. The result has plenty of surface area but no moment where the user can say, “That solved it.”
Start with the smallest complete loop
A useful MVP takes one specific person from a problem they recognise to a result they care about. The path can be narrow. You can handle some work manually. The interface can offer very few choices. The important part is that the loop closes.
MVP definition
The smallest product that delivers the core outcome and gives you real evidence about the next decision.Both halves matter. The user needs value now, and the founder needs to learn from what happens. A prototype can test whether an idea makes sense. An MVP has to work for someone who does not care that you call it an experiment. Y Combinator makes the same practical point: customers experience an MVP as a product.
The four layers of a complete MVP
1. A precise promise 🎯
Name the person, the situation, and the progress they should make. “Plan a product” leaves too much room. “Turn a scattered idea into a first build plan” gives you something you can protect.
2. A clear trigger ⚡
Why would someone open the product today? Maybe the roadmap is blank, an AI handoff failed, or the MVP keeps growing. Without a real starting moment, onboarding becomes a tour of features nobody asked to see.
3. One core action sequence 🔁
Keep only the steps that collect essential context, make a real decision, or produce the result. Remove a step and check what changes. If the answer is “not much,” it does not belong in the core path.
4. An observable result 👁️
The user should be able to point to what changed. A saved document is not automatically an outcome. A build plan that makes tomorrow’s decision easier is.
The complete loop
Trigger → “I do not know what belongs in v1.”
Core action → Clarify audience, problem, value, and dependencies.
Result → A coherent plan the founder can review and build from.
Decide what ships with evidence, not anxiety
Cutting a feature can feel like lowering the ambition. It is usually the opposite: you are choosing which promise to take seriously first.
| Ship now when absence… | Move later when the feature… |
|---|---|
| Breaks the core outcome | Adds convenience after the outcome |
| Prevents a key assumption from being tested | Optimizes behavior that is not yet proven |
| Creates unacceptable trust or safety risk | Automates a manageable manual step |
| Makes the primary path impossible to understand | Serves a secondary persona or rare path |
| Blocks the founder from observing useful evidence | Improves scale before demand exists |
“Later” needs a trigger, not a hopeful date. Add collaboration when active users keep sharing exported plans. Automate recommendations when manual reviews start repeating the same pattern. Build templates when setup time is clearly the thing holding people back.
Minimum does not mean careless
Small scope is not permission to be careless. The MVP can do one thing, but that one thing still has to feel safe and dependable.
- Protect user data.Authentication, authorization, backups, and deletion rules are not decorative polish.
- Handle the main failure states.Empty, loading, invalid, interrupted, and retry states belong to the core path.
- Make the promise understandable.Users should know what will happen before they commit time or data.
- Meet the accessibility baseline.Keyboard access, focus, labels, contrast, and responsive layout are part of product quality.
- Observe the loop.Capture where users start, hesitate, complete, abandon, and ask for help.
A good shortcut saves implementation work without quietly making the user pay for it. A manual review can be smart. Losing someone’s work because saving was postponed is not.
Applying the model to Product Clarity
I have a long list for Product Clarity: research synthesis, different planning views, collaboration, agents, analytics, integrations, and impact analysis. Shipping a weak version of each would only delay the useful part.
The first complete outcome is much narrower:
- 01Capture the product context.
Audience, problem, desired outcome, constraints, and current assumptions.
- 02Shape the smallest valuable release.
Separate the core path from convenience, scale, and speculative scope.
- 03Connect the plan.
Map features, pages, flows, data, and dependencies into one understandable system.
- 04Make the next decision visible.
Show what to build, what to cut, and what will be affected by change.
If a founder completes that loop and makes a better build decision, the MVP has done its job. The next feature should fix friction I can see inside that loop, not a future problem I have invented.
A 60-minute MVP scope session
- 10 minutes: Write the promise.
For one user, in one situation, define one meaningful outcome.
- 15 minutes: Draw the happy path.
Start at the trigger and stop when the user can see the result.
- 10 minutes: Mark the quality floor.
Add the trust, safety, failure, and accessibility requirements the path needs.
- 15 minutes: Remove or defer.
Challenge every remaining item with the ship-now/later test.
- 10 minutes: Define evidence.
Decide what completion, failure, confusion, and repeated demand will look like.
Finish with one sentence you are willing to defend: “This release works when this user reaches this outcome, and we learn this.” If you need several audiences and outcomes to complete the sentence, the scope is still doing too much.
Reader response
Was this field note useful?
Comments
0Continue the system
Before building the MVP, write the trail while it is fresh.
Read field note 03Field notes by email
Thanks, you're on the list. ✓
Email signup did not go through. Please try again.
A short note when there is something worth sharing. No spam.
Loading reader responses…