Seven Questions for Better Prioritization
Seven Questions for Better Prioritization
Think that the secret to prioritization is a better formula for weighing features against each other? Think again! According to Maggie, prioritization cannot be done with a formula. Instead, it starts and ends with the why. Looking for a quick framework for how to set yourself and your team up for better prioritization? This episode is for you.
Like this episode? Leave a ⭐️⭐️⭐️⭐️⭐️⭐️ review, hit the subscribe button, and share the podcast with your friends. You can also connect with Maggie on Twitter @maggiecrowley
Maggie: Welcome to Build, this is Maggie. Today, I have a short one for you, but it's something that comes up over and over again. So, I thought it would be worth sharing the way I think about every PM's favorite topic prioritization. The other day, someone sent me a note on Twitter saying their team was doing well, but that they thought that they were missing something when it came to prioritization. And he shared with me how his team prioritizes and what they look at was customer impact, so number of customers impacted by feature, economic impact or revenue generated by feature or cost savings, growth impact, so net new customers that will sign up, or roadmap impact, so presumably how far along this feature in question will get them on the roadmap. And then, all of the projects that they do have to touch on at least three of those categories. Put another way, what it sounded like to me was that the team has a batch of ideas that they're using these questions to figure out of that batch of ideas, which one should they do first. And the challenge with that system is that you can't reduce what should we build to a prioritization math question. It's not possible to be mathematically certain that you're making the right choice. So, instead you have to think in terms of bets and de- risking those bets. And at the end of the day, you have to figure out how you can have conviction about what you're about to do. And if you have a product that has a ton of users, and you're used to operating in an environment where maybe you're doing experiments and you're rolling out experiments to a slice of traffic, and when it wins, you're putting into control. It's easy for this type of mindset to set it on the team that it's easy to constantly compare various experiments and everything's mathematical and you start to lose the most important piece, which is the why. So, you cannot prioritize effectively if you don't start with the goal. Put another way, if you don't know why your team exists or why you're there, you're going to have a really hard time being effective at picking what you should work on next. So, instead what I do anytime I have to prioritize something is start with the why. So, I have a set of questions I start with that help me get at the current goal of when I'm working on whether that's the whole product, a inaudible product, a team, or an individual question. And so the questions I ask myself are what is the current business strategy? What's the product strategy? What are our current goals? What's our team's unique advantage or business's unique advantage in solving for those goals? What's the biggest blocker your product has to achieving that goal? What's the biggest challenge your customer has right now? What's happening in the market with competitors? If there's anything you have to think about with that. And then, I would ask the team, what are you here to do? Or sometimes let's say the PM is maybe getting really aggressive with how they're prioritizing something. I might ask something like, okay, don't think about it, go with your gut. What's the right thing to do next? And I find that that's a really effective way to ask a question of a team that maybe is going really deep and trying to prove out why one thing is better to do than the other thing. And that's often when the direction they feel they have to go in is different from the direction they feel they should go in. And the tricky part is that in answering these questions, you might find that none of the work you have in the batch of work that you started with is the right thing. And congratulations, now you're in it. That's when it starts getting fun as a PM because that's when you start to think, okay, shit! None of the stuff I thought I was going to do is the right thing. Now I get to figure out what the right thing is. And then, I have to figure out how to convince everyone around me that that is the right thing to do. And in my opinion, that's the really fun part about being a PM. So, okay, let's say that you've answered those questions. Now you can do is look at the list of things you were going to build, and I'd suggest here using Teresa Torres's Opportunity Tree Framework. So, take each thing, walk it back and identify which problem or opportunity that thing solves for. Then, take that list of problems or opportunities and compare it against the goal of your team and figure out which opportunity is going to get you furthest along towards your goal. So, you can ask something like what problem or opportunity can we solve that would have the most impact on our most important goal? And generally speaking, I find that there's a pretty clear winner that comes out of that type of exercise, because it's not that complicated. There's only a certain number of things you could really do at any given moment. And let's say that there are actually a couple of really good options. Then, that's a time when I might start to use those criteria we started with to weed out some impractical or impractically risky projects. So, maybe there's a really good idea, but it's way too hard and your team has none of the right skillset, probably a bad fit. Or maybe there's something that you think would actually solve their problem, but it's going to take too long or maybe it's not going to have enough revenue impact. Like those are good questions to start to think about when you have competing opportunities that are both really good. So, let's say there's also maybe a clear winner from your original list. And if you just look at it in comparison to your goals and you say, okay, this is definitely the one I want to do. Then, you can also use those initial questions to figure out what your success criteria have to be. So, maybe you've picked your winner, but then you could use those criteria to say, okay, well we have to get X percent more customers signed up from this feature. Or we need to drive this much incremental revenue for this project in this time spend to be worth it. And I do want to call out that I'm glossing over the whole concept of taking that list of ideas and making sure that there aren't better solutions to the same problems, but that is a just entirely different podcast. Okay. So by this point, you should have a clear picture of your goal or your why and what the project is that you think will be best fit to solve for that goal. Now what's tricky is that there's also day- to- day prioritization that the team has to do. And that's the other type of prioritization. The first part that we've been talking about is the big rock or the headline for the month or the quarter or whatever time horizon you're working on. The second part is, okay, you've picked that now the team has to do the work, right? And then, they're prioritizing day in and day out week to week. And when they're doing that, they have to prioritize that big rock against things like customer requests and internal customer requests, small UX issues, bugs escalations, and then of course, reliability and performance and scaling work. And the messy reality is that you're always going to have to be between all of those different forces. But as long as you have good constraints, so things like high priority bugs have to be fixed in some number of days and a really good grasp of your goal, you should be able to prioritize effectively. And sometimes that's going to mean doing things like taking a detour to fix a couple of small out of place things along the way. Sometimes that's going to mean saying no to literally everything until what you're working on gets out the door. And it's all going to depend on the team and the goal and the mission that they're on. No matter what the most important part of prioritization is the goal or the team's why. And the more clear that why, the better their decisions are going to be day to day, week to week, and the more likely they are to actually achieve that goal. And I want to also call out that this holds true no matter what level you're at. This same exact logic holds true if you're thinking about the entire product. So, when I sit down to think about what we should do next, I start with those same questions. I start with the goal. I start with the business strategy. Then, I move to the product strategy. Then the team's goals. But what's different is that there might not actually be answers to those questions. And so maybe my first task might be to answer them. So, there might be a strategy question I have to figure out before I can move on to the next step in that process. But again, I use the same exact set of questions for myself that I would suggest to use for a team. And I also want to mention that this doesn't mean that the team's work is top- down. This is only a framework for how to make sure that they're prioritizing the right things at the right time. The ideas and the things that they eventually work on can absolutely come from them, but they have to be in context of the business because if not, it's not going to help your business move forward. So, that's it. That's how I think about prioritization. I start with the biggest, most broad why, and walk my way all the way down to what I'm looking at on a given day. Thanks so much for listening. I would love to hear your tips and tricks for prioritization. I would also love to hear why I'm totally wrong and there is actually the mythical math formula out there that's going to make prioritization work. All right, thanks team.