What is an MVP? Test an early product with real users

What is the purpose of an MVP?

Michael Seibel’s Y Combinator lesson emphasises reaching users with a narrow offering and improving it through feedback. This is historical founder education, not a current investment announcement. It provides a useful approach rather than a universal timeline or success percentage. [1]

An MVP turns “does this look good?” into observable questions. Can a user finish the task, do they return, and where do they stop? A useful experiment produces information capable of changing the next decision, whether the initial result is encouraging or disappointing.

How do prototypes, demos and MVPs differ?

A prototype can illustrate appearance or interaction. A demo presents a particular sequence. An MVP attempts to offer testable value against a real user problem. The terms can overlap in practice, but the important issue is which assumption is tested through which behaviour.

Showing screens for an appointment product can test whether the design is understandable. Allowing someone to choose a real slot and complete a booking tests something different. Both may be useful, but visual approval should not be presented as evidence of successful use.

What could a small test look like?

Imagine a hypothetical appointment problem at small service businesses. Instead of a platform managing every aspect of the company, choose one business type and one sequence: receive a request, show availability and record a booking. Automated invoicing, loyalty features and advanced reports can remain outside the first scope.

The assumption is not simply that people want another application. It is whether the selected business can complete the appointment task through the proposed flow. Identify reachable users and an observable outcome before building. The example is a planning illustration, not a substitute for domain research or safety requirements.

What belongs in the first version?

KURUM.’s suggested worksheet contains four headings: customer, problem, essential action and measurement. For each proposed feature, ask whether the core assumption can be tested without it. If so, it may be deferred. Essential security, data protection and applicable requirements are not decorative features to discard.

Moving quickly should not transfer undisclosed risks to people. Products involving health, finance or physical safety require their own boundaries. A small scope does not automatically mean small responsibility. Establish the test setting and permitted data before participants begin using it.

Which measures are useful?

• How many users complete the essential action?
• Do they return when the need recurs?
• How much human help does completion require?
• Where do errors happen, and why?
• Which existing method does the customer replace?

A hundred registrations without use may establish little. Repeat use in a small group can be worth investigating without proving product-market fit. Measurement duration and the composition of the group should accompany the result.

What happens after the MVP?

Use the evidence to revisit assumptions before adding scope. A real problem with a difficult workflow may call for improvement. A problem users do not care about may require new customer research. Turning every comment into another feature can make the test’s purpose unclear.

An MVP is neither a funding guarantee nor a permanent excuse for an unfinished product. Its value is a better-informed next decision. Writing down which outcomes would lead to continuing, changing or stopping helps prevent development from becoming an endless activity without a learning objective.