They asked for a PDF export. It was delivered. They stopped using the tool anyway.
This story is common enough to deserve an explanation, because it says something about how software should be specified.
A user knows where it hurts
The people who use a tool every day are the best source there is on what goes wrong. They are rarely the best source on how to fix it, and that is not a criticism: it is not their job.
A feature request is a symptom that takes itself for a prescription. “I want a PDF export” means “I lose my Monday morning putting together a report for my manager”. The need was never a button. It was getting Monday back.
Build the button, and Monday is still lost: the report still has to be assembled, only the last step is faster. Understand the reason, and you may find that the report can generate and send itself.
The real reasons are never written down
Nobody fills in a feedback form with “this tool tires me out”. People think it, they work around the tool, and one day they are back in their spreadsheet.
A tool is rarely abandoned because of what it lacks. It is abandoned because of what it costs to keep using it: the extra clicks, the double entry, the screen nobody understands.
The question we ask
Before building what is requested, we ask one thing: “What were you trying to do, just before you needed this?”
The answer changes the project. Sometimes the feature is exactly right. Often it becomes something simpler. Occasionally it disappears, because the step it was meant to speed up had no reason to exist.
What it means for you
A list of features collected from your teams is a precious starting point, and we will read every line of it. But a roadmap should not answer requests. It should answer reasons. That is how you end up with fewer screens, a smaller budget and a tool people actually keep.