A roadmap item is not a customer problem
A roadmap item is a proposed solution. Good product discovery works backward to the customer situation, evidence, and outcome before treating the request as a priority.
A feature request arrives with a solution already attached
Customers, sales teams, founders, and internal stakeholders naturally describe problems as features: add an export, build a dashboard, support a new integration, change the onboarding flow. The request may be useful. But the roadmap item is still one proposed answer to a problem that has not necessarily been understood.
Discovery starts by separating the two.
Ask what the person was trying to accomplish
Move the conversation away from the requested interface and back to the situation. What were they doing? What made the current path difficult? What happened because of that difficulty? What workaround do they use now?
A request for “bulk export” might be about reporting, migration, auditability, client delivery, or a manual process that happens every week. Those are different problems and may deserve different solutions.
Preserve the context around the request
The same feature request can have different value depending on frequency, customer type, urgency, consequence, and available alternatives.
Record the context instead of reducing feedback to a count. Ten requests from low-fit users can matter less than three requests tied to a critical workflow for your core customers.
Look for evidence beyond preference
Useful discovery combines what people say with what they do. Support tickets, product behavior, churn notes, sales conversations, and observed workarounds can show whether the problem is persistent and costly enough to deserve attention.
The goal is not to prove the feature is good or bad. It is to understand the problem well enough to choose deliberately.
Write the problem without naming the solution
A practical test is to describe the problem in one sentence without using the proposed feature. For example: “Finance teams spend hours combining usage data from several accounts before monthly reporting.”
Now the team can compare several possible responses: export tools, scheduled reports, a consolidated view, an API, or a workflow change.
Decide what uncertainty remains
Before placing the item on the roadmap, ask what still needs to be learned. Is the problem common enough? Does the proposed solution actually fit the workflow? Would users change behavior? Is the effort justified compared with other problems?
A small interview, prototype, data review, or manual test may answer the question faster than a full build.
Keep the roadmap connected to problems
A roadmap is easier to prioritize when items preserve the problem, evidence, expected outcome, and major assumptions. Otherwise the team ends up comparing solution names that hide the reasons they exist.
A roadmap item can be a good idea. It just should not become the customer problem by default.