“Minimum viable product” is often misread as “the cheapest thing we can ship”. A better definition is the smallest release that real users can rely on to complete a real task, and that teaches you what to build next.
Choose one complete journey
Instead of building a little of every feature, pick one end-to-end journey and make it work properly. For an ordering system, that might be: a customer places an order, staff confirm it, and the customer is notified. A complete narrow journey is more valuable than a wide set of half-finished screens.
Keep the non-negotiables
Some qualities cannot be postponed, even in a first release:
- Data integrity: records must be correct and recoverable.
- Security: access control, safe password handling and protection of personal data.
- Usability for the core task: if the main journey is confusing, users will return to the old way of working.
- Basic support: someone must be able to fix problems and answer questions.
Cutting these to save time usually creates more work later.
Defer the rest deliberately
Make a visible list of what is not in the first release, with a short reason for each item. Typical candidates are advanced reporting, rarely used settings, automation of edge cases and integrations that can be handled manually for a while. A written list prevents scope from quietly creeping back in.
Use manual workarounds intentionally
Early on, it is often acceptable for an administrator to handle an uncommon case by hand. This lets you learn how frequent the case really is before investing in automating it.
Plan how you will learn
Decide in advance what you want to find out from the first release. Do users complete the journey? Where do they hesitate? Which requests come up repeatedly? Simple usage measures and regular conversations with users are enough to guide the next release.
Signs the scope is right
- It can be described in one or two sentences.
- A specific group of users can replace part of their current process with it.
- The team can explain what was left out and why.
- There is a realistic plan for the second release.
A minimum viable product is a starting point, not a finished system. Its job is to deliver value early and reduce the uncertainty around everything that follows.
