Avoid costly mistakes: Test your idea before you build it

How do you avoid spending months – or even years – developing a product only to discover that customers do not need it?

A Minimum Viable Product, or MVP, can help you test the assumptions behind your idea before you commit extensive time and resources to development.

But an MVP is not simply an unfinished version of the final product. To create a useful MVP, you must know what you are trying to learn, which evidence you need and what you will do with the result.

What is a Minimum Viable Product?

The concept comes from the Lean Startup approach. An MVP is the version of a new product or experiment that enables a team to obtain the greatest amount of validated learning with the least effort.

The emphasis is on learning – not on releasing as many features as possible with minimal development.

Depending on the question, an MVP might be:

• a landing page that measures whether people respond to a value proposition
• a clickable prototype that tests whether users understand a workflow
• a manually delivered service that simulates a future automated solution
• a limited working product used by a small group of early adopters

These approaches do not provide the same kind of evidence. A landing page may indicate interest, but it cannot show whether people can use the product successfully. A prototype may reveal usability problems, but not whether customers are willing to pay.

The right MVP is therefore the smallest credible experiment that can test your most important assumption.

Begin with the assumption – not the solution

Before deciding what to build, ask: What must be true for this idea to succeed?

Your critical assumptions may concern:

• desirability: Do customers experience the problem, and do they want the proposed solution?
• feasibility: Can the organisation develop and deliver the solution?
• viability: Can the product create sufficient value for the organisation?
• usability: Can the intended users understand and use it?

You do not need to test everything at once. Start with the assumption that is both critical to the idea and supported by the least evidence.

If that assumption proves false, you may need to change the idea before investing further.

When is your MVP ready to be tested?

An MVP is ready when it can generate evidence that supports a real decision. Three questions can help you assess it:

1. Does it test a specific assumption?

“We want feedback on our idea” is too broad. Define precisely what you need to learn – for example, whether a particular user group experiences the problem frequently enough to seek a solution.

2. Is the experiment credible enough?

The MVP must be realistic enough for the test participants to respond meaningfully. If a prototype is too unclear or incomplete, you may end up measuring confusion about the test rather than interest in the idea.

Minimum does not mean careless. Safety, legal requirements and professional standards still apply.

3. Do you know how the result will affect the project?

Define what you will measure and what different outcomes will mean before conducting the test.

What evidence would justify continuing? What result would make you revise the idea? At what point would you stop development?

Without these criteria, teams risk collecting feedback without learning anything that changes their decisions.

Choose the test that matches your question

Different methods answer different questions:

Landing pages and sign-up tests

Use these to investigate whether a specific value proposition attracts attention or prompts people to take an observable action.

Clicks alone provide weak evidence. A sign-up, request for contact or other meaningful commitment usually says more about genuine interest.

Clickable prototypes

Use wireframes or interactive prototypes to test workflows, comprehension and usability before developing the underlying system.

Concierge and Wizard of Oz tests

Deliver the service manually while presenting users with an experience resembling the intended solution. This can help you test whether the service creates value before investing in automation.

Be transparent whenever the setup, collection of personal data or nature of the service makes disclosure necessary.

Limited releases and beta tests

Give a defined group access to a working version and observe how they actually use it. This can provide evidence about behaviour, retention and operational feasibility.

Common MVP mistakes

Building too much

Teams may include features because they expect them to be useful rather than because they are necessary for the current test.

Begin with the learning objective and remove everything that does not help test it.

Building too little

An experiment can be so limited or unconvincing that users cannot respond meaningfully. In that case, rejection may reflect the quality of the test rather than the value of the idea.

Measuring attention instead of behaviour

Page views, likes and positive comments can look encouraging without demonstrating genuine demand. Whenever possible, measure actions that require effort or commitment from the user.

Testing too many assumptions at once

If an experiment changes the value proposition, target group, price and user experience simultaneously, it becomes difficult to understand why it succeeded or failed.

Treating the MVP as the finished product

An MVP is part of a learning process. It should lead to a decision: continue, adjust the idea, run another experiment or stop the project.

Build, measure, learn – and decide

The purpose of an MVP is not to prove that your original idea was right. It is to reduce uncertainty while the cost of changing direction is still relatively low.

Start by defining what you need to learn. Choose an experiment capable of producing relevant evidence. Then use the result to make an explicit decision about the next step.

The sooner you test the most critical assumptions, the less likely you are to spend resources developing a solution that nobody needs.