Turning a pile of feedback into a build order
Your customers already told you what to build. The problem is they said it in forty different ways, across five tools, wrapped in moods.
People don't describe problems, they describe moods
Every product team has the same buried treasure and the same reason they never dig it up. The feedback exists. It is just not in a shape anyone can act on.
Real feedback looks like this:
- "the export thing is broken again"
- "love the app but it's slow"
- "why can't I just do X"
- three paragraphs about something unrelated, containing one sentence that matters
None of that is a feature request. All of it contains one. And nobody has three hours a week to sit and translate.
The four moves
Extract. Pull the actual claim out of the noise. A single piece of feedback often carries two complaints and a compliment, and they belong in three different places. Treating a message as one unit is the first thing that goes wrong.
Classify. Bug, request, confusion, praise.
Cluster. Most of the value lives here. Forty people saying the same thing in forty different ways is one roadmap item, and the count is the signal. Get clustering wrong and everything downstream is wrong with it, confidently.
Rank. Frequency, severity, and who said it, weighted together. A churn-risk account and a trial user who never activated do not carry the same weight, even when they report the same bug.
The mistake we made first
We clustered on surface similarity, and it grouped by vocabulary instead of by problem.
"Export is slow" and "the download takes forever" landed in different buckets. "Export is slow" and "export is broken" landed in the same one. One of those pairs is a single issue and the other is two separate issues, and we had it exactly backwards. The roadmap that came out looked authoritative and was quietly wrong.
Clustering has to run on the extracted claim, after normalisation, never on the raw text. Obvious in hindsight. It was not obvious at the time.
Why the order of operations matters more than the model
It is tempting to throw the whole pile at a language model and ask for a roadmap. That produces something that reads well and cannot be checked.
Each step has to be inspectable on its own. You should be able to click any item on your roadmap and see the forty original messages underneath it, in the customer's words. If you cannot trace a priority back to the people who asked for it, you do not have a roadmap. You have an opinion with extra steps.
What this means for your roadmap
The useful output is not a list. It is a defensible order, with the evidence attached, so the next time someone senior asks why this is above that, the answer takes ten seconds instead of a week of politics.
That is the whole job. Get the messy thing in, pull out what it actually says, normalise it into a shape, then rank the shape. The ranking is the part people talk about. The three steps in front of it decide whether it is right.