How to Prioritise and Create a Quarterly Product Roadmap
Deciding what to build and getting it turned into a well-organised roadmap.
My last post was all about what a product strategy is, but now I want to discuss prioritisation and the roadmap.
Let’s take a look.
Prioritising a product roadmap can be difficult. There are a lot of stakeholder demands, conflicting priorities, user needs, market shifts, and technical considerations all coming into play. So how do you prioritise effectively, gain stakeholder buy-in, and build an effective and well-organised roadmap?
I’ll assume at this point you’ve already done a lot of discovery and gotten feedback from customers and internal stakeholders to shape what initiatives and features you may want to include in the roadmap.
Step 1: Alignment with Product Strategy
Before you even begin prioritising, it’s always worth taking a step back and assessing your initiatives and features against your product vision and strategy.
Do they align with the long-term vision and help you move towards it, or are they moving you in the opposite direction? How do these initiatives help you reach your strategic objectives?
It’s important that your initiatives and features align with your vision and strategy. You should consider deprioritising anything that doesn’t align, regardless of how shiny and exciting it may be. It’s likely not worth the investment if it won’t take you where you need to go.
However, this doesn’t mean you shouldn’t include initiatives that don’t align. You may occasionally need to accrue some strategic debt for the short-term survival of the business or product.
Key Takeaway: Ensuring initiatives align with the strategy and vision. Prioritising is useless if the initiatives don’t align with your end goal, or help with the survival of the product in the short-term.
Step 2: Assessing Impact with a Business Case
Before you begin prioritising your long list of initiatives that you know will easily exceed your annual development capacity, it’s best to start assessing the impact and building some business cases.
You won’t need to do this for every initiative, but large, expensive initiatives will need some validation before committing to the investment. It helps ensure you’re focusing on the initiatives that are providing the right level of value but can also aid you in justifying the investment to senior leadership.
Here are a few things you may want to consider when building out your business case:
Estimate Revenue Potential: How much revenue could it generate from new sales and upsells, either directly or through partnerships? Your sales team and CRM data can likely help here.
Calculate Costs (Fixed and Variable): Consider the cost of development resources to complete the initiative, but also any other fixed and variable costs required to deliver and sustain it over time. It’s essential to ensure you’re not developing something that will provide a negative ROI (return on investment).
Factor in Professional Services (PS) Revenue: Consider the potential Professional Services revenue for the initiative. This can often help justify larger investments.
Impact on Churn and Retention: Consider any impact to retention and how it may increase the lifetime value (LTV) of your customers.
Key Takeaway: Something you may think is a ‘nice-to-have’ could turn into a ‘must-do’ with a comprehensive business case. Ensuring you’re focusing on initiatives that drive the most value. While also providing justifications to senior leadership for investment heavy initiatives.
Step 3: Decide on a Prioritisation Framework and Prioritise
There are a lot of frameworks to consider when you come to prioritising your chosen initiatives now that you’ve got your impact and effort to hand. Some of them are:
RICE (Reach, Impact, Confidence, Effort): Essentially, how many users or customers will it impact, how much of a benefit will it provide, how confident are you in your estimates, and how much effort is required to bring it to life.
Pros: Quantifies decisions, making it easier to compare objectively.
Cons: Scoring can be subjective and time-consuming.
Best for: Balancing high-impact features against limited resources.
MoSCoW (Must-Have, Should-Have, Could-Have, Won’t-Have): Simple and effective for quick categorisation. Due to its lack of granularity, you’ll find stakeholders want everything down as a “must-have”.
Stack Ranking: Similar to RICE, but you can even include the RICE score into it if you wish. Decide what you want to evaluate the initiatives against and start ranking. It will give a well-prioritised list of initiatives.
I’m personally a fan of stack ranking my initiatives, but using MoSCoW when doing some quick prioritisation with stakeholders. Keep in mind prioritisation frameworks will help get a structured priority list but they are not perfect. Treat them as a tool to guide your prioritisation and combine them with a bit of common sense.
Key Takeaway: Frameworks offer a structured approach, but remember—they’re not perfect. Use them to guide decisions, but don’t trust them completely.
Step 4: Stakeholder Feedback
From here, you should have a list of clear priorities, but before you turn this into a more actionable roadmap, You’ll want to get feedback from cross-functional stakeholders.
There may be something you’ve missed, or you’ve been generous with some prioritisation scoring. Getting feedback here will not only help to get buy-in but also keep you honest and ensure you’ve not overlooked something important, like an upcoming legislative change one of the team has come across. Here are some tips to help you at this stage:
Hold Internal Feedback Sessions: Bring in some stakeholders from different departments to help provide some feedback. You can do this as a cross-functional group but also with individual teams. Each stakeholder group will provide valuable feedback, but take it with a pinch of salt as they may prioritise items that are causing pain to them at this specific moment, like closing a recent and juicy sales opportunity they’ve got open.
Leadership Buy-In: Presenting your list to leadership is important for buy-in and sign-off. They want to focus on how everything aligns to the overall business goals and strategic objectives. As well as the impact each initiative will have on key areas like revenue, user growth, and retention. They may question some initiatives and impacts or suggest alternative initiatives. Having senior leadership on board will help provide support when tough trade-offs arise later.
Seek Buy-In, Not Just Input: After you’ve collected the initial round of feedback, it’s important to go back to the group with your finalised list. Not everyone will agree 100% with the list of initiatives and features, but it’s vital that stakeholders understand the rationale behind certain decisions and are on board with the direction. When you share the roadmap across the wider team, the buy-in of various stakeholders will help the roadmap be perceived as a more unified plan. Instead of a decision made by the product team.
Handling disagreements: Not everyone will agree with you, and that’s fine. If stakeholders are pushing for things that don’t align with the vision, don’t be afraid to call it out, and don’t feel pressured to change priorities if it doesn't make sense to. Listen and understand stakeholder disagreements, as sometimes they may reveal blind spots, but don’t be afraid to stand firm if you agree with your current priority list.
Key Takeaway: Stakeholder feedback and buy-in are the glue that holds a successful roadmap together. It ensures that priorities align with business needs and that everyone is pulling in the same direction.
Step 5: Collaborate with Your Development Teams to Create a Quarterly Roadmap
Now that you’ve got a prioritised list, you’ve secured buy-in, and people are aligned. It’s time to bring your development teams back into the conversation. You’ll need their help to turn the list into a more realistic timeline, considering the capacity of different teams and any dependencies you may face.
Here are some things to consider during your roadmap planning call with your development teams:
Capacity Across Teams: Understand each team's availability and expertise. This helps you map the right projects to the right resources—whether it’s backend, frontend, data science, or DevOps. For example, if all your data science initiatives are at the top of your priority list but you’ve only got 2 people with this skillset, it’s unlikely all these initiatives can be done in Q1. It may mean some of your items aren’t feasible at all that year without additional resources.
Identify Dependencies: Determine dependencies between tasks and teams, such as needing an API scoped and built before an integration can be done. This helps reduce bottlenecks and keeps projects on track.
Go through this with your development team one quarter at a time, making notes of any risks and dependencies. Do it for the full calendar year to ensure you can realistically achieve everything you need to and address any resourcing issues early. As opposed to planning 6 months at a time.
You can then share the full 12-month plan with stakeholders internally, but be mindful to set expectations that things can and will change.
Key Takeaway: Involve your development team when planning your roadmap timelines to ensure your roadmap is realistic and takes into consideration any limitations and dependencies you may have.
Additional Thoughts
So now you should have a complete and realistic roadmap you’ve shared with stakeholders. But here are a few additional things to consider during roadmap season:
Look for outliers: Sometimes, a feature might score low in RICE but is a strategic “Must-Have” in MoSCoW. Use common sense when reviewing your list, and don’t trust the framework blindly.
Avoid analysis paralysis: If you’re spending too much time trying to gather information to score features and initiatives, move forward with the information you have available and adjust it once more information comes to light.
Revisit priorities regularly: Quarterly reviews help ensure that your roadmap reflects any shifts in strategy, market conditions, inaccurate estimates, or new insights from user feedback.
Embrace change: Expect and embrace change; you will likely need to make changes as new information comes to light.
Do you find this works for you, or do you have a different process?
Would you like more information on creating the roadmap or templates to help you? Let me know!