Start with the problem, not the requested feature
Two customers can ask for the same feature for different reasons. Two different requests can also be symptoms of the same underlying problem.
Before comparing roadmap items, rewrite each request as a customer problem or desired outcome. Ask what is difficult today, what happens when the problem is not solved and how the customer works around it.
That changes the roadmap conversation from “Which feature has more votes?” to “Which customer problem deserves more attention, and what evidence supports that conclusion?”
Compare roadmap options with the same learning lens
For each proposed improvement, explore the same six questions.
Lens · What to investigate
- Importance: What consequence does the problem create when it occurs?
- Current workaround: How is the customer handling the problem today, and what does that workaround cost or complicate?
- Dependencies: What other systems, processes, roles or approvals affect whether an improvement would help?
- Stakeholder differences: Who feels the problem, who benefits from a change and who might inherit new work or risk?
- Trade-offs: What becomes easier, harder, slower, riskier or more constrained if this option is introduced?
- Evidence gap: Which parts are already supported by real evidence, and which are still assumptions?
The purpose is not to turn these answers into a simulated score. It is to make the reasoning behind the roadmap decision visible.
Hold the customer context steady before changing it
When you compare two roadmap options, start with the same modeled customer context: the same industry, region, company size and relevant role. That makes it easier to see whether the options expose different customer problems rather than different customer environments.
Then add another role when the decision requires it. A daily user may care about workflow effort. A manager may care about control and consistency. IT may see dependencies that the user never encounters.
Those differences can reveal that one roadmap item solves a local usability issue while another affects a broader adoption or operating problem.
Example: two improvements, one customer context
Illustrative example, not a customer result.
A B2B operations platform used by multi-site industrial service companies has two proposed improvements. One would let supervisors make bulk schedule changes. The other would add automatic alerts when planned work is at risk of being delayed.
The product team keeps the company context constant and explores both options from the perspectives of an operations manager and a frontline supervisor.
Instead of asking, “Which feature would you prefer?”, the team asks the same questions for both. What problem is this addressing? What happens today? What workaround exists? Who else depends on the change? What new burden or risk could it create?
If the simulated conversations surface different assumptions, the team records them rather than declaring a winner. One option may depend on how often schedules actually change, while the other may depend on whether anyone can act on an alert in time.
Those are research questions. The team can check them through real interviews, product data, support evidence or observation before committing the roadmap.
Turn the comparison into an evidence map, not a ranking
After the conversations, capture the reasoning behind each option in a simple team-compiled comparison.
Mark what is already supported by customer research or product evidence, what is plausible but unverified, and what appears contradictory or unclear. Then ask which uncertain assumption could most change the relative priority of the options.
This prevents a polished simulated response from carrying more weight than real evidence. It also prevents the team from treating every unknown as equally important.
A useful outcome is not “Option A scores 8.4 and Option B scores 7.9.” It is “Our decision currently depends on these assumptions, and this is the evidence we need to resolve them.”
Customer learning informs the roadmap. It does not replace product judgment
Customer discovery is one input into prioritization. Product strategy, technical feasibility, contractual commitments, risk, economics and sequencing still matter.
Use Virtual Customer when you need to understand the customer side of that decision more clearly before spending scarce research time. Then return to real customers and real product evidence for assumptions that are consequential, uncertain or difficult to reverse.
The aim is a roadmap you can explain because the team understands the customer problem, the trade-offs and the evidence behind the choice.
Start with two real roadmap options
Choose two improvements currently competing for attention. Keep the customer context the same, explore the underlying problem and trade-offs for each, then identify the one assumption that most needs stronger evidence before you prioritize.