An MVP is a learning system
A minimum viable product is not the cheapest version of every future feature. It is the smallest credible product that lets a real user complete the core job and gives the team useful evidence.
Scope gets clearer when you write the decision the release must support: will this audience adopt the workflow, pay for the outcome, or switch from the current workaround?
Define one complete path
Choose the primary user and map one end-to-end success path. Supporting features should exist only when that path depends on them.
- What triggers the user to begin?
- What information must they provide or receive?
- What is the moment of value?
- What must happen after success or failure?
Defer flexibility before reliability
Advanced customisation, edge-case roles, broad integrations, and sophisticated reporting often arrive too early. A narrower product that completes its core job reliably is more valuable than a flexible system whose critical path is fragile.
Document deferred work and the signal that would justify it. That turns ‘not now’ into a product decision rather than a forgotten promise.
Keep technical shortcuts visible
Speed can justify temporary decisions, but invisible debt becomes expensive. Label prototypes, document assumptions, add basic observability, and protect data boundaries from the start.
The goal is not enterprise architecture on day one. It is a first release that can be understood, measured, and deliberately improved.