You're reading the page six of the product development handbook.
How to decide what's up next?
Prioritisation is the processes for deciding what's up next or the what's most important thing to work on right now. A prioritised list creates a shared understanding to help direct a teams movement in the same direction. Benefits of a clear priority list include trackable progress, transparent decision-making process, and achievable goals.
For product feature development, you combine all of the decisions made throughout the entire process to set the direction and define the roadmap.
Independently you will prioritise:
Problem & discovery backlog (e.g. the research backlog)
Backlog tickets, specs, and user story (e.g. the developer backlog)
Epic level / work-stream prioritisation (e.g. the brief backlog)
Design backlog (e.g. what features need UI design work)
All of these smaller prioritisations lead to the bigger overarching prioritisation of the outcomes at a product level (e.g. the product roadmap)
Roadmap Priority = Insights + Data + Strategy
Making a product roadmap is all about making a decision on priority and deciding what deserves the most attention. To make good prioritisation decisions you need to collect as much information as possible.
Your decisions are only as good as the combinations of the inputs. Collecting data, gathering advice, and bringing together as many inputs as possible will give more clarity to the decisions that are made. Prioritisation decisions are the most influential decisions to the product because the set the product strategy.
Building a roadmap
Roadmaps hold the high-level strategy of a product. Roadmaps are the highest level visual representation of strategy to be shared across all stakeholders. Roadmaps show priority.
Who owns the work: Product Manager Who's involved: UX Designer, Business, Researcher, Tech Lead
You can build one roadmap for everyone, or make separate ones for each stakeholder group.
Roadmaps are used to:
Articulate priority,
Get everyone on the same page,
Communicate change, and
Set strategy.
Roadmaps are a tool that can be extremely valuable for a team and help set the context of the work and direction. There are endless options for roadmap formatting. I recommend looking at your other companies roadmaps to get inspiration and consider which stakeholder groups should have their own roadmap.
If you only have one roadmap - make a public facing roadmap. That way everyone in the organisation knows what is safe to communicate to anyone.
Public roadmaps
Most companies to share their roadmaps publicly, and if they do, they only share some information that they are happy for the public and their competitors to see. Product companies should have a roadmap available for their customers.
For public-facing roadmaps, I recommend two types: A release log combined with your next up work, or a kanban style roadmap. Both of these options don't make any time commitments, they show the priorities, and they ensure that all information is able to be shared with anyone.
Sharing public roadmaps offers transparency to your current and potential customers, or really any interested person. This can help them engage in the growth of your product.
Option 1 - What's Next Format
The 'What's Next' roadmap is a list of the top (most likely 5) pressing problems, outcomes, solutions, or features that you are working on. The great thing about this format is it's free for you to write whatever content is necessary to get your point across.
If you know what feature is next, write it. If your team is working on one brief at a time, write it. If your aiming to solve a problem, but don't know the solution - that's great too.
The format for the 'What's Next' is to split the page into two parts:
1. What's Next - List your next up roadmap items
2. What's New - A release log of all features, bug fixes, or events that you'd like to share.
Option 2 - Now, Next, Later Format
Now, Next, Later is a three column style of roadmap. The first column, the 'Now' column can also be called, 'Current', 'In priority', or 'In progress'. The middle column 'Next' represents all outcomes or problems that are reasonably known, but less important that everything in the first column.
Internal only (private) roadmaps
Internal roadmaps might have the same structure as a public roadmap, but the content will be geared towards stakeholders only inside your organisation. You can make a separate roadmap for each stakeholder that aligns with their strategy or just have one roadmap marked confidential.
Internal roadmaps may include:
secret or sensitive content that you don't want competitors or customers to know,
non-functional work (e.g. refactoring tech debt), which most people outside your organisation probably don't care about.
Prioritisation Frameworks
Prioritisation is the act of defining what is most important right now - not what is most important in the future. Learn to be ruthless. The easiest way to reduce scope is to define priority and stop work on everything else.
There are many prioritisation frameworks or methodologies. Here is 4 to get you started:
Method #1 - it's the vibe of the thing 🤷‍♀️
Probably the easiest method of all, use your brain to and decide what's the most important. This option has the potential to be reactive instead of proactive.
Scene from 'The Castle' - a 1997 Australian cult classic film.
Method #2 - RICE 🍚
Similar to the 🌶Spice Factor that we used for picking a solution.
RICE Score = (Reach x Impact x Confidence) / Effort
How many people will this impact? Use a consistent number to compared across all features.
How much will this impact each person? Use a scale of 0 - 1.
How confident are you in your estimates? Use a scale of 0 - 1.
How long with this take? Use developer months or half-month increments.
As reach, impact, or confidence goes up. The RICE score goes up. As effort goes up the RICE score goes down
Method #3 - ⚖️ CD3
CD3 means for Cost of delay divided by the duration. I really like this methodology, but it only works if you can quantify the value of your customers. If your product is still in pre-release or is a new product it might be hard to understand the cost of delay.
CD3 Score = Cost of Delay / Duration
Cost of Delay
How much does it cost your company to not have this feature right now? If you're customers don't have this feature, how much is it costing you in future sales and churn in current customers?
How long with this take? Use developer months or half-month increments.
For CD3 list all of the features with their CD3 Score, sort by ascending and choose the highest number. The CD3 score is in units of dollar per time, so choose the highest valued feature.
Method #4 - Kano
This method was developed in the 1980s. It separates out essential needs from delight. For example, a customer needs to be able to click a button, but if they don't need the button to animate when clicked. Button animations are usually considered delightful.
The Kano model ranks all of your features on a graph where the x-axis is functionality and the y-axis is satisfaction. Your goal is to choose the features that are needed by the customers first before choosing features that are nice to haves.
Roadmap maintenance
Roadmaps are never a 'set and forget' kind of document. They are living, and they change all the time. Roadmaps should be updated at least once a month or every quarter. As you update your roadmap you can share the new roadmap, but also provide information about what changed from the last roadmap and why.
Get feedback from all stakeholders
Good roadmaps are built collaborative across all stakeholder groups. As part of maintaining and updating a roadmap, run interviews and get feedback from your stakeholders. Try to understand the reasons behind their opinions of what they like and dislike. Treat roadmap maintenance with the same standard that you would customer research.
To read more how to build product roadmaps, check out this book → Product Roadmaps Relaunched: How to Set Direction while Embracing Uncertainty
What happens when you make a decision?
Prioritising a roadmap involves many strategic decisions and sets the direction for your product. The act of prioritising requires you to make decisions that affect your whole organisation. I think it's important to understand what happens when you make a decision.
First, the success of your product involves:
good decision making,
good execution, and
It's all too human to look back at past decisions and wonder if they were the right or to dream of a future really where you made the other decision.
"Hindsight is common and bland as boiled potatoes." - Maureen Howard
Look back on your decisions to learn from them.
Do - Learn for your past decisions.
Don't - Long for a reality where you made a different decision.
The only benefit to looking back and analysing your past decisions is to collect the learnings and use them input into future decisions. My 80-year-old, US history professor in university used to say,
"You can judge the past by standards of today."
This is true; every failure or wrong decision is an opportunity for learning that will help you make better decisions in the future. Your goal is to not regret or get hung up on your choices, but instead, to always strive to make the best choice possible with the information provided to you.
When I need to make a decision I like to think about how a master chess player chooses their next move during a game. A master chess player will think through 5 - 7 moves, then project each one of those moves forward by another 5 - 7 moves. They will go through each permutation and option in their head, rolling through every scenario, then they will pick the best option. The number of potential options that a master chess player thinks about before choosing their move is 7 Factorial or 7!, which looks like; 7x6x5x4x3x2=7!. Calculating 7! equals 5040. 5040 options is the number of every permutation of the 7 initial moves projected out 7 times.
How your decisions split the universe
There is a quantum mechanics theory that states - when you make a decision, the universe splits into two new universes and both options happen simultaneously but we can only see one version. Welcome to The Multi-universe or Many Worlds Theory. You might have heard this described as Schrodinger's cat thought experiment.
Schrodinger's cat is both alive and dead at the same time, and it's only when you observe the cat that you see which universe you are living in. The science of decision making has gotten pretty weird recently, particularly as we start to go deeper into the understanding of quantum mechanics.
And there's an app for that. Universe Splitter is an app that will "Immediately contact a laboratory in Geneva, Switzerland, and connect to a Quantis brand quantum device, which releases single photons into a partially-silvered mirror. Each photon will simultaneously bounce off the mirror and pass through it — but in separate universes" You can use this app to help you decide between two decisions. It's more random than flipping a coin.
This video below explains what's happening on a quantum level if your interested in take a short physics break from reading about product development. When you make a decision, there is theoretically a world that has moved forward, where everything is the same, except for the fact that you made the opposite decision in that moment. Like thinking about the chess moves, all the possible permutations of the universe with everyone's decisions is actually happening - we juct can't see it.
You don't have the power to change your past decisions once you see the outcome, but you do have the power to say, "I made the best decision at the time-based in the information that I had available to me." So don't get too hung up with choice paralysis. Make your decision, use data, set your priority, and move on.

go to next page


What's the best way to manage a dev team?
Like this handbook and want to see more?