Check out a free preview of the full Complete Intro to Product Management course

The "Prioritizing" Lesson is part of the full, Complete Intro to Product Management course featured in this preview video. Here's what you'd learn in this lesson:

Brian provides two tools that are helpful when prioritizing projects. Comparing the complexity to business value splits the risk into effort and impact. The RICE method takes a more scientific approach, allowing product managers to associate a score with each task.


Transcript from the "Prioritizing" Lesson

>> Prioritization, I feel like I've talked about this like indirectly a bunch of times because you all stop bringing it up [LAUGH]. But turns out, it's actually really important. It's like one of the biggest things that a product manager does, a lot of my job as an engineer comes to me is I can do task A, or I can do task B.

And I need you to choose so it's your fault if it was the wrong one to work on A lot of it's just owning the risk, right? So if you own so much risk, you better learn how to manage the risk. So you always, always, always have more work than you could ever possibly do.

I have never met a PM in my entire life who's like, we're actually out of stuff to do. I really can't think of one. You know who probably says that? The PM of Craigslist. Craig ran out of stuff to do. I don't know who Craig is, but what I actually admire about the product of Craigslist is like, they're like, we're done.

We did it. We finished it. Super stable is incredibly stable and it's a good product and they make a ton of money. Bananas anyway, if you are the PM of Craigslist and you're listening to this, you can just shut it off and go hang out in your yacht, right like it's fine.

You can ignore this section of the course right? You did it, everybody else tune in because I've never met another PM that would say we're out of things to do. So frequently the question is like do I work on A or do I work on B? It's just obvious.

A is mission-critical, B is not, we're gonna work on A, right? Or Z is on fire and alpha will wait. We'll work on Z, right? So, lean into your intuition where that's possible a ladders up into a project that is mission critical to our metrics, and B, affects like one of our secondary metrics.

You're probably gonna do A. So, what do you do when you have A and B and they are, in your eyes, roughly of same importance? This is where this can get a bit dicey. So I'm gonna give you two different tools that I use to assess which thing I should work on next.

So I'll do the simple one first. This one's usually enough for most things. So trying to, yeah, we're ultimately trying to judge three things here impact. How many people can we impact in which ways? How risky is it? And what's the cost here? Cost can be people, cost can be money, cost can be resources going out, right?

Impact, risk, and cost ultimately, everything that I'm gonna talk about here more or less correlates to one of these two things. Sorry, three things. Impact is a roll up idea of how many people and how deeply am I going to affect them. If you don't migrate your database in your server is gonna overload and crash that affects all of your users that's highly impactful.

What if you add support to an obscure language to your application for a demographic of users not using your application. Low impact, right high effort, very costful, low impact there. You can probably put that on the backlog if that feels important for you to support. Risk is the idea of how likely something is going to happen.

So, if you're a stripe and you are not paying out someone correctly, that's a high risk that they're gonna find out that you did that, right? I would also argue it's ethically, you should probably pay people the money if they're due, but it's a very risky thing because people keep track of their money very, very closely.

I'm sure you can imagine like less risky situations of like, what happens if someone sends a direct message and it fails to send the first time. So they have to send it again, not incredibly risky is particularly if it's like a low likelihood of tap and right. I would judge that to be a low risk kind of situation where the failure state is not very expensive and the recovery state is extremely easy for them.

It's not preferable. It could be fixed. It doesn't necessarily have to be the highest prioritized thing. Actually, famously, Facebook notifications for like a decade were incorrect, right? I don't remember if you remember like old blue Facebook where you would go on there and it would be the wrong amount of notifications and you'd have phantom notifications.

You'd click on it. Nothing would be there. You'd close it again, and then you would click it again and like it would go back and it would never be right? That's because they just judged that as like not a very impactful thing because the, while it did happen to a lot of people, like the risk of them actually doing anything about it was fairly low, right?

All right, so, yeah we kind of talked about what risk is and all those kinds of things. So, complexity versus business value matrix, right? This is just one that's kind of good to keep in your mind, high impact, low effort, high impact, blah, blah, blah. Generally if if something has high impact, low effort, that's like a must do.

If something is a low impact, high effort, it's a throw away. And then here is where you kind of have to really kind of judge things so this is just a useful way to kind of visualize okay if I'm in this one I'm just gonna do it right away.

And this one, if I'm in this one I'm not gonna do it and then if I'm in one of these that's when I'll go to the like more advanced matrix of how to judge prioritization. So I talked about it before, but I'll talk about it here again. This is the RICE method, and it is from Intercom, which is a company that many of us have used great company.

I like this one really resonated with me. So there's many ways to judge priority, and this is just the one that stuck with me the most. So this is what I'm gonna teach you. But if it doesn't resonate with you, there are lots of other ones just search for prioritization framework and Google and you will find a trillion of them.

So at intercom apparently they do this for everything and they always judge correctly by the score. I am not such a stickler for the rules here. I still allow for my own sense of product sense to be infused here because this is, we're this is a squishy science.

So, you're being paid for your opinion here. So, use it. So, the RICE method R is reach, which is how many people will this effect? It's generally a good proxy for the reach of whatever you're going to do. It helps you kind of avoid, this will be so impactful, particularly when it comes to power users, right?

Because power users will be very loud. Hey, we really want this feature yesterday, but when you would go ask yourself, What's the reach of this and it's only 100 people out of your 100,000 users, it helps you kind of keep in line. Yeah, maybe this is good for our 100 people and that's impactful to them but we don't have to cater to their every whim because we have so many other users.

Okay, so after reach. Yeah, and this is measured in people quarterly or people whatever time period you're looking for. So let's say it was 400,000, right, people in a quarter, that's what your number would be here. Impact is a scale value for how impactful something will be. And the numbers that they give here is 3 is the massive most awesome impact, 2 is for high impact, 1 is for medium impact or average impact, 0.5 is for low impact and 0.25 is for minimal.

So I think you can see how reach and impact are kind of combining together to get you a good number of what we should be thinking about if you affect all of your million users. And it's minimal impact, that's actually better than high impact for a hundred users, right?

So it kind of helps you keep us a grip on reach versus impact. How many people is this affecting versus how much does it affect them, okay. Confidence, I quite liked this one as well, and a lot of other things didn't have this kind of built into it.

But confidence is like, how confident are you in your estimations here, right? So I am 50% sure, this is going to do exactly what I think it's gonna do, right? And if you do that, then you are 0.5 right? And so you have whatever you thought your reach at times impact was and if you're 100% confident that this is definitely going to do this right?

A good example is like if I don't fix the database my website's not gonna come back up that's 100%. I am definitely confident if I don't have a database, my website doesn't work, right? Whereas, like, if I add an additional button here for them to see their profile, I'm like 50% confident that's gonna do anything, right.

So that's kind of what that value helps you do is it helps you kind of scale down. Based on how confident you are in your assessments there. They say for anything that you are less than 50% confident in, go revise your hypothesis until you arrive to something that you are 50% confident in.

Don't do anything under 50% confidence. Because that means if you're leaning towards it, this is probably not gonna work. So go find something that you think is gonna work. Okay, and then E is for effort. This is how many people working for how long to ship it measured in person months, right?

So if a project needs three days for two months, it is a six on effort, right? Once you have your numbers, it is reach times impact times confidence divided by effort, and that yields you a RICE score. Now you have more or less apples to apples number of this is how impactful I think this thing's going to be.

And I use this somewhat frequently when I have things in front of me that I'm not really sure which one's more important than the other. I don't do this for my entire roadmap. I probably should, and I know people that do. I generally just use it as a tool to break ties.

So it's a tool for discussion it's a school for unlogged jamming conversations I actually like this to take in a meeting sometimes as like, hey. Let's like break down which of these is more important than the other it helps you get talking to other people in terms of reach and confidence.

And you can argue over things like we think this is high impactful, we think this is low confidence, blah, blah, blah. But at least you're talking about something in particular rather than like, this is more important than this, right? It helps break it down into values that you can talk about.

But I wouldn't take this as gospel cuz I think if you do that, you end up doing probably things that you probably end up deprioritizing some of your betts. And sometimes that product sense, that gut feeling is really important, as a product manager.

Learn Straight from the Experts Who Shape the Modern Web

  • In-depth Courses
  • Industry Leading Experts
  • Learning Paths
  • Live Interactive Workshops
Get Unlimited Access Now