Validate an Idea before Building an MVP

Separate the idea from the problem

Suppose you want to build a resource-management product for independent trainers. That is a solution idea. The underlying problem might be version confusion, time spent answering repeated questions or participants losing access after a session. Those are different problems with different buyers and possible solutions.

Write a problem statement naming one person, one situation, the current workaround and the desired outcome. Keep assumptions visible. You do not need to prove the entire business before taking a step, but you should know which belief that step is intended to test.

Talk about recent behaviour

Interview people who recently experienced the situation. Ask how they handled their last session, what materials they shared, which tools they used and where the process broke down. Explore alternatives and consequences before presenting your product. Record direct evidence separately from your interpretation.

A small interview sample is useful for discovery, not a statistically representative claim about every trainer. Look for repeated patterns and important contradictions. If one person’s difficulty comes from a unique organisational policy, do not automatically generalize it into a universal product requirement.

Rank the assumptions

Choose one small experiment

For the resource-management idea, a manual service may be more informative than a full platform. Help a few trainers organize the materials for an upcoming session and observe whether participants can find what they need. Make the manual nature of the service clear and use only data you are authorized to handle.

Write the test audience, duration, observable behaviour and decision rule before running it. For example, decide which task-completion evidence would justify another iteration and which result would send you back to problem discovery. Avoid changing the goal after seeing a weak result.

Scope a complete MVP journey

If the experiment supports further work, define one complete journey: a trainer creates a resource collection, a participant opens the correct collection and the trainer can correct a missing or outdated item. Keep authentication, access and error handling appropriate to that journey. Remove optional features such as badges or complex analytics until evidence requires them.

Write acceptance criteria in user-facing terms. A participant should know which session the materials belong to, whether an item is available and how to report a problem. A collection of attractive screens that never completes the task is not a useful test of the product’s core value.

Measure outcomes and interpret them carefully

Track whether the intended task was completed, where people needed help and whether they returned for the next relevant session. Use activity metrics as diagnostics rather than treating every click as success. Record support work and manual effort so the apparent product experience does not hide an unsustainable operating burden.

A positive early result supports the next bounded experiment, not a guaranteed market outcome. A negative result may indicate the wrong audience, an unclear problem or a poor implementation. Use interviews and observed behaviour to distinguish those explanations before adding more features.

Create the decision memo

• Problem statement and intended audience.
• Evidence from recent behaviour, with sample limitations.
• The assumption tested and the experiment design.
• Observed results, including failures and contradictions.
• The decision to continue, revise or stop.
• The next smallest step and its remaining uncertainty.

Keep this memo short enough to guide the next week of work. The aim is to reduce uncertainty through useful evidence, not to produce a document that makes the original idea look correct regardless of what happened.