How to pick the one outcome your MVP must prove

“We need an app” describes a proposed solution. “Will independent consultants book and pay for this service without a sales call?” describes an uncertainty. The second statement gives the team a way to choose the first journey and recognise useful evidence.

Write down the customer, the problem and the behaviour you hope to see. Be specific about the context. A user who signs up after a personal demonstration is not the same as someone who finds the product independently. Both observations may be useful, but they answer different questions.

A compliment is encouraging, but it is weak evidence of a workable product. Choose an action close to the value you want to deliver: completing a first booking, submitting a real document or returning to repeat a task. If payment matters, plan how you will test willingness to pay rather than assuming free usage will translate into purchases.

Define success and the observation window before launch. An illustrative target might be a certain number of invited users completing the core task within a week. The number should reflect the experiment and available audience. It is not a universal benchmark.

Map what a person needs to do from arrival to the successful outcome. Include necessary trust, permission, confirmation and error recovery. A small product still needs to tell someone when a payment fails or a booking is not confirmed. Those are parts of the journey, not optional polish.

Then challenge every proposed feature. If it does not help the user complete the task, let the team observe the result or protect essential data, put it on a later list. Manual work behind the scenes can be appropriate during a test, provided someone owns it and the user experience remains honest.

A useful experiment can show that your first assumption was wrong. Agree what you will do if people start but do not finish, finish once but do not return, or ask for a different outcome entirely. Instrument the key steps and arrange short follow-up conversations with participants.

At the end of the test, compare behaviour with the original question. Resist turning every comment into a feature request. First decide whether the product is delivering the intended value. That decision will give version two a stronger direction than a long list of unrelated improvements.