How to test a product idea before you build it

How can you find out whether a product idea is worth building before you spend time making it? Begin by finding out what people need, identifying what your idea depends on, and testing that assumption with something small enough to change. The aim is to gather evidence for the next decision. An encouraging conversation alone is too little to justify building everything.

Published guidance from Stanford d.school, Startup India and the UK government's Service Manual offers a useful route through this work. The UK guidance concerns public services. Here, its methods serve as advice for product testing, rather than compulsory rules for an Indian startup.

Start with the problem

The GOV.UK Service Manual advises understanding the problem before committing to build a service. If you already have a solution in mind, it recommends questioning it and defining the problem you need to investigate. This leaves room for the research to change what you build.

For your own idea, separate the proposed product from the need it is supposed to meet. Describe whose problem you want to understand and what you still need to learn about it. A feature is a possible response to that problem. First, find out whether your intended users actually face the problem it would solve.

This attention to customers also appears in the US National Science Foundation's I-Corps programme. It uses customer discovery to help teams assess the market potential of inventions. Discovery helps teams investigate whether an invention might sell.

Ask people about their experience

Choosing interviewees is part of the research. GOV.UK's guidance on in-depth interviews recommends speaking to current or likely users of the service being investigated. For your product idea, consider whether the people you can easily reach are also those whose needs you want to understand.

The same guidance favours stories and actual examples over general statements. Ask people to describe their experience of the problem and how they currently deal with it. Keep the conversation close to what has happened, rather than relying on what they imagine they might do with a future product.

In your notes, separate accounts of existing difficulties from approval of your proposed solution. A compliment or a hypothetical promise is not proof of a future purchase. These responses tell you different things, and you still need to test the product itself.

Identify what must be true

Stanford d.school's Experiment Expedition worksheet asks: "What must be true for our concept to work?" It then asks teams to prioritise critical and fundamental questions for testing. This turns a broad belief in an idea into assumptions you can test.

GOV.UK similarly advises identifying and testing the riskiest assumptions. The relevant risks depend on what is being built. Whether the product can be built may be just one question. Choose the first test to suit the product.

Write down what your idea depends on and choose the assumption whose failure would most seriously challenge it. Keep that statement separate from what you already know. A clear statement makes the assumption easier to investigate.

Decide what the test will measure

Before testing, decide what response would support the assumption and what would undermine it. Stanford's test-tracking worksheet explicitly asks for both. Set out both possibilities before seeing the responses, including any result you would rather not find.

GOV.UK's measurement guidance says to choose measures according to the hypothesis being tested. For usability, its guidance identifies task completion rates and the time taken to complete tasks as concrete measures. These measures help you find out whether people can use the design. Whether they want to buy it is a separate question.

If your claim is that the proposed approach improves an existing process, establish how that process currently performs. GOV.UK calls this a baseline. Use that comparison to judge whether the new approach improves on the existing process.

Keep the measurement tied to the question. Views or likes alone may not answer a question about customer need, ease of use or purchase demand. These sources give no universal passing percentage. The evidence you need depends on the assumption you are testing.

Build only enough to investigate

A prototype can be much simpler than a finished app. GOV.UK describes formats ranging from a quick drawing on paper to a prototype made in code, and advises choosing the format that meets the needs of the current test. Its guidance on testing risky assumptions says to do only the minimum needed to investigate them.

Focus on the part of the proposed experience that helps answer your question. Build enough to test that part. A paper sketch has limits when testing ease of use or whether something can be built. Choose the level of detail to suit what you need to learn.

For a usability test, define tasks and observe people attempting them. GOV.UK advises against giving away the answer or hinting at how to complete a task. Let people work through the tasks independently so you can see whether they can use the design unaided.

Separate a working prototype from demand

Startup India's description of the validation stage makes a useful distinction: even when a prototype is ready, potential demand still needs to be checked. It includes field trials and testing with potential customers among validation activities.

That distinction should shape how you report your findings. A prototype may work and be usable while demand remains uncertain. Report the conclusion that the test supports and keep the remaining questions open. A successful demonstration alone is not commercial success.

Stanford d.school describes prototyping as a process that typically passes through several stages before the eventual design is settled. Use the findings to revise the idea or prototype and identify what needs testing next. Consider results that challenge the assumption as well as those that support it.

What to do with your own idea

Begin with a problem to investigate and people who currently experience it or are likely users. Record what you learn, choose the critical assumption, and decide what evidence would support or weaken it. Then make the smallest suitable prototype, observe the test and compare the result with the question you set out to answer.

The useful outcome is a clearer decision about what to change, what to test again and what remains unknown. Be clear about which question you have answered and which parts of the business still need testing.

For practice, One Young India's Entrepreneurship in Action includes validating a real problem, modelling value and pitching what you build in its founder component.