Start with the uncertainty, not the feature count
An MVP is useful when you do not yet know whether people need an offering, will use a particular approach or can obtain the promised benefit. Begin by naming the uncertainty. “We need to launch something small” does not tell you what to build. “Will local offices order a recurring shared lunch?” gives you a more useful focus.
Write a hypothesis that connects a group, a situation and expected behaviour. Then decide what experience would let you observe that behaviour. This can lead to a smaller and more informative offering than cutting a long feature list in half while keeping the original assumptions untouched.
Preserve a complete piece of value
A small scope should still support a coherent task. If customers can select a lunch but cannot understand collection or receive the food, the experience does not test the intended value fairly. It mostly tests their tolerance for an incomplete service. Include the practical steps needed to fulfil the promise you actually make.
You can narrow the audience, service area, choice or operating times. These are often more useful reductions than removing essential reliability. Explain the boundaries clearly so people can decide whether the offer suits them. Minimum is a choice about learning scope, not a general excuse for avoidable confusion or careless handling of customer information.
An illustrative lunch service example
Imagine a fictional café considering a recurring lunch service for nearby offices. Instead of building a complex ordering platform, it offers a limited menu on specified days, takes requests through a simple form and coordinates preparation manually. Customers receive clear information about availability, collection and how to ask for help.
The café observes whether offices order again, what coordination problems arise and whether staff can fulfil the promise consistently. This is an illustrative approach, not evidence that the business idea will succeed. Manual handling may be acceptable for this learning stage, but the café records the work involved rather than treating it as free or infinitely expandable.
Distinguish an MVP from other early artefacts
A prototype helps explore an idea or interaction and may simulate a service that does not operate. A proof of concept investigates whether a particular approach is feasible. An MVP focuses on useful learning from an early offering. The terms can overlap in everyday conversation, so state what a specific trial actually allows people to do.
A sign-up page can test interest in a message, but it does not establish successful use of the service. A working ordering flow can test a transaction, but it may not establish repeat demand. Match the claim to the experience observed. Calling every early artefact an MVP can hide which important assumptions remain untested.
Decide what you will observe
Choose evidence that relates directly to the question. For the café, completed orders, repeat requests, cancellations and preparation effort provide different information. Compliments alone may be encouraging without explaining whether the service fits an office’s routine. Combine observed behaviour with questions about difficulties, alternatives and reasons for not returning.
Define in advance what would make you continue, change the offer or stop. The criteria should fit your situation rather than borrow an impressive benchmark from another business. Allow for an inconclusive result. A short trial with a narrow group may reveal useful obstacles while leaving the overall level of demand uncertain.
Be honest about manual work and boundaries
You can perform some behind-the-scenes work manually while customers experience a coherent service. Keep an internal record of those steps and their effort. Otherwise, a smooth early experience may conceal a workload that prevents the approach from operating more broadly. This is especially important when the founder quietly handles every exception.
Avoid misleading customers about what is available or what has been automated. State any limitations that affect their decision or support needs. Plan how to handle errors, cancellations and the end of the trial. The learning goal does not remove the responsibility to deliver the limited promise you have chosen to make.
Turn observations into the next decision
After the trial, separate what happened from your interpretation. “An office ordered again after changing collection time” is more specific than “customers love it”. Consider alternative explanations: personal relationships, unusual events or extra attention may have influenced behaviour. These factors do not make the trial useless, but they limit the conclusions you can draw.
Validation gathers evidence for a defined purpose; it does not prove that a business will succeed in every setting. Use the findings to choose the next question. You might refine collection, test another customer group or decide that the operational burden is too high for the benefit the offer creates.
A small planning sheet before you build
Write down the intended customer, the problem, the assumption, the smallest coherent offer and the observation that matters. Add what is deliberately excluded, who handles support and when you will review the result. This makes hidden work visible and prevents attractive extras from consuming the capacity needed to learn.
Then ask whether a simpler method could answer the question first. An interview may clarify a problem before any product exists; a prototype may expose confusion before real ordering begins. Choose the least elaborate approach that can generate relevant evidence. Build an MVP when actual use is the missing information, rather than because the label sounds like a necessary project stage.
Common questions
Must an MVP be software?
No. It can be a service, a physical offering or a combination of manual work and simple tools. What matters is a coherent experience that helps answer an important assumption. The delivery method should match the question and the people involved.
Does a successful MVP mean we should scale immediately?
No. It may justify another step while leaving questions about repeat demand, operations, costs and wider use unanswered. Check which conditions made the early result possible and whether they can be maintained as the offer changes or reaches more people.