Thinking Like a Product Manager

Part III — Prioritization and Conclusion

(You can read Part I and Part II of this series here on Medium)

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.

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.

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.

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:

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:

Here’s what it looks like on the grid.

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.

I hope you enjoyed this series of posts on thinking like a Product Manager.

My intent with this series was to:

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:

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?

Related posts:

There are many paradigms for classifying personality types. Some say there are 4 personality types. Others 8.. 12.. 16. One of the most well-known is Myers-Briggs, which breaks down our personalities…

Are you looking for copper prices? Would you like to be able to see these prices in the currency of your country of origin (Indonesia)? If your answer is yes, we recommend you read this post! Copper…

The way I have settled into retirement — away from what had been my home for eight years, away from a job that I had for sixteen years, away from an area where I had lived longer than any other…