Choosing a research approach

You no longer pick blind

The research plan builder opens by asking what you want to learn or decide. From that answer, plus the audience you built earlier (including what you said you were unsure about), it works out which of the four approaches your question needs and explains why in a sentence or two.

Some questions need more than one piece of research, and when yours does you get all of them, numbered, in the order to run them, each with a line on why it sits where it does. Ask which of three ideas lands, which benefit resonates and what to call it, and you get those three in that order, because a value proposition test runs on one concept at a time and a name is judged against a settled promise.

Asking what to charge is the case worth knowing, because it splits by how many ideas you have. On one idea you get a price test on its own. If nobody in this study has been interviewed on a concept yet, a note beside it suggests you test the concept first, because people price something they already know far better than something described to them moments earlier. Once the study has one, the note is left off, since you can pick that concept from the Reuse option when you set the price test up. That note is a suggestion. Taking it means going back and rewording your answer so it asks about the concepts, which is the same route as any other change to a plan.

On several ideas it is not a suggestion. Pricing ideas against each other compares them, and a participant can only compare ideas they have already been shown, so those concepts have to be picked from the Reuse option when you set the price test up. Comparing takes two, so if your study does not have two tested concepts yet, the plan puts a concept test first and the price test second, and says why. Once it has two or more, you get the price test on its own, because what you actually want to price is a question for the setup screen rather than for the plan.

The plan is a suggestion, not a decision. Candor sets up the first step. The later steps are there to show you what to run next; they are not clickable, and each one is set up later as its own research plan. If the plan misreads what you meant, go back and reword your answer to get a different one.

You pick once per research plan, and a plan can only run interviews of its own approach. If you want both problem validation and concept testing on the same audience, that’s two plans and two runs, not one. Switching approach mid-build clears the material you entered for the previous one, because each approach takes a different kind of input.

Problem discovery

Pick this when you don’t yet know what problems matter most for your audience. You know who you want to serve, but not what to build for them or what their actual constraints look like.

Inputs you provide: learning goals describing what you want to understand — up to 6 of them, for any interview type. No hypotheses, no concepts, no prices.
What the guide does: open-ended sections that probe context, frustrations, current workarounds, and priorities. Lots of follow-up.
What synthesis returns: themes and tensions, but no opportunity framing. The point of discovery is understanding, not direction.
Use it when: you’re entering a new market, exploring a problem space you don’t live in, or sceptical that your assumptions about the audience are right.
Don’t use it when: you have specific hypotheses you want tested, or a concept you want evaluated. Discovery is too broad to give you those answers efficiently.

Problem validation

Pick this when you have a clear hypothesis about what problem matters and you want explicit evidence for or against it.

Inputs you provide: one or more problem statements (what’s painful for the audience). The screen asks What problem(s) do you want to test? You also set learning goals.
What the guide does: probes for behavioral evidence around each hypothesis. With five or more hypotheses, the guide automatically switches to a card-sort methodology where your synthetic participants sort hypotheses into pain buckets and the interviewer deep-dives the top-ranked ones.
What synthesis returns: an explicit verdict per hypothesis (validated, partially validated, not supported, not applicable to audience, or inconclusive) with the evidence behind it attached.
Use it when: you have a hypothesis to kill or confirm. The verdict structure is what makes this type worth doing. It forces an answer.
Don’t use it when: you have only one vague hypothesis. Problem validation needs sharp statements; vague ones get ambiguous verdicts.

Concept testing

Pick this when you have a specific product concept and you want to know whether it lands.

Inputs you provide: one or more concept statements (a paragraph each describing the concept), plus learning goals.
What the guide does: re-establishes the relevant pain from the participant’s memory, then presents the concept and probes comprehension, fit, objections, and willingness to engage. With multiple concepts the methodology adapts: comparative when there are a handful, card-sort when there are many.
What synthesis returns: what’s working, what needs rethinking, and who the concept is actually for. Structured to drive a build-or-pivot decision, not just generate themes.
Use it when: you have a real concept, not a vague direction. Concept testing rewards specificity in the input.
Don’t use it when: you don’t yet know whether the underlying problem is real. Run problem validation first, then concept testing on what survives.

Four kinds of concept test

Concept testing comes in four kinds. The research plan builder picks one from what you said you want to learn: a question about names, benefits, or headlines gets that test by name, and anything else about an idea gets the standard test. To change it, go back and reword your answer. The standard test evaluates whole concepts. The other three test a set of options for one concept you already have.

Standard concept test. Show one or more full concepts and gauge reaction, comprehension, and perceived value. People meet each concept cold and react to it. Add up to 12 concepts; 5 or more runs as a card sort.
Name test. Test potential names for one concept. People meet the concept first, then react to each name for it: does the name fit, resonate, and connect to what the product does? Nobody has to guess what the name is for.
Value proposition test. Test candidate benefits for one concept. Participants see them one at a time in the concept’s context, then say which is most compelling and believable.
Messaging test. Test potential messages or headlines for one concept: which is clearest, most persuasive, and makes them want to learn more.

The structural difference is the anchor. A standard test compares peer concepts against each other. The other three expose one concept first, which can be typed, uploaded, pasted as a URL, or reused from a concept you’ve already tested in this study, and then present each option inside that context. That’s what stops a participant from judging a name or a headline in a vacuum. On a name test the base concept has no name of its own, because the names you are testing are the only names participants should hear. A concept you reuse from earlier in the study keeps its name, and participants hear it once, when the interviewer reminds them of the concept they already saw.

Afterwards the subtype travels with the work. Guides, reports, and the project page are titled by it, so you’ll see “Value proposition test v1” or “Name test v1” rather than a generic concept test label. Version numbers count within a subtype, so your first name test is v1 even if two standard concept tests already ran in that study.

Sequence them the way the decision runs: settle whether the concept lands with a standard test, then use a follow-on test to sharpen how you talk about it. Naming a concept nobody wants yet is effort spent on the wrong question.

Price testing

Pick this when you have a concept that’s already resonating and you need to understand what people will pay for it and how price interacts with perceived value.

Inputs you provide: the solution(s) being priced, an optional Target price point for each if you have one, and learning goals around willingness-to-pay or value perception.
What the guide does: probes how the participant thinks about cost, the alternatives they compare against, anchors they reach for, and where they’d draw price-sensitivity thresholds.
What synthesis returns: value perception gaps, willingness-to-pay ranges, and where price becomes a deal-breaker for which segments.
Use it when: you have validated demand and need pricing intelligence to commit a number.
Don’t use it when: the concept hasn’t been validated for fit yet. Pricing feedback on a misfit concept is misleading.

A simple decision aid

Three questions, in order:

Do you know what problem matters for this audience? No → problem discovery. Yes, but want evidence → problem validation. Yes, with evidence → keep going.
Do you have a specific concept to test? No → don’t pick concept testing yet. Yes → concept testing.
Has the concept already been validated for fit? No → don’t pick price testing yet. Yes → price testing.

A common stack for new ventures

Many product teams sequence these in order: problem discovery (orient), problem validation (sharpen), concept testing (test the solution), price testing (commit to a number). Each stage informs the next. You don’t always need all four. Pick the ones that map to decisions you actually need to make.