Prioritization for product managers
Deciding on what to do and when is a critical part of the role of product management. There are a million opportunities out there so how do you know that you are pursuing the right one? Life has many trade offs as does building products. Such is life :)
Here are some lessons that I have learned when communicating what I have prioritized in my roadmap. This is a blog post I have been meaning to write for a long time. But alas it also got de-prioritized. This is what I believe in when prioritizing.
1. Be open and transparent as to what you have chosen to do and why
I use a RICE criteria which is used by growth teams. Whilst the criteria is important it’s not the most important thing. The fact that I am open about my criteria is critical. Stakeholders, management and my team can view it and provide feedback. They can clearly see my criteria and justification for doing so.
I use a Confluence page with the roadmap macro. I like the roadmap macro as I can easily slide items to move them around. It is a visualization that is open to entire company. In addition, the criteria and method to the madness is detailed underneath. You can also use a spreadsheet, google docs, or trello board. The main point is that its visible and anyone can see how you got there.
2. Have a criteria to communciate your reasoning
Everyone has their own method for choosing what’s important. However having a criteria allows us to be more objective, opens up rigorous debate and removes emotion from the process. It becomes less a battle of opinion and will. I can’t stress this enough.
Firstly its about being clear on the mission of the team. Then we can assess everything against our criteria.
I’ve been using a RICE model from Intercom as my criteria. A lot of growth teams also use an ICE model.
Ths is what each letter means:
R = Reach. How many users will this decision impact. Quantify the change. Eg we expect 7,000 new users will re-engage with the product as a result of this push notification we will add.
I = Impact. What impact does this have on a key metric/goal. For my team, we are focused on activation. So we rate everything we consider out of 3 for the impact on this rate. Eg this will be 3/3 in driving new users.
C = Confidence. What is the teams confidence of our estimates for reach, impact and effort? We give a % for this out of 100. Eg 80% confidence in impact and effort.
E = Effort. How many months will this take 1 person to do. Eg 0.5 months for 1 person. 2 people will take 2 months? That’s 4 months.
The overall formula is (reach x impact confidence) / effort. It will be in a spreadsheet.
I will copy the spreadsheet and then rearrange into themes (see below). I like this method as it’s brings in numbers and considers a range of factors. It also considers the impact to customer value. The highest value items based on these factors will surface to the top.
There’s lots of other criterias out there that I have used and seen. Including value/effort, who screams the loudest, etc… Essentially the RICE model is a value/effort analysis which is about ROI (return on investment). Another variation I have used to determine ROI is: (business value x customer value) / effort. Which I call Bang 4 Buck
3. Involve your team to widen the pool of ideas
I have found that involving your team will open up more ideas and will also get them interested in what we are doing. Ultimately as the product manager you decide what to do. But if you hand down a roadmap and tell people what to do, they will not buy into it. In addition, your developers, designers have deep and amazing insights that you may not see. They are knee deep in the trenches everyday. There might be something eating away at them that they know will be valuable for your product.
You need to listen to your team. It doesn’t mean that we will do the most popular thing the team wants. You need to go wide, source lots of ideas then narrow down. I like the design thinking approach (go wide then narrow).
I encourage discussion, get the team to put their ideas into an ideas board in trello or on post-it notes. Then we have a group discussion about it. Any team member can have their say, but not their way. As the product manager, you own the metrics and success/failure. You decide what to do based on what is best for the customer.
4. Use themes
Product managers and people generally love themes. These are groupings of similar things. When someone looks at your roadmap, they’ll probably only remember 2–3 things. By grouping them into themes it’s easier to understand. I want them to walk away remembering the high level priorities. It’s also easier for you to show what we are prioritizing and it’s logical rather than a hodge podge of features.
It gives the team a focus. Something that has continued to be drilled into me from my time in Silicon Valley is focus. We focus on a theme. We have an insane focus on one thing and when we’ve done that, we move on.
5. Don’t solely use the criteria
A criteria should not be the sole determinant. Simply because I have an ordered list with items that have a high score does not mean I will do them in that order. Consider other factors such as dependencies, competitors, time to celebration lunch and does the order make sense. Can we group this priorities into themes?
The way I did it is show this is Act 1, Act 2, Act 3. Each Act has a theme. We have a focus on each quarter. Like a play! We want to paint a picture which tells a story. We want to show move 1 then move 2. We playing chess not checkers.
6. Frontload the highest impact items
We divide our year into 4 quarters. I give guidance to my stakeholders on a quarter by quarter basis. I know that if I implement something I need to provide lead time because of several factors:
* Customer adoption: it takes time after we ship a feature for customers to discover it and use it. Marketing also needs time to tell the world about it.
* Product adoption: In a mobile platform team, we provide services to product teams. It takes time for us to ship it as a mobile SDK and then for product teams to implement it as part of their cycle.
If I ship a new feature in Q1, the impact will not be felt til Q2. Hence there is a lead time I need to provide. In addition, I have a goal to move a metric. I want to do the items that have the highest impact to that metric first whilst balancing the cadence of shipping value constantly. Its an interesting balancing act. As we want to smash that goal as much as possible but if I wait til the last quarter, I might not get there in time. What if some fire develops or what I do in Q3 takes longer than I expect and the highest impact thing is in Q4? Its a race to move that metric so we need to consider frontloading highest impact items.
7. State what you are not doing
Often we tell our organizations what we are doing. We have our elaborate spreadsheets with our criterias, beautiful roadmaps, and our perfect slide decks which we agonize over. But we don’t state what we are not doing. We don’t tell the hard choices we made and the opportunities we decided not to pursue.
In the vein of transparency, we need to be open about the opportunity cost. There’s going to be some stakeholder or team member that is upset that we decided not to pursue their bug fix or feature. By clearly providing a list of things we decided not to do and why, it will help communicate why the other items are the priorities.
Perhaps these are too hard to implement and the payoff is too far down the track. Or that the reach is too small. Whatever it is, it is a good practice to communciate the choices we made. Our job is to say yes to 1 great thing and no to 99 other things. We have limited resources. It is our responsibility to our customers to pursue the highest customer value items.
8. Share to get feedback and buy-in
Once you have decided on the priorities, share it again with your team & other stakeholders to get feedback. You listen, spar (debate) and adjust accordingly. This will make your priorities more robust. You need to lead and persuade that this is the best path backed with criteria, insights, customer data and solid reasoning. You need to develop a position and show your organization the way.
As the product manager, you will ultimately decide on the priorities. We need to lead people to the conclusion, not tell them the conclusion. Then they will understand the priorities, be infused with missionary zeal and be ready to rock! A team that believes in the mission and is aligned on the priorities can acheive anything.
I’m out like the last Jedi,
Matthew Ho
p.s. Like this blog post? Then I’d appreciate a clap! You can also read more on my blog here.
