You have a list of problems you think matter. Find out which ones are real for this audience and worth solving, before a roadmap gets built on them.
Problem validation answers one question: is this problem worth solving? Use it when you have specific problems in mind and need evidence before you invest in any of them.
Write each problem as a statement that names who has it, the situation, and what it costs them. Candor interviews synthetic participants, holds your problems back until they’ve talked about their own frustrations, then tests each one. Every problem comes back with a verdict and a count of how many participants it held for. Confirm the ones you’ll bet on with real customers.
Run problem validation when you need to decide which problems to invest in. They might come from a discovery study, support tickets, sales calls, or a conviction somebody senior holds strongly.
It’s also how Candor does assumption validation. Most of the assumptions a product rests on are about the problem: that it exists, who has it, and that it hurts enough to act on. Write each one as a problem statement and it comes back with a verdict.
The verdicts are the point. Validation forces an answer on every problem, including the cheap and useful answer that a problem isn’t real.
you don’t have problems to test yet (start with problem discovery), or your statements are still vague. A vague statement comes back inconclusive, because nobody can agree or disagree with it.
Your problems are held back at the start. Participants talk about what frustrates them before any of your problems is named, so the first thing you learn is whether yours come up on their own.
An unprompted check: what’s frustrating in this part of their work or life, without naming any of your problems.
When something came up, a story about it, so the evidence comes from something that happened.
Your problems, introduced one at a time and in a different order for each participant: their experience of it, the last time it happened, and what they actually did about it.
With a longer list, a card sort instead: participants sort the problems by how challenging they are, rank them, and the interviewer goes deep on the ones at the top.
A challenge to the problem they backed most strongly, where it ranks against everything else on their plate, and a closing check on where they disagree.
Every problem comes back with one of five verdicts and a count of how many participants it held for.
Alongside the verdicts, the report can include a table of every problem ranked by severity, any problems participants raised on their own outside your list, and how each group read each problem.
The report tells you to read it as a map, not a verdict, and that’s worth taking literally. Participants can tell you a problem is real and widely recognised. Confirm it with real users before you bet on it.
Discovery surfaces the candidate problems. Validation narrows them to the ones worth building for.
Test ideas against a problem you know is real, with concept testing.
Take the validated problems to real customers, and don’t spend that budget on the ones that came back not supported.
For a working method, read validating product assumptions before you build.
It means the evidence across participants supports the problem as you stated it. Read the verdict with its count: Validated at 3 of 12 participants is a different fact from Validated at 10 of 12. The other verdicts are useful too. Partially validated usually means the problem is true of one group and not another, and Not supported saves you from building for a problem that isn't there. Treat a validated problem as strong direction, and confirm the ones you'll bet on with real customers.
Name the segment, the situation and the consequence. 'Senior insights managers at CPG companies can't test concept variations fast enough to keep up with launch timelines, and it delays go-to-market by weeks' is testable. 'CPG teams want better research' isn't, because there's no specific situation for a participant to recognise or reject. Vague statements tend to come back Inconclusive. If you can't picture what a participant would say to disagree, sharpen the statement before you run the study.
So you can see whether they come up on their own. Name a problem first and most people will find something to agree with, and the interview ends up measuring how reasonable your statement sounded. Candor asks about frustrations in that part of their work or life first, then introduces your problems one at a time. The problems participants raise before hearing yours, and the ones outside your list entirely, are often the most valuable part of the report.
Up to 10. A short list is tested one problem at a time, in a different order for each participant, with follow-ups on the last time it happened and what they did about it. A longer list switches to a card sort: participants sort the problems by how challenging they are, rank them, and the interviewer goes deep on the top of the pile. Sharp statements matter more than volume either way, because ten vague problems produce ten inconclusive verdicts.
Close to it. Assumption validation means testing what you believe about customers before you build. The riskiest of those beliefs are usually about the problem: that it exists, who has it, and that it costs them enough to act. Write each one as a problem statement and Candor gives it a verdict. Assumptions about a solution, a price or a message belong in concept testing, price testing or messaging testing.
Problem validation tests whether a problem is real and worth solving. Concept testing tests whether a specific solution resonates. The order matters: a great concept for a problem nobody has won't ship, while a real problem with no solution yet still tells you where to point the roadmap. Validate the problem first, then put effort into testing ideas against it.
Start with a free project, or walk through Candor with us first.