Mastering Product Prioritization: Insights from a Seasoned Product Manager

Speaker A: Hello product people. Welcome to the new season of the Product Perspective.

Speaker B: This year we're diving deep into the

Speaker A: minds of creators, innovators, founders and industry leaders. Get ready to uncover the strategies, stories and the insights that fuel successful products in today's dynamic landscape. So buckle up and let's get started. Hello everyone. Uh, welcome to the Product Perspective. Um, for everyone joining us for the first time, a very warm welcome to you and for our regular listeners. Thank you for coming along the journey with us today we're talking product and specifically the complexities of product prioritization and decision making. To help me understand this better because honestly it's something that I personally struggle with, I'm joined by Gil Pollock. Um, now Gil has been in and around product management for over a decade across Australia, um, and the US Building solutions for customers across fintech, uh, health tech and B2B SaaS. But right now Gil is focused on developing best in class consumer banking app solutions as the digital product lead at ING Australia. I for one am excited to hear Gil's insights, as I'm sure both aspiring and seasoned product managers are also. So sit back, relax and let's get started. Welcome Gil. It's really great to have you here.

Speaker C: Hi John. Yeah, it's great to be here. Um, excited to delve into the world of prioritization which I think is a challenge for every product manager.

Speaker A: So it is, it is, um, well outside of being product lead and a domain expert, you have a lot going on so it's a good topic to be discussing. Um, so you've got coaching and mentoring, angel investing, your own startup thrown into the mix on your, and your repertoire. Um, you must be super passionate about everything product.

Speaker C: Yeah, products are ah, a big part of my life. I guess I'm lucky I stumbled into it um, early in my career like a lot of product managers, um, and it's something you know, I'm passionate about. There's so much content online and there's so many people you can learn from. Uh, so you know, it's, it's a balance between, you know, reading and staying up to date with all the latest product information and also staying healthy, having those relationships and doing all the other things that are important to maintain a healthy lifestyle.

Speaker A: And what got you into the coaching and mentoring side of things? Like you've been in product for quite a while and um, as I mentioned you had your own startup. Um, what led you down the coaching path?

Speaker C: Yeah, I think I just really found out from becoming a manager and being um, and speaking to you know, colleagues and other people in my life that it's something I really enjoy doing. Um, truth be told, like uh, uh, I really was really excited to become a manager because you know when you, when you are subordinate or you, you have so many different managers, you kind of pick and choose what you like and you think you can be the you know, perfect manager. And I wanted to kind of put that to the test and uh, that gave me a taste for that kind of. It's a different relationship but that can kind of gave me a taste for something and I wanted to explore it outside of the work, um, boundaries uh, and in a more like casual and friendly manner.

Speaker A: Yeah, and that makes sense I think um, that with that going on with yourself, so you're uh, you're working, coaching and mentoring at ah, the same time that you've got a lot going on. So taking that back into the day to day being a product manager, um, often prioritization involves making tough choices. So how do you navigate the delicate balance between addressing user needs and technical constraints along with the business's goals?

Speaker C: Yeah, as I mentioned like it's one of the most challenging things about being a product manager prioritization and I think a really good place to start is taking a step back and trying to understand the business's goals and objectives and strategy and then kind of understanding how your team or your specific goals can contribute to the business's success. I think after that when you've got a grip on that, you can start to consider all the different uh, user problems and opportunities in your world that can contribute to your team's success. Uh, so I can give a bit of an example of how I've done this before at ah, um, Invoice To Go in the past if you want.

Speaker A: Yeah, for sure.

Speaker C: Yeah. So Invoice To Go, um, it still is a great invoicing app for small business owners. Um, and when I was working there a uh, CEO came in with a new strategy and the strategy was to grow our payments revenue and he implemented the OKR goal setting framework uh, to get that as prioritized across the whole company. So for folks not familiar with okr, it's a pretty common goal setting framework or methodology. Um, it stands for objective key result. Uh the objective is a qualitative kind of visionary statement and the key results are uh, goals that uh, that are measurable, that kind of infer that you're making progress towards that objective. So Invoice To Go, the CEO came in, said we need to drive up our payment key productive for the business. Uh, he set an objective, you know, get payments to be equal to our SaaS revenue, get payments, revenue. Uh, the key result would have been, and I'm paraphrasing but something like, you know, 20% revenue 20 year on year. So you know, I was at the time looking after a group of product teams mainly focused on the customer, uh, facing products like invoicing estimates. Uh, so I looked at this objective and set my group of teams an objective to increase the invoice payment, uh, invoice paid rate or volume. Uh, the reason being is that this would contribute directly to the uh, company success. The more invoices that are paid, a proportion of them are paid online and therefore, you know, contributing to company success. So then I worked with um, PMs in my team, um, uh, 1pm was after estimates or quotes and I kind of worked with her to kind of identify her results and her objectives. And we settled on, you know, growing the estimate approval rate. Reason being is that the more estimates that are approved lead to downstream invoices which contribute then to the group success and the company therein, the company success. So taking a step back like you might not understand, might not be able to understand the ins and outs of invoice, but the point here is that I'm now in the shoes of this PM looking after estimates. Uh, I'm about, I understand how my success leads to my group success which in their end leads to my company successful. It's a great place to start prioritizing from. Yeah. So after this uh, I think you can then go work closely with your design and engineering counterparts to uh, explore the myriad of opportunities that you can do to address your specific objectives. Um, you know, at this phase, probably starting to think more about desirability and feasibility risks for these initial um, initiatives and comparing them. And that's where kind of the other part of your question comes in, the technical constraints. So when you're working hand in hand with your engineering counterpart, you can kind of start to assess the different complexity of different initiatives and that should factor into what you prioritize and the pros and cons of each initiative. So like, I guess, in summary, I think a really good starting point for prioritization is getting a grapple on what the company's strategy and objectives are and how you contribute to their success and then taking a user centered experimental approach with your design and counterparts to assess the opportunities that can contribute to your success.

Speaker A: Yeah, so here at User Back we actually um, kind of timely for this chat, but we had a Roadmaping discussion yesterday. And um, in that roadmapping discussion the question or we're basically looking at what are we doing over the next 12 months? We're just uh, in the first quarter of 2024, uh, we've kind of completed the majority of things we set out to do for 2023. So what's um, now for the next 12 months do we want to look at? We started with what's the business goal, um, for the next 12 months. And once we understood what that business goal was, uh, it was yeah sure, looking at the technical constraints of the items that might be on the backlog, um, that we didn't complete in 2023 and maybe even 2022, uh, what are the user needs? Um, and at that point in time we kind of looked at that and went well we don't actually necessarily know at this stage for what we plan to do over the next four months what the user needs are. So we need to focus heavily around customer research and understanding more from our users. Um, and this kind of bleeds into my next question, uh, because once we had a kind of solid understanding of this is the direction we want to go over at least the next three months we want to have quarterly themes of what we want to be building. So uh, we've worked that out. Aligning it to the business goal. The challenge there is the trade off um, in terms of the decision making process to align everything on the roadmap to the business goals, making sure there's as minimal technical constraints as possible. Um, the user needs are being met. Uh, but it's then working out how to prioritize the features that you want to build. But then there's also uh, actually I'm going to preface this with, it leads into the next two questions. The first part of this is prioritizing uh, features and how to communicate those choices to stakeholders. Because on one hand an organization might have said hey guys, over the next two years this is what we're going to be focused on. You have a roadmaping meeting and that direction changes because of a new business goal or a requirement. Uh, and then being able to communicate those changes to stakeholders because they may be relaying that information back to uh, customers through customer success. Hey customer. Yep. That big feature that we've been promising you for the last two years that's coming next year and then the business decision make or the business makes a decision and changes that. Um, so how do you communicate that? Um, and how do you evaluate those trade offs when deciding what features to Prioritize.

Speaker C: Cool. Yeah, good question. I think I'll start with the evaluation part first and then go into the communication. Um, so you know, when you're evaluating different opportunities it's a big, again it's a good indication of why the PM role is so critical and challenging because every time you make a decision there's an element of risk and there's a huge opportunity cost. So some kind of, some tool, you can use some tools or frameworks to help you be a bit more objective. Um, with this process. Uh, I think a common one is rice. So RICE stands for reach, impact, confidence and effort. And essentially how it works is you give each competing initiative, ah, score for each of these inputs, you multiply them and then each initiative has a total score. And in theory the initiatives of the highest score you should proceed with. Um, so again I can give a bit of an example about how I use this in the past like to put into practice. Um, so you know, when I first joined Invoice2go, I was an IC and my challenge was to diversify the company away from just being a one product company, away from just doing invoices. Um, so we had our customer base of small business owners, uh, micro businesses. And you can imagine there's like so many things you can do to help them. It's like a myriad of opportunities. So what we did is similar to what you said before we started speaking to customers doing discovery. I was working really closely with some great designers, uh, engineering people and uh, a researcher and we started to kind of map out our top opportunities. But we didn't have enough confidence any opportunity to go further and like go full on. So what we decided to do next to get more confidence, we built some prototypes and uh, devised some prototypes to test the hypothesis and assumptions that were behind each of these opportunities. And you know the funny thing I recall is quite quickly you rule, you building prototypes, you kind of work out which initiatives, opportunities you don't want to do and uh, aren't received well. So one such example was we were exploring helping our small business customers communicate more effectively with their clients. I think we probably all had an experience at the tradie or small business owner where they're not, you know, where you don't get the communication you, you desire, it doesn't maybe live up to your standard. So we want to help with this. But you know, quite quickly after building this prototype we got really quite negative feedback from both the customer, our customer, the tradie, uh, and in addition to that, you know, the engineering team Worked out that if we are to build this, it's a ton of work. So just using that RICE framework, this scored really poorly, um, comparing that to something we did proceed with. So we were also exploring through our discovery, we kept hearing, you know, customers, they struggle to stay organized, so they have information scattered across different applications. So we built kind of a tool to centralize this information on Invoice to Go, which is great for the business engagement with our platform. Um, but the prototype also was received really well and great. And finally the cherry on top was that the engineering effort wasn't very large, especially compared to other opportunities. So this scored really well on the RICE framework and we decided to proceed with it.

Speaker A: Yeah, I think uh, the Rise framework, we use that here internally as well. Um, and we just build a matrix of all the things that uh, we would like to be building along with all of the ideas that customers have submitted. Um, but combining that with that experimentation, culture and building something small and quickly, especially in B2B SaaS where things move and change, um, in an instant, the market changes quickly. So you need to change with that, um, or at least try to get ahead of it. Um, that RICE framework can work really well to validate. Once you've validated an idea, work out. Is this something that we really actually can be, um, going all in on and building? Because it may turn out that the effort is way too high for the return, um, back to the business. Um, but I guess that um, mentioning the, the customer ideas coming in, um, uh, along with what you've got planned on your roadmap, um, there can be conflicting demands that arise. So whether that's from customers asking questions or uh, new leads coming in, um, giving feedback back to sales teams, uh, look, we really need these features. Can you build them before we sign the contract? Um, so how do product managers, um, reconcile these different conflicting demands to ensure, uh, everything is really well prioritized on the roadmap amongst everything else that product managers have to be building and dealing with?

Speaker C: Yeah, it's again a tough, tough ask. There's uh, always going to be conflicting views internally about what should be done and there's always going to be like conflicting data points as well. Uh, I guess it's a product manager's job to sift through the noise and find what matters. Um, and ideally make the right prioritization decisions. Um, but it's also really critical to give stakeholders the rationale behind it because I think stakeholders don't have to agree with prioritization decisions and they won't Always. But they have a right to understand the rationale behind it. A good place to start is, um, I recommend PMs who are looking after a product or feature, develop and communicate a strategy and vision for that product. Um, you know, this includes like, where you're going, what you're going to do, um, maybe some milestones to get there and how you're going to measure success, but also what you're not going to do. And the reason I think this is valuable to deal with internal stakeholders is because even before you get to planning season or whatnot, you're giving stakeholders the context of what you're doing and the insight behind why you're doing that. And uh, you can have discussions up front, but when you do get to those prioritization moments, it should have, you've already set up guardrails for the discussion. So I think that's a really useful first step. Uh, regarding, you know, divergent customer feedback. Um, it's inevitable, especially if you have a lot of customers, um, which is a good problem to have at the end of the day. But, you know, a good tool to use is, um, a tool I've used successfully before is, you know, grouping your customers. So something like customer archetypes, customer Personas, um, and when you, what essentially what is you're grouping sets of customers based on, uh, there are nuances between a Persona and an archetype, but at high level, you know, based on customer profile characteristics, attributes, motivation, pain points and et cetera. And when you do group and have these groupings of customers, you can then identify when you're solving a problem or building a solution, which customers you're targeting versus which you're not. And then when you do get feedback in, you can quickly look up the customer and you can say, is this relevant to the problem I'm solving? Is this relevant to the customer I'm trying to help? Or if not, you can quite easily disregard it, which is a really useful tool because again, one of the things that's challenging about a product manager is like, there's a lot of distractions. You're pulled in multiple directions. So anything to kind of make quick decisions is very valuable.

Speaker A: Yeah, you're right, um, in that a lot of product managers, they fear, um, opening up the, the floodgates so to speak, of customer feedback, um, and even internal feedback as well, because they're already so busy and maybe overwhelmed with, um, with existing projects that they have to get done on their, their roadmap, however long that is, um, that when they open the floodgate and start collecting feedback. There's all this other stuff that they have to try to deal with and once you turn it on it's very difficult to turn it off. And as soon as it's turned on, the people that are providing the feedback, there's kind of that expectation that hey, you're asking for feedback now, we expect you to do something with it.

Speaker C: Uh, but again I think it's a good problem to have as a product manager. There's nothing more I love doing than going and sifting through product feedback. If anything I'm a bit addicted to it and it can be a bit of a time suck and I got to pull myself back out of it. Be like this isn't the best use of my time, I'm procrastinating or something.

Speaker A: Well, that's all you mentioned. Or um, that methodology of just looking at um, who the customer is and um, what problem they have and that's uh, really valuable in that case. Um, one of the things that we do here is we look at the feedback we're collecting and who that, what the business type is. And if they don't match the business type of our ideal customer profile and the feedback that or the idea they're suggesting or the feedback that they're giving doesn't necessarily align with our, the product direction or the business goal. Because usually feedback um, is self serving. You're giving feedback to make your life easier. So if you're targeting um, if you're targeting plumbers for example, and an electrician is providing feedback because hey great, they're using your product and they get value from it. But if they're suggesting feedback that benefits them and doesn't necessarily benefit a plumber, you're less likely to action that.

Speaker C: Exactly.

Speaker A: So outside of the RICE framework, um, and also looking at the customers that are giving feedback, even um, from internal stakeholders as well, um, are there any best practices that you can suggest for um, continuously reassessing and refining priorities as the product landscape changes? Because I guess one thing to ask before you answer that is how often should you be looking at what you're building and how often should you be looking at those outside forces that are giving you lots of ideas and feedback?

Speaker C: I think the most important thing here is to ensure that you keep delivering small incremental value to your customers. This means breaking down your features into really small increments and shipping often. Uh, the reason this is important is if you do this you'll continuously get data and qualitative and quantitative from customers that may inform Whether you need to reassess your roadmap. Uh, I think a good practice to do this is to use another framework, go figure. Um, called Moscow. Um, so Moscow stands for must build, should build, could build, won't build. Um, and essentially what you can do, it's a really simple framework, but you can go through um, in your refinement sessions with your team, um, all the user stories that need to make up a feature and assess with this very simple framework what's absolutely essential to adding value and getting this feature out. Um, that way you can ideally ship more things more frequently. Um, it's interesting. It's an example of how we've talked about prioritization on multiple levels. Um, this example, how this is prioritization on the user story level within a feature. We've already talked about prioritization of features and now we've already talked about prioritization of products. It's just one more example of how prioritization is an everyday task for pm.

Speaker A: Um, we're talking about small features here. Um, how frequently or what would be the cadence of releasing a small feature to a customer?

Speaker C: Well, yeah, it really, you know, features can vary the definition of company to company, but you know, coming at it, experimental mindset. I can. Can you in add, um, can you validate experiments or validate assumptions by shipping something and getting more insight? Uh, that could inform whether you need to like change, protect. Uh, so whether it's a whole feature or it's an enhancement, what it even, you know, it could be at least to a small beta pool. It doesn't really matter as long as you're basically de. Risking your roadmap.

Speaker A: Yeah, that makes sense. Um, I think smaller, more frequent releases, um, at least in my opinion it does more than just help validate ideas. Um, before you go and spend time building them out, um, it shows customers or users that you know, you're. You're building out the product, even if it's something small. And it gives, it gives the marketing and communications team something to talk about so that you're communicating regularly with your users.

Speaker C: Yeah, And I think another thing is it gives your team momentum. There's a lot of momentum in product teams. And if you're continually building and building and building shipping, it can really be a drain on the team.

Speaker A: Yeah. What's that saying? Momentum builds momentum.

Speaker C: Yeah.

Speaker A: Um, so for anyone that is aspiring, um, or you know, a seasoned product manager, uh, and they're looking to upskill and learn, uh, how they can actually, um, I guess build prioritization and Decision making skills. Um, is there anything that you have in terms of advice or where they can go and look or a book they can read or course they can do?

Speaker C: Yeah, I think, like advice, like there's a lot of, there's a ton of content online, um, and sometimes, and I've talked about a few frameworks and I think it can lead people to take and put too much effort into coming up with the perfect imports for rice or you know, going way too, uh, taking Moscow way too seriously. They're just mental models and frameworks to help guide your decision. So don't overthink these things and don't put in too much time because the ROI I don't think is there. Um, I guess the other thing I've talked about a lot, um, is that prioritization is a team sport. It's a, you need to bring in your design and engineering counterparts early. Uh, and they have a unique perspective. Um, but also, uh, they'll make you, your, your decisions that you end up making more effective. I think something that's not often spoken about, about bringing these folks in early is that my experience, when you make a decision and your, your team is right really behind you, it's really compelling to stakeholders. Uh, they can sense that they're being brought on the whole journey and they're backing this decision that at the end of the day the product manager is accountable for but the whole team has been a part of. So I'd say that's something that, ah, it's a really great feeling, uh, I guess finally, you know, de risking um, by delivering in small incremental chunks like the old days where you used to deliver something in three months, it's a huge risk. You don't know. It's every, every piece of work's got tons of risk. If you invest three months before getting in front of customers, it's very, there's a good chance, you know, you missed the mark, you needed to rework or it completely is off the mark. So shipping in small incremental chunks is great practice. Not just for prioritization, just for management. And it will make your life a lot easier. You, um, mentioned books, Um, I think a really good book, uh, about decision making in general, uh, is decisive by the, um, Heat brothers. Um, one of the key lessons I learned there is, you know, when you do explore um, opportunities, make sure you go broad and explore multiple solutions. Um, because you can be blindsided by just being, having narrow vision and being, you know, have a lot of confirmation bias or emotional attachment to A certain solution.

Speaker A: Yeah, I, yeah, I completely agree with that. Um, one of the things, well, at least I've learned about um, in this short chat is the Moscow Framework. So I'm going to go offline and um, learn a bit more about that and how we might be able to use that internally here along with the Rice, um, uh, framework as well. Uh, that's really interesting. I think, uh, when you're talking about having your whole team behind you, uh, and having conviction on something that you are building, uh, something to help with that is just communication. So having really good communication skill set, um, making sure you're talking with people early on, um, from concept and bringing everyone along for the journey. So it's not a very last minute, hey, this is what we're doing. And then people sitting there looking at each other. What, what are we doing? Why are we doing it? Asking lots of questions.

Speaker C: Yeah, yeah. Um, and, and I think like, you know, communication is central to the PM role. Right? You have to convince people, influence people without being their manager. Um, and uh, there's a lot of accountability. So how you do that, uh, I think it's important that PMs understand the norms of their company and how they can, you know, sit within them. Cause every company communicates differently, um, and be effective.

Speaker A: Yep, absolutely. Um, Gil, thank you so much for joining. It's been a pleasure having you. Um, I have 100% learned some new things, um, in this episode and I think our listeners will have as well.

Speaker C: Thank you. Great being here.

Speaker B: Thanks for listening to this episode where Gil and I ran through product prioritization and decision making for product managers. Some key takeaways include understanding the importance of aligning product goals with business objectives to utilizing frameworks like RICE and Moscow, uh, for evaluation and prioritization. One thing that I keep being reminded of when talking to product leaders is the need for experimental mindset and delivery of small incremental value to customers. This, combined with the role of effective communication in decision making and the endorsement of a team centric approach to prioritization is a recipe for growth and success in product. Thanks again for joining us. If you'd like to hear more from product people like Gil, subscribe to the podcast and feel free to get in touch with me with any questions or suggestions for the pod on LetsTalk at userback IO. Until next time, bye for now.