Define an MVP around one completed task
Scope a first release by the customer outcome rather than the feature count.
Name the beginning and the end
Minimum viable product is easier to discuss when the team agrees what a customer can finish. Write the trigger, starting information and intended result. For a fictional equipment-booking product, the task might start when a technician needs a tool and end when the technician has a confirmed collection slot. A catalogue alone does not complete that task.
Include the awkward middle
Walk through missing inventory, unavailable time slots and a changed request. These cases expose work that a happy-path prototype can hide. Decide which exceptions the product handles and which receive a visible human handoff. Manual support can be a deliberate learning tool, but customers should know when a person is reviewing their request and when to expect a response.
Make omissions explicit
List features that can wait, such as recommendations, multi-location reporting or elaborate customization. Explain why each omission does not prevent the first customer from completing the chosen task. A small release still needs clear labels, sensible errors and recoverable actions. Cutting those basics can make the experiment measure confusion rather than the value of the idea.
Watch completion before expansion
Observe a few customers attempt the task without coaching every step. Record where they pause, abandon or ask for help. Compare the result with the process they used previously. Use those observations to revise the workflow before adding another customer group. Your next action is to write an acceptance scenario that a teammate can test from beginning to end.
