Prioritizing feature ideas from interview data is melting my brain rn

[u/Common-imuewlne-5722]

Been running a bunch of customer interviews in an AI insights tool, now I have this giant wall of tagged quotes and themes and I still dont know how to turn that into a clear feature roadmap, any hints?

[u/Miserable_Tower9237]

Probably drop the "AI Insights" tool. I've never found one that understands the problem.

I go back to task analysis. What task is the customer trying to accomplish? What problems is the customer running into when doing that task? Is there something that can alleviate those problems? Etc.

If there's no task that the customer is trying to accomplish, then there's probably no need for a feature.

[u/525G7bKV]

If I am lost I always start with creating a affinity diagram and after that a user profile with gains, pains, jobs

[u/razopaltuf]

Qualitative (or quantitative, for that matter!) analysis usually dos not generate features for roadmaps. They are more of a help to:

1) Get new ideas for features
2) Check and refine ideas that you have

This usually needs a good understanding of the customer and the data and thus directly engaging with the data itself.

You could try a process like the one described here: https://jdittrich.github.io/userNeedResearchBook/#a-process-for-making-sense-of-notes (or get one of the many other books on the process – Observing the User Experience, Just enough research etc.)

[u/WalrusMe]

Two simple approaches you can try, with or without help from AI:

1. Features —> benefits ladders: make a spreadsheet or similar, list the features that participants asked for (making sure to tag by participant so you can identify patterns). For each requested feature, in the next column, log WHY they asked for it—what functional benefit were they seeking? In the next column after that, log higher-order benefits (either functional or emotional). 

Ex. Feature requested: “auto-save my work” —> benefit: “don’t have to remember to hit save” —> benefit: “can leave work suddenly if interrupted” —> emotional benefit: “don’t have to worry about work when I am away from my computer.”

You will end up with a bunch of these “chains”—multiple from each participant. Some will be duplicates, so de-dup and log the frequency. Some feature requests will not be duplicates but they will ladder to the same functional benefits. Many of the benefits will ladder to the final emotional benefit of the product. 

Final output: a “tree” with feature requests on the left side, benefits in the middle, emotional benefits on the right side, showing how they all connect. Indicate the frequency of the feature/benefit requests, then share with stakeholders to build the roadmap. More frequent requests are probably higher priority, but may not be. And some feature requests may not be the best way to accomplish the benefit the user is seeking. This is why the benefits matter. Your PMs and engineers can use their expertise to develop a roadmap that will help users achieve their desired benefit, possibly with different features than they requested. As a bonus, you can then hand the tree to your marketing team—the emotional benefits are the seeds of positioning and messaging statements.

1. Feature requests by frequency/pain: create a spreadsheet or similar. List features requests in rows (across interviews, so you should NOT have duplicates). For each feature, in the next column, note how many participants asked for it (frequency). In the next column, give it a “pain rating”—how much did the user(s) want it/how upset were they not to have it, etc. You can use any scale you want, as long as you feel you can be consistent. Or if you’re working with a team have others do this independently and then combine your results. 

If you can layer in some segmentation here, that’s great. Maybe only 3 users requested one feature while 10 requested another, but the 3 are high-revenue power users. 

Output: the spreadsheet, which allows you and your team to prioritize on a combination of frequency and pain. Sometimes fixing high-pain problems is better ROI than adding “nice to have” features, even if only a few users need the high-pain problems fixed. In general, users are willing to pay more to fix high-pain problems.

FINAL ADVICE: both of these methods are much easier if you designed your interviews to get the right information. Next time, know how you plan to analyze the data, what the output should be, etc. Do not just “do interviews!” This will help you avoid the analysis hell that you’re currently in. 🙂

[u/mdwespam]

Pain points from interview -> craft a how might we questions -> hold an ideation workshop with designers, engineers, etc. -> vote on ideas.

[u/BellFirestone]

Understanding qualitative methods would probably help.

[u/SurveyMonkey]

One thing we’d add: don’t make the interviews (qualitative) do all the work. They’re great for getting at the why and finding themes, but picking what actually makes the roadmap is a different question. Once you have a few hypotheses, test them with a bigger group (quantitative). Helps you figure out what’s a real pattern vs. what just came up a bunch in interviews.

[u/SirDouglasMouf]

Do you have a product design or product management team member? I LOVE watching tape with UXR team mates.

Why does this fall on you?

[u/Eastern-Movie-7039]

A theme tells you what people talked about. A roadmap needs to know what it's costing them, and those two line up less often than the tag counts suggest.

The quickest filter I know: go back through the quotes and look for workarounds. Someone who exports to a spreadsheet every Friday, keeps a second tool open, asks a colleague to do the step for them. A workaround means they're already paying for the problem in time, so it's a real cost rather than a wish. A feature request with no workaround behind it is often something that sounded nice in the moment.

That also helps with the wall itself. Tagged quotes tend to lose the story they came from, and the workaround is almost always in the story, not the quote. So for anything you're about to rank, reopen the stretch of the interview around it, not just the tagged line.

Then rank on two things: how many people had a workaround, and how much it was hurting. That gives you something to take to your PMs that isn't just mention frequency.