How I make product decisions from idea to working SaaS
I do not start with a feature list. I start by finding the assumption that would make the rest of the project irrelevant if it were wrong. The MVP should be large enough to test that assumption and small enough to postpone almost everything else.
The first version of an idea is rarely a product. It is usually a mix of a problem, excitement, possible features and an imagined future. AI makes expanding that imagined future extremely cheap, which makes scope discipline more important.
An MVP exists to expose the most important assumption that might be wrong.
1. Start with the problem, not the product category
“I want to build a reading app” is not a problem. Describe the user, situation, friction and current alternative before discussing features.
type ProductProblem = { user: string; situation: string; friction: string; currentAlternative: string;};2. Narrow the first user
The first user definition does not need to describe the entire future market. It needs to be specific enough to make product decisions coherent.
3. Find the assumption that can kill the project
Problem existence, willingness to care, workflow comprehension, retention and monetization are different assumptions. I prioritize the one that would invalidate the most downstream work.
4. Cut scope by learning value
Three wrong features are still a bad MVP. A feature belongs in V1 if it tests the critical assumption, enables the core flow or is required for user trust.
function belongsInV1(feature: Feature) { return ( feature.testsCriticalAssumption || feature.isRequiredForCoreFlow || feature.isRequiredForTrust );}5. Write the core loop in one line
A product needs a repeated rhythm. If the core loop is unclear, the screen list tends to grow without hierarchy.
const coreLoops = { bookProduct: "add → read → update progress → choose next", feedProduct: "subscribe → scan → open/save → return", dailySystem: "capture → choose focus → act → close/review",};6. Make system decisions before visual polish
My preferred order is problem, core flow, domain model, boundaries, interface, polish. Beautiful AI-generated screens can make a weak model look more convincing than it is.
7. Choose technology around product risk
If demand is the major unknown, learning a new backend does not reduce that risk. I prefer proven defaults until product requirements create a real reason to change.
8. Keep an intentionally-missing list
A roadmap says what may be built. V1 also needs a clear list of what is deliberately excluded so scope does not expand by default.
9. Think about monetization before it infects the architecture
You do not need a paywall on day one, but if the product will be paid, entitlement and value boundaries should not be an afterthought.
10. Launch starts measurement
The first real information arrives when users install, activate, complete the core action, return or fail. Small samples are not statistical certainty, but repeated behavioral and qualitative signals are valuable.
11. Feature requests are data points
A user usually describes a solution from their own context. I try to extract the underlying problem, signal frequency and product fit before turning it into backlog work.
12. MVP does not mean unreliable
Minimal applies to scope, not basic trust. If data disappears or the primary mobile flow is broken, the user is testing bugs rather than the product hypothesis.
My practical order
- Write the behavioral problem
- Narrow the first user
- Choose the critical assumption
- Define the core loop
- Include only loop, trust and validation requirements
- Write the intentionally-missing list
- Use proven technology by default
- Verify the real core action
- Observe post-launch behavior
- Ask whether simplification beats another feature
Conclusion
Software production is becoming cheaper. Product judgment is not. I think of an MVP as a compact learning system that should produce enough reality to make the next decision better.
const goodMvp = { scope: "small enough to finish", experience: "good enough to trust", hypothesis: "important enough to matter", feedbackLoop: "fast enough to learn",};