Minimum is about scope, not care.
An MVP — minimum viable product — is an early version built to test an important assumption with real users. For our projects, ‘viable’ means a person can complete the essential job and the team can learn from what happens.
A booking product might first need to prove that customers will choose an available slot and that the business can reliably honour it. Loyalty points, a referral programme and a complex dashboard do not help answer that first question.
Write down what would change your mind.
Before a feature list, agree what you need to learn. Who will try it? What task will they attempt? What behaviour would suggest that the idea is useful? What result would make you change the approach?
Small numbers of early users can reveal usability problems. They do not automatically prove a market. Keep observations, assumptions and commercial evidence separate when deciding what to build next.
Cut the surroundings, protect the core.
We prefer one complete, understandable journey to five half-built ones. Some internal work can be manual at first if the team can handle it and the user’s expectation is still met.
- One clearly named user and problem.
- An end-to-end task, including failure and recovery.
- A feedback channel and a way to observe completion.
- Basic safeguards for the data and permissions involved.
- A decision point: continue, change direction or stop.
Plan the next decision, not every future screen.
An MVP is useful when it reduces uncertainty. Review what people did, where they needed help and whether the problem mattered enough for them to return. The next release should respond to that evidence.