How is validating a feature different from asking if people want it?

Asking if people want a feature invites polite yeses. This template validates the problem instead: how often it happens and what they do about it today. A real workaround proves demand far better than an opinion about the idea.

How many responses do I need to validate a feature?

Because each respondent produces a transcript, 20 to 50 from the right users is usually enough to see whether the workarounds converge. You are reading for a repeated, painful problem, not statistical significance.

Should I describe the feature or just the problem?

Lead with the problem so people react to their own experience. You can describe the feature in the intro to set context, but the anchors deliberately focus on frequency and the current workaround, not the pitch.

What do the results look like?

The frequency breakdown, themes with quotes and counts of how people cope today, full transcripts, and a plain-language box for asking things like "what workarounds did daily sufferers describe?"

Templates / Feature validation

Product · Adaptive interview template

Feature validation template

The dangerous feature is the one everyone agrees sounds useful. Useful is free to say and costs nothing to agree with, which is why roadmaps fill with features that demo well and change nobody's day. Validation is not about whether people like the idea; it is about whether the problem it solves is real, frequent, and painful enough that they have already jury-rigged a workaround.

This template starts by grounding the feature in a problem the respondent actually has, how often they hit it, then asks how they handle it today without your feature. The AI interviewer chases the workaround, because the existence and awkwardness of the current fix is the truest signal of demand. Someone who has built a spreadsheet to cope is telling you more than a hundred people who say the feature sounds nice.

When to use it

Before committing engineering time to a feature on the roadmap
When two proposed features compete for the same sprint and you must choose
To pressure-test a feature request that a loud customer keeps asking for
After a rough prototype, to confirm the underlying problem is worth solving

Running it well

Lead with the problem, not the feature. If you describe the feature first, respondents validate your idea instead of revealing their reality.
Weight the answers by frequency. Feedback from someone who hits the problem daily is worth more than a dozen occasional encounters.
The workaround transcripts are the deliverable. An elaborate manual fix is the strongest evidence a feature is worth building.
Validate one feature per study. Bundling two blurs the themes and lets a strong problem carry a weak one.

The questions, and why they're shaped this way

These are the anchor questions. You can edit, reorder, or add to them; the AI interviewer handles the depth between them.

Multiple choice

How often do you run into the problem this feature addresses?

DailyWeeklyOccasionallyRarely or never

Frequency is the first filter. A painful problem people hit twice a year rarely justifies a feature, and the answer routes the interview toward heavy users whose workarounds matter most.

Open text

How do you handle this today, without the feature?

The workaround is the demand signal. If people have built spreadsheets, scripts, or manual routines to cope, the problem is real; if they shrug, the feature is a nice-to-have dressed as a priority.

What the interviewer asks next

Follow-ups aren't scripted. The AI reads each answer and probes what a researcher would. Depending on what a respondent says, it might ask:

"You said you hit this daily. Walk me through the last time it happened and what it cost you."

"You mentioned you built a spreadsheet to cope. What does it do that no existing tool handles?"

"You said you rarely run into this. When you do, is it a minor annoyance or something that blocks you?"

Live demo

Play the feature validation interview

This is the real interviewer, not a recording. Answer as yourself and watch the follow-ups adapt to what you write.

Prefer a full window? Open the demo.

Common questions

How is validating a feature different from asking if people want it?: Asking if people want a feature invites polite yeses. This template validates the problem instead: how often it happens and what they do about it today. A real workaround proves demand far better than an opinion about the idea.
How many responses do I need to validate a feature?: Because each respondent produces a transcript, 20 to 50 from the right users is usually enough to see whether the workarounds converge. You are reading for a repeated, painful problem, not statistical significance.
Should I describe the feature or just the problem?: Lead with the problem so people react to their own experience. You can describe the feature in the intro to set context, but the anchors deliberately focus on frequency and the current workaround, not the pitch.
What do the results look like?: The frequency breakdown, themes with quotes and counts of how people cope today, full transcripts, and a plain-language box for asking things like "what workarounds did daily sufferers describe?"

Related templates

Research

Concept test template

Find out whether an idea lands before you build it, and hear the objections verbatim.

Research

User research interview template

Generative discovery that chases behavior, not opinions, at any hour.

Product

Beta feedback survey template

Find out what your beta testers actually use and what quietly let them down.

Product

Product feedback survey template

A recurring pulse that digs into the score instead of just plotting it.

Run the feature validation with your own audience

Join the waitlist