In this final post in the series of basic Product Management frameworks to help you think like a PM, I’ll delve into the part of my job that is both most important and where I’m least popular: prioritization.
Prioritization is important because we could build pretty much anything into our software, and choosing concentrates our finite time and money into the things that will lead to the most customer value and ultimately, money to keep the company going.
Prioritization is where I’m least popular because it’s inevitable that someone won’t like my decisions. We can’t do everything. Sometimes we can’t do the fun or easy things. Sometimes the “boring” projects have to happen.
While the priorities are ultimately the PM’s decision, the process for making that decision can be daunting when stakeholders are asking for things from all directions. This post outlines the clearest, most useful framework I’ve used for this to keep my thoughts in order and the process transparent. The nine-box.
Exploring the nine-box
Like the framework for containing complexity that I introduced in Part II, this one is also derived from the management consulting world. Its formal name is the “GE-McKinsey Nine Box Matrix” and it looks like this:
This matrix was used to help executives at General Electric in the early 1970s sort out what to do with their many business units, where their options were to 1) invest & grow, 2) keep it going, 3)divest/sell for cash. The idea is to work out which divisions were strong relative to their competition AND in industries where GE thought it was well-positioned to succeed.
To use this framework in a product management context — unless you’re doing long-range business planning in a diversified company, which isn’t where most PMs spend their time — we need to make one significant change and one small one.
Updating the axes
The significant change we need to make to the original nine-box is the axes, to tighten the focus of our criteria.
Let’s start with the y-axis, “industry attractiveness”. In a Product Management context, we need to think about this more as “customer pain” that I described in Part I. The degree of pain experienced by your most important customer segments will help you (up)sell your product and grow the company. You can link levels of pain to the thing that you most want to optimize for in addressing that pain — this could be things like revenue opportunity, the number of customers impacted, or customer satisfaction.
Now for the x-axis. The original is “competitive strength of the business unit” relative to the rest of the industry. Most PMs look at the scrum team(s) they can influence — their own as well as sister and dependent teams — however, we’re going to broaden this group to your stakeholder list (as discussed in Part II). How projects fall on this axis should be a team judgment of how good you are collectively at getting to market from where you are today.
Moving up and to the right, right
The minor thing we need to change about the nine-box is the orientation of the x-axis. In the picture above, the rating goes high-medium-low looking left to right, which is confusing as “up and to the right” usually means “good” or “growth”, so let’s flip it.
This is what we get after making those changes:
Using and interpreting the product nine-box
To use this, discuss proposed projects with your team and put them into the appropriate spot on the grid. Here’s how I interpret the positioning of a project in each of the nine boxes, going left to right and top to bottom:
- 🔶High customer pain, Low team efficacy: We should build this, but we don’t have the right resources; let’s escalate this to get what we need to make it happen.
- ✅ High customer pain, Medium team efficacy: We should build this, but some of our resourcing is iffy; let’s prioritize closing the gaps with training, temporary help or a small budget increase, then get to work!
- ✅ High customer pain, High team efficacy: Let’s stop talking and build this now!
- 🔶 Medium customer pain, Low team efficacy: This is one to explore, but we’d need some non-trivial time for discovery and possibly substantial new resources or tools.
- 🔶 Medium customer pain, Medium team efficacy: Strong contender, but some of our resourcing is iffy; let’s close the gaps with training, temporary help or a small budget increase.
- ✅ Medium customer pain, high team efficacy: This looks like a good bet for us, we should move forward.
- 🔴 Low customer pain, Low/Medium/High team efficacy: Put it in the parking lot unless we have nothing in the other categories.
Here’s what it looks like on the grid.
Features vs. technical debt
This matrix is very feature oriented on the surface, but you can also use it to prioritize technical debt if you need to look at projects side by side. Technical debt can be a cause for customer pain in this model, for example, “the site is too slow to update orders”, or when customers need a feature you can’t build until you pay down debt).
If you allocate a certain percentage of overall development time to tech debt, you can prioritize only tech debt on the matrix. Change the y-axis to what you’re most focused on solving for by paying down debt: development velocity or cost reduction would be common ones to explore.
Conclusion
I hope you enjoyed this series of posts on thinking like a Product Manager.
My intent with this series was to:
- give aspiring PMs some tools to apply Product basics wherever they are today (in the workplace, hackathons and class projects); and
- provide folks who need a PM but don’t have one yet to fill in the blanks to help ensure they’re building the right things.
There’s much more to PM than these frameworks, but they will get you started in the right direction. Next up on the productized blog, I’ll be tackling:
- some of the tougher and least written about PM challenges — things like establishing KPIs, communicating failures, deciding to end of life a product;
- tips and techniques for building great PM teams; and
- resumes, interview prep, and career planning.
I’d love to hear about how you use these frameworks in real life; please leave your feedback in the comments. Thanks for reading.
Are you looking for a steady stream of insights for building better tech? Need help understanding how these pieces fit together in a real-life situation? Or in translating the data you gather in the empathy map into a vision and strategy for your product?
Click here to join the newsletter list and learn more about the upcoming online course, and click here to follow productized on Medium.
