MVP: test the idea before building everything

A minimum viable product is an initial version that lets a team test an important assumption with real users. Minimum refers to scope, not a broken core experience. People need to receive the promised benefit so the team can learn whether to continue.

Imagine a booking service for a small workshop. A useful assumption is that customers can select an available appointment and complete their booking without calling. This is more specific than saying people need a convenient app.

The workshop example needs available times, a service choice, contact details and confirmation. Loyalty points, extensive analytics and an account area can wait if they are not needed to test that assumption.

However, an occupied slot must not look available, and confirmed bookings must not disappear. A failure in the core journey reveals an implementation problem rather than a lack of interest. Separate optional features from the conditions required to deliver the promise.

Before launch, write down the questions: do people understand the service choice, reach confirmation and still need to call? Count both completions and the people who had access to the journey. Speak to those who stopped rather than guessing why.

Test under conditions close to actual use. If a staff member guides every participant, the results do not establish that the service works independently. A small group and short trial provide early evidence, not a precise forecast of demand.

Use the observations to choose whether to extend the journey, remove an obstacle or rethink the idea. Do not add features simply because they appeared in the original plan.

If workshop customers repeatedly misunderstand appointment duration, clarify the time selection first. Adding a review section will not resolve that issue. The useful outcome of an MVP is an informed decision about the next version.