🗺️ Roadmapping - Part 2: Prioritization and planning process
A roadmap is an artifact of your product strategy, not a day-to-day plan.
How you prioritize your next few quarters will significantly impact the success of your product. Roadmapping is something I spent a lot of time on early in my career. I knew the importance of getting it right; nothing else mattered if we solved the wrong problems. Many product managers get this wrong, especially early in their careers.
If you're not working on the right things, it doesn't matter how efficient you are, how great your development team's code is, or how bug-free your software is. You built the wrong things and won't see the growth you need. If your roadmap is output-oriented and not strategy-focused, you won't have the flexibility to execute your strategy. A roadmap is an artifact of your product strategy, not a day-to-day plan.
The first step to getting prioritization right is to focus on outcomes over features. You can look at this in a few different ways, depending on your situation:
Grouping problems or solutions you'll focus on by user persona.
Group similar problems that can be solved with one solution.
Prioritize KPIs.
Focus on solving existing pain points within your product.
Prioritize partnerships, integrations or technology.
When you're trying to prioritize the problems you will solve or the solutions for them, it's helpful to use prioritization frameworks to help you score each idea. However, don't use this method alone. Instead, let it help you understand how you might prioritize things. Many other factors need to be taken into consideration. Here are some questions you can ask yourself:
Do you have clients waiting for this feature?
What is the revenue potential for this feature or for solving this problem?
Are there interim steps you need to take before one of these ideas becomes feasible? Do those interim steps add enough value along the way to be prioritized?
Is there tech debt you need to pay down?
Do you have a critical step in your onboarding flow that needs improvement?
Are there 'pinch points' for users within your app that need immediate improvement?
Are there specific objectives or KPIs you're trying to hit?
Do you have an integration you're trying to work around the timing of?
Is there a regulatory or compliance requirement deadline?
Are there market disruptions happening that you need to adjust to or plan for?
Is there something happening (i.e. Global Pandemic) that your product is in a position to create value during?
Once you're clear on any overriding objectives, you can start to filter and prioritize your ideas based on one of the following strategies or come up with your own:
MoSCoW Method: This framework categorizes requirements into four prioritization levels: Must-haves, Should-haves, Could-haves, and Won't-haves. It helps teams to prioritize features based on their criticality to the product's success.
Kano Model: The Kano model focuses on customer satisfaction and categorizes features into three main categories: Must-be qualities, One-dimensional qualities, and Attractive qualities. It helps to understand customer preferences and prioritize features based on their ability to delight customers.
RICE Score: RICE stands for Reach, Impact, Confidence, and Effort. This framework helps prioritize projects based on the potential impact, the number of users it will affect, the confidence in the estimates, and the effort required to implement the project.
WSJF (Weighted Shortest Job First): WSJF is a framework popularized by SAFe (Scaled Agile Framework). It prioritizes features based on the cost of delay, job size, and how well it aligns with the business strategy. It ensures that the highest-value features are worked on first.
Value vs. Effort Matrix: This framework plots features on a matrix with the x-axis representing the effort required and the y-axis representing the value delivered. Features are then prioritized based on their position on the matrix.
The ICE Scoring Model: ICE stands for Impact, Confidence, and Ease. This model assigns a score to each feature based on its potential impact, the team's confidence in that impact, and the ease of implementation. Features with higher ICE scores are given higher priority.
Opportunity Scoring: This framework involves assigning a score to each potential project or feature based on various factors, such as market demand, competitive advantage, alignment with business goals, and the effort required. Features with higher scores are given higher priority.
Roadmap planning can be a messy process. I often switch between several planning strategies and frameworks while setting my priorities. There's no magic solution, and you must go through multiple iterations. It's easiest to split this work out across the entire quarter and start planning far in advance. You do not want to leave this process until a week before your roadmap is due.
But how do you know what to build in the first place?
I like to use design thinking to help ideate and imagine ways to accomplish your strategy or goals (this includes grouping similar ideas and looking for common trends that can all be solved similarly). Then, refining the most promising ideas by working through divergent and convergent cycles of thinking is essential.
To put it another way, you work backward from your vision/strategy, and then when you figure out where you're starting, you map out how you incrementally reach your end goal, stacking all of the ideas from your design thinking strategy into a stairway to success.
Roadmapping Series
Part 1: A living document
Roadmaps aren’t intended to remain static. We’ll explore some ways to help keep your roadmap fluid and up-to-date as things change.
Part 2: Prioritization and planning process 👈
How do you decide what gets put on your roadmap?
Part 3: Milestones
When should you add Milestones to your roadmap? What constitutes a milestone?
Part 4: Outcome-based roadmaps
This type of roadmap focuses on outcomes over features or solutions.
Part 5: Now, Next Later
Avoid concrete timeframes and focus on priorities.
Part 6: Development Roadmap
The roadmap you build for your dev team differs significantly from what you would create for your stakeholders and customers.
Part 7: Layering your roadmaps
How layering shows different levels of detail within your roadmap for various stakeholders and taking a simple approach to maintaining them.
Let me know if there's anything else about roadmaps you want to see expanded on, and I'll develop this series more if there's enough interest.