Product validation is finding out whether the idea holds up before you spend a quarter building it. We work out which question is actually load-bearing, run the method that answers it with people who match your brief, and come back with a build, change or stop recommendation.
Book a free 30-min callProjects from €399.
Most research that gets called validation is reassurance with a sample size. People are shown an idea and asked what they think, they say something encouraging because disagreeing is awkward, and the deck that comes out of it reads as a green light. Nothing in the design of the study could ever have produced a red one.
Validation is the opposite instinct. You write down what has to be true for the idea to work, then you go looking for the cheapest way to prove it false. If nothing in the study could stop you building, you have bought a description of the market rather than a decision about your product.
These fail independently, and they fail for different reasons. A concept can win decisively while the demand behind it is far too thin to fund a roadmap, which is the most expensive way to be half right. They also run in order: a preference result means nothing if the people giving it did not understand what they were looking at.
Not whether the problem exists, but how often it bites, what it costs them when it does, and whether they have already built a workaround. A problem nobody has worked around is a problem nobody is paying attention to.
Whether people can say back what the product does and who it is for, without you in the room. Comprehension fails quietly, and every answer after it is noise.
Whether your version is the one people choose when made to pick, and what the ones who did not pick it were stopped by.
How widely the pain holds across a whole audience rather than five people, and how much appetite sits behind it at the tier you are planning.
Whether the thing works in someone else's hands, in their language, on their device, with none of your team sitting next to them.
Almost everyone starts at the concept. It is the fun part, there is something to show, and it produces a percentage. But the two stages before it are the ones that decide whether that percentage means anything, and both get skipped because neither produces a slide.
The pain point first. Teams confirm a problem exists and treat that as a green light, when the question is how sharp it is: how often it happens, what it actually costs when it does, and what people are doing about it today. A problem everybody recognises and nobody has worked around is a problem nobody will change their habits to solve, and recognition is very easy to mistake for demand.
Then comprehension. Before anyone can tell you whether they want the thing, they have to understand what it is, and that fails far more often than teams expect because the team has been looking at it for months. We ask people to explain the product back in their own words before asking anything else. When a third of them describe something you did not build, the preference scores underneath are measuring their version, not yours, and no amount of sample size fixes that.
Picking the method is most of the job. Run the wrong one and you get a confident answer to a question you were not asking, which is worse than no answer at all.
Interviews about what people did last time, not what they would do. User research.
Ask people to explain the product back before you ask them anything else. Concept testing.
Forced choice between versions, with the reasons counted. Concept testing.
Sizing it across a whole audience, by behaviour rather than opinion. Product research surveys.
Moderated sessions where we can ask why at the moment someone hesitates. Usability testing.
Whether the translated product reads naturally and holds its layout. Localization testing.
Human raters scoring against a rubric you define. AI output evaluation.
The output of a validation project is a position: build it, change this first, or stop. It says which of the five questions passed and which did not, because an idea that fails on demand needs a completely different response from one that fails on the message, and a report that blends them together leaves you exactly where you started.
Underneath that sit the recordings, transcripts, clipped moments and ranked findings, so anyone on your team can go back to the source on any claim. The raw material is yours to keep whether or not you work with us again.
A written concept, a landing page, a deck, a Figma prototype, a Lovable build, a live URL, or a few static screens. Nothing has to be finished, and the earlier it is, the more a negative result is worth to you. The most common reason validation does not happen is a team deciding they are not ready yet.
Validation goes wrong abroad for reasons that have nothing to do with the method. A screener written for one market quietly recruits the wrong people in another, a concept gets polite agreement in a culture where contradicting a stranger is rude, and a question that was precise in English lands vaguely in translation. The study runs cleanly and the answer is still wrong.
We recruit directly in each market rather than drawing from one pool, verify identity and current role at sign-up, and field in the local language by default. The market pages set out what is specific to each one.
Product validation is the work of finding out whether an idea holds up before you commit to building it. It tests five separate things: that the pain point is sharp enough to act on, that people understand what the product is without you explaining it, that your solution is the one they would choose, that there is enough demand to matter, and that the thing is usable once it exists. Each needs a different method, which is why validation is a sequence rather than a single study.
Market research describes a market. Product validation tests a specific decision you are about to make, and is designed so that it can come back negative. If a study has no result that would stop you building, it is a description exercise rather than validation.
By asking what people did, not what they think. We look for frequency, what the problem costs them when it happens, and whether they have already built a workaround, because a workaround is the clearest evidence that somebody cares enough to act. Agreement that a problem exists is not evidence of anything: almost nobody disagrees that a problem exists.
We show it with no explanation and ask people to describe what it is, who it is for, and what it would replace, in their own words, before any other question. Then we count how many got it right. If comprehension is low, we stop there and report that, because preference and pricing answers collected from people who misread the concept are measuring something else entirely.
Yes, and that is the cheapest point to do it. A written concept, a landing page, a deck, a Figma prototype or a few static screens are all enough. Teams most often delay validation because they feel unfinished, which is exactly the state worth testing in.
You save the build. We report it plainly, including which part failed, because an idea that fails on demand needs a different response from one that fails on the message. A validation project you cannot fail is not worth running.
It depends which question you are answering. Problem and experience questions are qualitative and reach saturation at around eight to fifteen interviews. Comparing concepts or sizing demand is quantitative and wants roughly 100 responses per market, more if the decision turns on a few points of difference or you need to read the result by segment.
Two to three weeks from brief to readout call for a single question in a single market. A full sequence across several questions runs longer. Recruitment is the variable: a general consumer audience takes days, a narrow professional audience takes longer because we go and find those people.
Projects start from €399 for one question in one market, and scale with the number of methods, markets and sessions, and how hard the audience is to reach. Running a study yourself on our platform starts at €99.
Send us the idea and the decision behind it. We will come back with which question to answer first, the method, and a figure.