Why it matters
Most product risk is not technical. It is whether people want the thing and will use it. An MVP answers that question early, before you spend on features nobody asked for. The idea was popularised by the lean startup movement, and it applies as much to an internal tool as to a new company.
How to decide what goes in
- Write down the one assumption that, if wrong, makes the product pointless.
- List the shortest path a user takes to reach the core value.
- Build only that path, with real data and a real way to measure it.
- Leave out everything else, even good ideas. Keep them in a backlog.
Minimum does not mean careless. Sign-in, payments and personal data still need to be secure from the first release. Cutting a feature is fine; cutting protection is not.
An example
Imagine a clinic that wants an app for booking appointments. The first version might offer one thing: pick a time slot and confirm it by message. Reminders, family accounts and payments wait until real patients show that booking is what they want. It might even be built with no-code tools at first. This is a hypothetical example, not our work.
Common mistakes
- Building too much. If it takes many months, it is not minimum.
- Building too little to be viable. Users should get real value, not a demo.
- Having no success measure, so you cannot tell what you learned.
- Treating the MVP as throwaway without deciding what happens next.