By Simon Sovič, Senior Product Manager
The short answer is a 7-step process: set one clear goal, clean your backlog, score features using RICE, ICE, or MoSCoW, apply a strategic filter, align stakeholders, sequence your roadmap, and review it on a fixed cadence. You can run this process in one to two hours, and it works whether you are a solo founder or a PM on a large team. Difficulty: beginner to intermediate.
What You'll Need
A list of candidate features or ideas (a backlog, even a rough one)
Basic data: user feedback, support volume, or usage metrics (even informal notes work)
Access to your stakeholders for a short alignment conversation
A spreadsheet or prioritization tool (Notion, Linear, Productboard, or even Google Sheets)
A shared understanding of your product's current goal or north-star metric
Step 1: Define What You Are Optimizing For Right Now
Before you score a single feature, you need one clear goal for the current period. This is the most skipped step, and it causes the most roadmap fights later. Ask: what does the product need to achieve in the next quarter? Examples include reducing churn, increasing activation, growing revenue, or improving retention. Write that goal down in one sentence and share it with your team. Every prioritization decision you make in the next steps should point back to this sentence. If a feature does not move that metric, it belongs lower on the list, regardless of who asked for it.
Tip: if you cannot agree on one goal, you have a strategy problem, not a prioritization problem. Solve the strategy problem first. My guide on product strategy walks through how to get alignment before you touch the roadmap.
Tip: goals change between quarters. Revisit this step every cycle.
Step 2: Collect and Clean Your Feature List
Gather every feature request, idea, and initiative into one place. Include items from customer interviews, support tickets, sales calls, internal Slack threads, and your own product sense. Do not filter yet. Just collect. Once everything is in one list, remove exact duplicates and merge ideas that are clearly the same request phrased differently. You are not prioritizing yet. You are making sure you have a complete picture before you start making cuts.
Pro tip: tag each item with its source (customer, internal, data-driven). This helps you spot if your list is dominated by one voice, which is a bias risk.
Aim for a list of 10 to 30 items for a quarterly roadmap. More than 30 usually means you have not done enough merging.
Step 3: Score Each Feature Using a Simple Framework
Pick one scoring framework and apply it consistently. The goal is not mathematical precision. The goal is structured thinking. Three frameworks work well in practice:
RICE: Score each feature on Reach (how many users are affected), Impact (how much it moves the goal, scored 0.25 to 3), Confidence (how sure you are, as a percentage), and Effort (person-weeks). Divide Reach times Impact times Confidence by Effort. Higher scores go higher on the roadmap.
ICE: A simpler version. Score Impact, Confidence, and Ease on a scale of 1 to 10. Multiply them together. Useful when you have limited data and need to move fast.
MoSCoW: Sort features into Must Have, Should Have, Could Have, and Won't Have this cycle. Best used when stakeholders need a clear yes/no conversation rather than a ranked list.
In practice, RICE works well for data-rich environments. ICE works well for early-stage products. MoSCoW works well for stakeholder alignment meetings. Pick one for this cycle and stick with it.
On one SaaS platform I managed, I ran ICE scoring across a backlog of 24 features with the team in a single afternoon. The exercise surfaced a small onboarding fix that had been sitting ignored for months. We shipped it in the next sprint and saw a meaningful lift in activation within three weeks. The framework did not make the decision. It made the right decision harder to ignore.
Warning: do not use two frameworks on the same list. It creates inconsistent scores and erodes trust in the process.
Tip: estimate Effort in ranges (small: 1 week, medium: 2 to 4 weeks, large: 1 to 2 months) rather than exact hours. Precision here is false accuracy.
If you want a ready-to-use scoring template, the PM templates and tools page has a pre-built version you can copy straight into Google Sheets.
Step 4: Apply a Strategic Filter
After scoring, sort your list by score. Then pause before accepting that ranked order as final. Apply a strategic filter by asking three questions for each top-ranked item:
Does this directly support the goal you defined in Step 1?
Does this build on what the product already does well, or does it pull the team in a new direction?
If we build this and nothing else this quarter, will users notice and care?
Items that score high on the framework but fail these questions should be moved down. Items that score lower but pass all three may deserve to move up. This is where product judgment matters. Frameworks inform decisions. They do not replace them.
Pro tip: flag items that scored high purely because of high Confidence. High confidence often means the team is comfortable with the idea, not that it is the right one.
Step 5: Get Stakeholder Input Before You Lock the Roadmap
Share your ranked list with key stakeholders before you finalize anything. This is not a negotiation. It is a sense check. Show them the goal you defined in Step 1, the framework you used, and the top 5 to 10 items in priority order. Ask two questions: does anything on this list conflict with what you know that the team does not? Is anything missing that is a hard business requirement for this quarter?
Collect their input, update scores where new information changes the picture, and document where you disagreed and why. This step prevents the roadmap from being relitigated at the sprint level.
At one company, a sales leader pushed hard to add a custom reporting feature ahead of three higher-scored items. Instead of debating in the meeting, I walked through the RICE scores on screen and asked him to challenge the numbers rather than the ranking. He revised his estimate of the feature's reach downward once he saw how few accounts had actually requested it. The feature stayed in the backlog, and we kept the focus on activation. Showing your work changes the nature of the conversation.
Tip: keep this meeting under 45 minutes. If it runs longer, the goal from Step 1 is not clear enough.
Tip: avoid presenting the list as a draft that needs their approval. Present it as a recommendation that needs their knowledge.
Step 6: Sequence Your Top Features Into a Roadmap
Prioritization tells you what matters most. Sequencing tells you what order to build in. These are different questions. A high-priority feature may still need to come third if two other features are dependencies for it. Map out dependencies between your top items. Then group features into time blocks: this sprint, next sprint, this quarter, next quarter. Avoid locking in exact dates unless you have strong delivery confidence. Use timeframes, not deadlines, for anything beyond the current sprint.
Show your roadmap in a format that matches your audience. Engineers want sprint-level detail. Executives want quarterly themes. Build both views from the same source of truth.
Pro tip: leave 20 percent of team capacity unplanned. Bugs, incidents, and urgent requests will fill it. If they do not, you pull from the next priority item.
For a deeper look at how to structure this work, see my notes on product roadmap planning.
Step 7: Review and Adjust on a Regular Cadence
A roadmap is a document you update on a fixed schedule, not a contract. Set a recurring review, monthly for most teams, quarterly at minimum. At each review, check whether the goal from Step 1 still applies, whether any new data changes your scores, and whether anything shipped has opened up new priorities. Remove items that are no longer relevant. Add new items that have emerged. Re-score where needed. The teams that get this right treat prioritization as a habit, not a one-time event.
Tip: track what you decided not to build and why. This creates a record that stops the same debates from recurring.
Common Mistakes to Avoid
Prioritizing by who asked loudest. The loudest stakeholder is rarely the most representative user. Let your framework and data carry more weight than volume.
Skipping the goal-setting step. Without a shared goal, every feature looks equally important and prioritization becomes political.
Treating scores as final answers. Frameworks reduce bias. They do not eliminate the need for judgment. Always apply the strategic filter.
Building a roadmap that never changes. Conditions change. A roadmap that does not change is a sign the team is not paying attention to new information.
Confusing a feature list with a roadmap. A roadmap communicates strategy and timing. A feature list is just an inventory. Make sure yours tells a story about where the product is going and why.
Ignoring effort in scoring. A feature with high impact but enormous effort can crowd out three smaller features that would deliver more value combined.
If you want to understand how feature prioritization fits into the broader work of a product manager, read What Does a Product Manager Actually Do Day to Day for a full picture of how this work connects to strategy, discovery, and delivery.
FAQ
Which prioritization framework is best for a small startup?
ICE scoring works well for early-stage teams with limited data. It is fast to apply and forces you to be honest about confidence. As your product matures and you gather more usage data, graduating to RICE gives you more precision, especially when estimating reach.
How do you handle a feature request from a major customer or executive?
Run it through your framework the same way you would any other request. If it scores high based on reach, impact, and confidence, it belongs in the roadmap on its merits. If it scores low, document why and communicate that clearly. Decisions made outside the framework erode the team's trust in the process over time.
How often should you reprioritize your roadmap?
A monthly check-in works for most teams. Quarterly is a minimum. You should also trigger an unscheduled review when a major assumption changes, such as a competitor launch, a significant drop in a key metric, or a strategic shift from leadership.
What if two features have the same score?
Break ties using your strategic filter. Ask which item better supports your current goal, which has fewer dependencies, or which gives the team more learning if it ships first. If they are still equal, default to the one with lower effort so you can deliver value sooner and gather feedback.
How do you communicate roadmap priorities to stakeholders who disagree?
Show your work. Walk them through the goal, the framework, and how each feature scored. When stakeholders see the logic, disagreements usually move from "I want X" to "I think the impact of X is higher than you scored it." That is a productive conversation. Adjust scores where they bring new information. Hold the line where they are expressing preference without evidence.
Need Help With Your Roadmap?
If you want a second set of eyes on your prioritization process or help building a roadmap your team will actually use, book a consultation and we can work through it together. If you would rather start on your own, the PM templates and tools page has scoring frameworks and roadmap templates ready to use today.
This page was made by SuperDuperSEO →