To prioritize features for a product that already has users, start with the decision or outcome to improve, not the most repeated request. First separate incidents, obligations, and security risks from growth work. Then assess each opportunity by strategic fit, affected users, problem severity, evidence quality, and delivery effort or risk.
The right priority is not necessarily the most requested feature. It is the next investment most likely to produce a verifiable result while protecting trust in the product.
Why a request list is not a roadmap
After launch, ideas arrive from major customers, sales, support, analytics, engineering, and leadership. They are expressed at different levels. “Add a dashboard” describes a solution; “I cannot tell which cases need my attention” describes a problem.
When every request becomes an equal backlog item, three biases appear:
- the loudest voice seems to represent the entire market;
- easy-to-name solutions replace problems that need understanding;
- invisible maintenance loses to visible new features.
A roadmap should express intended outcomes, bets, and constraints. A backlog preserves options; it should not make the decision for the team.
Step 1: separate obligations from opportunities
Not every task belongs in the same ranking.
Mandatory lane
Put critical incidents, vulnerabilities, data loss, regulatory deadlines, imminent incompatibilities, and contractual commitments here. Severity and timing determine their order. An outage affecting access or billing should not wait for a growth score to make it attractive.
Improvement lane
Put opportunities to improve activation, retention, revenue, productivity, or experience quality here. These can be compared because the team chooses when and how to pursue them.
Product health reserve
Protect an explicit share of capacity for reliability, accessibility, performance, dependencies, and internal tools. The proportion depends on the product; what matters is making this work visible before debt becomes an emergency.
This separation prevents an attractive commercial request from hiding operational risk without making every technical improvement an automatic top priority.
Step 2: turn every request into an observable problem
A useful intake form fits into a few questions:
- Who encounters the problem, and in what context?
- What task are they trying to complete?
- How often does it happen?
- What is the consequence: lost time, abandonment, error, cost, or risk?
- What evidence exists: observed session, ticket, usage data, or lost sale?
- What workaround does the user employ today?
Also ask which decision would change if the problem were solved. That question separates a preference from an economic or operational opportunity.
The same request from ten people does not always represent ten independent problems. It may come from one confusing journey, a particularly vocal segment, or unclear communication. Group requests by problem before counting votes.
Step 3: combine evidence from several sources
No single source is sufficient.
- Usage data. It shows where users arrive, abandon, or return, but not always why.
- Interviews and observation. They reveal context, workarounds, and real consequences.
- Support. Tickets expose recurring friction while overrepresenting people who ask for help.
- Sales and customer success. They identify objections, renewal risks, and needs from specific segments.
- Operations and engineering. They expose manual intervention, incidents, and constraints that slow every delivery.
The Government of Canada Digital Standards, updated May 25, 2026, include designing with users and iterating frequently. The principle also applies to a private product: every roadmap bet should connect to user evidence and a way to learn after release.
Step 4: compare opportunities with five criteria
Use a short scale, such as 1 to 5, with one sentence of justification. The numbers make assumptions discussable; they do not create scientific precision.
Strategic fit
Does the opportunity reinforce the segment, positioning, and outcome the product promises? A request may be valuable to one customer and still pull the product away from its chosen market.
Relevant reach
How many affected users or accounts belong to the segment the business intends to serve? Distinguish total volume from strategic volume.
Severity and frequency
Does the problem block a core task, create an expensive error, or add minor friction? A rare catastrophic problem may outrank a small daily annoyance.
Evidence confidence
An assumption from one conversation deserves less confidence than a problem observed, measured, and confirmed by several sources. Low confidence does not mean “no”; it often means “run a small discovery task.”
Effort, dependencies, and risk
Estimate design, data, integrations, migrations, testing, deployment, and support. A feature that is quick to code may be expensive to operate or difficult to remove.
Do not rely on one average score. Discuss the gaps. A high-impact, low-confidence opportunity calls for validation; a modest but expensive one likely calls for rejection.
A prioritization example
A B2B platform receives three requests: a custom export from one large account, a simpler invitation flow where 28% of new administrators abandon, and a new visual theme mentioned during a few demos.
The export may protect meaningful revenue but affect only one workflow. Invitations affect several new accounts and a measured activation step. The theme has little evidence connected to sales or usage.
A reasonable decision might be to:
- immediately test a lightweight correction to invitations;
- explore the export with the customer to identify the smallest need and its contractual value;
- keep the theme in “later” until stronger evidence appears.
This result does not come from a magic formula. It comes from a visible comparison of strategy, reach, severity, evidence, and cost.
Step 5: limit commitments to three horizons
A readable roadmap can use three horizons:
- Now. Committed problems, measurable outcome, and responsible team.
- Next. Opportunities with enough evidence to continue discovery, but no firm date promise.
- Later. Coherent options that still lack evidence, capacity, or timing.
Do not turn “later” into a silent graveyard. Add a review condition: a usage threshold, another customer, a removed dependency, or a decision date.
The GOV.UK Service Manual guidance on agile planning, updated March 31, 2026, recommends planning at multiple levels and revising plans as a team learns. A roadmap should therefore be stable enough to guide and light enough to change when better evidence appears.
Step 6: validate risky bets before building
A high priority does not automatically authorize a complete build. Choose the least expensive test capable of disproving the assumption:
- targeted interview or task observation;
- clickable prototype;
- manual service offered to a few customers;
- in-product message;
- instrumentation of a poorly understood step;
- limited release to one segment.
Define in advance what would advance, change, or stop the idea. Without a criterion, every result becomes a reason to continue.
Step 7: close the loop after release
Give every shipped item a measure and review date. Depending on the problem, observe activation, task time, errors, tickets, adoption, retention, or support cost.
Tell the people who supplied the evidence, then document what actually happened. A feature with low adoption may require better discovery, different communication, or removal. Stacking more features on an unverified bet does not protect the first investment.
What to communicate to customers and teams
Explain the selected problem, expected result, confidence level, and what is not committed. Avoid promising a date for an idea still in discovery. Say which question the team is resolving and when it will review the decision.
When rejecting a request, acknowledge the need, explain the blocking criterion, and offer a workaround when possible. A consistent decision builds more trust than a vague “yes” that never ships.
Put the method in place this week
Gather open requests, remove duplicate solutions, and rewrite the ten most important as problems. Separate obligations. For everything else, record one piece of evidence, an intended outcome, the five criteria, and the next action: build, validate, wait, or decline.
Project Factory helps evolve custom SaaS platforms and mobile applications through observable decisions. The Hapbee project illustrates a mobile product whose roadmap evolves within an existing ecosystem. If the issue is instead whether to stabilize or replace the technical foundation, read our guide to modernizing or rebuilding an application.