Don’t prioritize… say NO!

Welcome everyone to another episode of the Product Bakery. Today again with my co-host and myself. Hi Alex. As usual, before we start in the conversation, I wanted to remind you that we have all our episodes on our website. If you type product-bakery.com in the browser, you can get there. And what's new is that we have comments turned on all the episodes, which also means that you can directly interact with us, with our speakers, as well as everyone else who listens to the podcast. So feel free to go there, check it out, leave your comments, questions, and we're happy to take them on in our next episodes. As well, you can also follow us on our social media channels for some more visual updates on Instagram or LinkedIn. And please feel free to share the Product Bakery with all your friends or colleagues. And with that said, Christian, I brought a really nice topic today, or at least nice for me, because I think it's something that I constantly come across. And it's the topic around prior prioritization. And more than prioritization, also the topic of saying no. And we've talked about this a couple of times. And product managers are famous for saying no to pretty much like every request. And we know it's like somehow related to the roadmap. It's somehow related to priorities. But I think you're constantly faced with feature requests or with ideas from everywhere in the organization, minor bug fixes, bigger bug fixes. Everything at one point reaches the product manager. I really wanted to get a little bit like your view on how to best prioritize things. No. Should we close it here? No. Okay, that's good. Okay, then we can go on. I just shared with you what you need to be a good product manager. No, two letters. Two letters, one word. Just say no. Yeah, it's a tough topic. It's a tough topic. What's the secret sauce? Alex, we don't talk about sauce. We talk about bread and floor. And, you know, you cannot drag that away from the product bakery. What's the secret ingredient? Come on. I really want to get to this conversation. Yes, I know. Prioritizing is generally not an easy topic. Just to share where I come from, I had back then the issue of not knowing everything, which is also part of the job as a product manager. But there are a couple of basics you should take care of. So let's say doing your homework. And you maybe remember once when I was explaining the story of Leonardo da Vinci, the one from the backlog management episode. So my point is, it's important to do your homework, first of all, before you are able to give an answer, to say yes or no, or to take things into consideration. And then something that I was not good at the beginning of my career was making decisions and saying either yes or no. You have 10,000s of stakeholders, a lot of requests, a lot of wishes, bug fixes, etc. But you have just limited resources to solve or to fix them. So there is no way around it. You have to say no at some point. One thing that I was doing wrong was trying to please people or trying to follow my gut feeling instead of inquiring more. And based on that, I also messed up the sprints with too much scope or wrong decisions. And therefore, it's first of all, before we talk about the solution, or let's say there is maybe not a solution, but the ingredient. First of all, self-awareness, I believe. Self-awareness, about what specifically? Self-awareness in terms of, have I done my homework? Did I do the best that I can do to get my information in a certain time frame and to be able to make a call? But I think one thing that I would be curious about there is, if I already have a lot of tickets, stories, ideas, and I know I want to work on them, and I get different requests in, how do I also prioritize? You mean additionally? Additionally, additionally from other stakeholders. So how would I prioritize or balance also the work that I need to spend to do my homework on these tickets to make an informed decision on where I put them on my planning? Let's imagine we are a team, I don't know, five, six, ten people. And we have our company vision, we have our product vision, we have our OKRs. So this is something you're working with in your day-to-day business. That means this is something that gives you the guideline for your upcoming sprints and also to be able to understand in which direction you're heading at the moment. In case you don't have that, obviously that sucks. You have to go back and do your homework. But when additional requests are coming in, then you have to reevaluate and reprioritize eventually. So that's a normal thing that you go back and as a product manager, so let's say it's, I don't know, we have our sprint plannings on Monday. And on Wednesday, we get a couple of tickets in, bug tickets, additional requests, the button needs to be blue or red because it's better converting because we have done research. Let's assume that. So now we need to evaluate what do we have in the sprint and do the new tickets help us achieving our long-term goal or bigger goal like the OKRs or the upcoming release or the customer request that we have promised to the customer to deliver. So you need to go back and forth and check what's possible and what not, and what fits into the big picture. And if you have many things that are important, you will still realize at some point you cannot achieve everything. So in that sense, if you have to make the decision, what delivers the most value in the shortest time? For example, sometimes you also have to work on the things that deliver a high value, but take a lot of time because of internal dependencies. What I like doing is always looking at, for example, value risk or value effort. So there are many tools out there that you can use. You can use an ICE score. There are a gazillion of things, but it maybe starts first of all at looking at the quarterly goals or the product vision. So you take the vision and then you try to use one of the frameworks to balance it against it. Now, maybe to bring it a little bit more to the direction of the relationship obviously between the product manager and, for example, the designer, because you brought up earlier, and I quote, you've done the research. If we speak about dual-track, agile, or generally cross-functional teams, you also need to prioritize the discovery. And I had a fun conversation today at work exactly around this, because obviously when you have to prioritize discovery and you are on an early stage process, or you're generally early stage in the product or in the feature specifically, there might be a lot of things that you still need to uncover. There is obviously also a lot of different effort that you need to put in the discovery phase or in the research phase and so on. Absolutely. So how do you balance these topics? And you can tell me, it's on me as a designer to give you the right priority when it comes to research, but how would you prioritize it? Yeah, first of all, I would love to work with a designer who supports me on that as much as possible. So I see that, and maybe some people would disagree with me, but the whole backlog management part and the whole feature sprint planning part, ideally that should not take more than 10% of your work. So the ceremonies and all that stuff, and also having the groomings ready, refining the tickets, writing the tickets, doing the sprint planning, in the best case, 10%. Let's say it's 25%. That's fine. So what are you doing the other 75%? Here comes exactly into place what you just mentioned. This is the time where you have to sit down with your VP product, for example, as a product manager, with your co-working designer that you are very close with, that you love, and you need to make a plan together. So it's not like that I'm coming just up with the priorities because in quotes, I understand the business, or I have the domain knowledge. This is team effort, and this is something that needs to happen together. And it also needs to fit into the operational and strategic goals of the company. Let's say you are my VP product. You are focused on the product vision and the product strategy very likely all day. So you have exactly in mind what needs to happen in which order or things we need to uncover. And you will also very likely challenge me and my designer together with the VP design. It's an interaction that needs to happen, and it's a plan that needs to be mapped out together. But I would also love to know how you see that. Yeah. And with the discovery, it's a bit challenging, right? Because I think what you mentioned earlier on, when it comes to providing a lot of value in a short amount of time, it needs to be true for all tasks. But I think when you talk about research tasks or discovery tasks, you also need to look at, okay, where can I generate insights that are valuable for the whole business? And it's pretty much like also weight that one in, right? Because you might have some longer studies. You might have some more ethnography studies where you try to really go deep on behavioral patterns and so on. That might not be like, I have an assumption and I'm now proving it with a very quick experiment. And we had the session on lean analytics, which I think was super valuable when we talk about how to actually create quick experiments with a mindset of also throwing things away. But I think it's important to find this right balance and to have both on the roadmap, let's say. To be honest, I see this as a kind of separate project here because we have this whole discovery work and within that discovery work, I believe you need to do the same. First of all, understand what you want to understand in the future. You maybe have a list of things that you want to discover and then you need to evaluate and also figure out what will first of all be achievable in the shortest time. But on the other hand, what is relevant to make sure we are also ensuring to building the right things for the future in long-term or mid-term. Yeah. Yeah, no, absolutely. It makes totally sense. So to wrap it up, I would say no is always a good start, but don't just say no. Say no to the right things and say yes to the right things. Yes, but also tell people why you say no. And just don't reject feature requests or something that comes from customer support or whomever and just say no because people are bothering you or because you are sick of saying 10,000 times no. I really recommend take some time, explain people why, because then you will be less annoyed in the future and it's also a foundation for better communication and teamwork. Final question, just because it came to my mind. I know we're running out of our 15 minute slots. One of probably the trickiest things is to say no to something where it's like super important for a stakeholder. And personally, it's something like he keeps requesting, but you simply know it's not providing enough value to compete with all the other requests. So it will probably not make it to the roadmap, let's say in the next years. How do you deal with that? First of all, bring tissues to the meeting. But yeah, Alex, exactly as I mentioned, you need to explain what is currently in the roadmap and why it delivers more value and why this personal request cannot make it to the roadmap for a certain amount of time. What I always did is I was saying not within the next six months. I'm always very clear about that and also direct, but I leave it also open to the person to say then, hey, after six months, just contact me again and we have a chat. Yeah. Or bring some data points to prove me wrong or whatever. That's even better. Yeah, I agree. Cool. Christian, thank you so much. Nope.