Your idea. Tested before built.

How to validate a product idea by testing your riskiest assumption

Every product idea rests on a handful of beliefs. People have this problem. They care enough to change how they work. They would trust a new tool with it. Your solution actually solves it. Validation means checking those beliefs against reality before you spend a full budget on them.

You do not need to test them all at once. Start with the one that, if it turns out to be wrong, makes the rest irrelevant. That is your riskiest assumption. For one idea it is whether the problem is painful enough. For another it is whether the technology can deliver, for example whether an AI feature gives good enough answers on real data.

Once you know what you are testing, the rest follows. You build only what is needed to put that one question in front of real people, you decide in advance what result would convince you, and you run the test. A prototype is the tool that makes this fast.

• List the beliefs your idea depends on, in plain sentences.
• Pick the one that would end the idea if it were false.
• Decide what you would need to see to call it confirmed.
• Build the smallest thing that lets people show you.
• Run the test, then decide: continue, change or stop.

Why conversations alone are not enough to validate an idea

Talking to potential users is the right first step. It shows you how they describe the problem, what they do about it today and what it costs them. Those conversations are cheap and often reshape the idea before anything is built.

But opinions about a product that does not exist are unreliable. Most people are polite. They will tell you an idea sounds useful, and then never use it. Asking whether someone would use something tends to produce a yes that means very little.

A prototype changes the conversation. Instead of describing an idea, you hand someone a thing and watch. Do they understand it without help? Do they finish the task? Do they ask when they can use it for real? Behaviour is much harder to fake than enthusiasm, which is why it makes better evidence.

Choosing the right kind of prototype for idea validation

Prototype is a broad word, and the right kind depends on what you are trying to learn. A prototype built to test whether people understand your concept looks very different from one built to test whether the technology works.

Choose the lightest option that answers your question honestly. If you are testing whether people grasp the value, a clickable demo may be enough. If you are testing whether an AI feature works on real documents, you need something that runs on real documents, even if the screens around it are rough.

• Clickable demo: tests whether people understand the concept and the flow.
• Working prototype: tests whether people complete a real task with it.
• AI proof of concept: tests whether a model performs well enough on your data.
• Manual behind the scenes: tests demand while a person does the hard part.
• Landing page with a sign-up: tests interest before anything is built.

How to run a prototype test with real users

Start by finding people who match the user you have in mind. Five to ten good sessions tend to reveal the biggest problems, because the same issues show up again and again. Friends and family make poor testers: they know you, and they are rarely the target user.

Give each person a realistic task rather than a tour. Ask them to do something they would actually want to do, then stay quiet and watch. Note where they hesitate, where they get stuck and what they say out loud. Resist the urge to explain; the moments you want to explain are the findings.

After the task, ask about the past rather than the future. How do you handle this today? When did it last happen? What did it cost you? Those answers anchor what you saw in real behaviour and tell you whether the problem is as big as you thought.

Reading the results and deciding what comes next

Go back to what you wrote down before the test: the result that would convince you. Compare what happened against it honestly. Strong signals look like people completing the task, asking to keep using it, or offering to pay or to introduce a colleague. Weak signals look like polite praise followed by silence.

There are three sensible outcomes. The assumption holds, and you move on to the next riskiest one or start scoping a first product. The idea is right but the solution is not, and you change it and test again. Or the problem is not big enough, and you stop. That last outcome feels like failure, but finding it out early is exactly what validation is for.

Keep a short record of each round: what you tested, what you saw and what you decided. It keeps the team honest, and it becomes useful evidence when you talk to investors or partners later.

How Walhallah builds prototypes for idea validation

We start by helping you name the question the prototype needs to answer. Then we build only that, with AI at the core of how we build, so a focused prototype is often ready in days rather than weeks. That puts something real in front of people while the idea is still cheap to change.

When the test is done, you get a plan for what is next: what the evidence says, what still needs testing, and what a first product would need if you decide to go ahead. Sometimes the honest advice is to change course, and we would rather tell you that after days than after months.