Frame the problem
Write down who has the problem, what they do today, and why the current alternative is not enough.
The build method
Make the next decision smaller.
A reliable MVP process turns a large unknown into a sequence of testable decisions. The goal is not to follow a theatre of “discovery” and “delivery.” The goal is to learn quickly without building the wrong thing too well.
Five moves
From uncertainty to a useful release.
Each step exists to reduce a different risk. If a step does not change the decision you need to make, it may not belong in the MVP.
Choose the evidence
Define the one signal that would make you continue, change, or stop: activation, payment, reply, booking, or repeated use.
Cut the scope
Keep the smallest workflow that can produce that signal. Put every tempting “also” into a later version list.
Build the core loop
Implement the real path from entry to outcome, including the failure states that would make the result meaningless.
Ship and observe
Deploy to a small audience, collect evidence, and decide what to improve, remove, or validate next.
Decide explicitly
Write down what you learned and what the next version is for. An MVP without a decision is just unfinished software.
Definition of done
The first release should be usable, measurable, and ownable.
Before a build is called done, the person receiving it should be able to explain what it does, run it, find the important data, and know what is deliberately missing.
The core action works
A real user can complete the intended outcome without a developer acting as a manual backend.
The success signal exists
The product captures the event or feedback needed to decide whether the hypothesis is worth pursuing.
The handoff is clear
Code, configuration, accounts, deployment steps, and known limitations are documented.
Common failure modes
Most expensive features are usually the least important ones.
If the team cannot say what evidence a feature produces, that feature is probably a preference, not a requirement.
| Instead of | Start with | Why |
|---|---|---|
| Building every requested feature | One measurable workflow | It shortens the distance to real evidence. |
| Polishing before launch | Clear feedback paths | Usability is learned through use, not internal approval. |
| Adding integrations too early | Manual operational handoff | Manual learning can reveal which integration is actually worth building. |
| Promising a complete platform | A narrow first promise | Specific users are easier to understand and serve. |
Start with the question
What must be true for this idea to be worth continuing?
Send that question, or a rough description of the product. I will reply with the smallest responsible way to test it.