An MVP that answers business questions

Choose the question the product must answer

Does the recipient have a sufficiently painful problem? Can they use the solution independently? Do they return and want to pay for it? These are different questions that require different experiments. Do not try to test all of them simultaneously by adding more features. Write down one assumption whose falsity would undermine the rationale for the investment.

Demonstration example: A portal for subcontractors aims to reduce email exchanges when reporting availability. The first test can check whether companies actually update their data without reminders. Advanced reports and a recommendation system will not help if the basic information still requires collecting it via phone calls.

Context and references: Google Design: Design Sprint Kit

Limit features, preserve the full task

The user should be able to move from need to result. For a purchasing portal, this means finding the right product, understanding the terms, and placing a correct order. You can limit the number of products or the companies served. It is not worth removing information needed to make a decision just because the interface looks simpler that way.

Some backend operations can initially be manual, provided this is a conscious and feasible choice. Document the cost of such support and the scale limit. Do not call a process automated if a human performs it. Honest limitation allows you to investigate the need without investing in every mechanism before confirming demand.

Measure behavior after the first impression

Praise for a prototype is not equivalent to using the product. Observe task completion, return within the natural work cycle, and drop-offs. Ask what the user did instead of using the solution. The alternative is often a spreadsheet, a phone call, or nothing, rather than a competing application.

Define events that correspond to value. Registration is an intermediate step. For a bidding tool, a better signal might be the use of an accepted draft. Collect data proportionally to the goal and with respect for privacy. For the first test, you do not need to track every cursor movement if interviews and a few consciously selected events are sufficient.

Define the decision before seeing the results

Write down the conditions for development, pivoting, and termination. This prevents the team from retrospectively selecting only favorable metrics. Consider the nature of the product: a tool used once a quarter should not be evaluated based on daily returns. The length of the experiment must correspond to the natural cycle of the need.

After the test, distinguish between a lack of value and a problem accessing it. If users want the result but cannot complete the configuration, improve onboarding. If they complete the task but see no reason to return, investigate the problem itself. The next stage should result from this diagnosis, not from a pre-written list of features created before the first conversation.