MVP as a learning plan, not a cheap final product

Why this matters

An MVP is valuable only when it reduces an important uncertainty. A feature-light product that takes months to build but produces no decision is not minimum and may not be viable.

A usable framework

• Risk: the assumption most likely to invalidate the business
• Audience: the exact user or buyer who can test it
• Test: prototype, concierge service, landing page, data sample or limited product
• Signal: behaviour or payment threshold set before the test
• Decision: continue, change segment, change solution or stop

How to apply it

1. List the top assumptions across problem, demand, delivery and economics.
2. Rank them by impact and uncertainty.
3. Choose one test that can produce reliable evidence quickly.
4. Set the success and failure thresholds in advance.
5. Document what changed in the roadmap after the result.

Common mistakes

• Building the easiest feature instead of testing the biggest risk
• Calling a slide deck an MVP when behaviour cannot be observed
• Changing the metric after seeing weak results
• Adding features before deciding what was learned

The output you should have

The deliverable is an MVP experiment brief: assumption, participant, test, metric, threshold, result and decision. The software is only one possible component.

Immigration, residence, company and tax rules can change without notice. Treat this guide as structured orientation, not legal advice; verify the current official requirements before paying fees or submitting an application.