Effective techniques to prioritize your product roadmap with Rajesh Nerlikar from Prodify Group Product Stories Effective techniques to prioritize your product roadmap with Rajesh Nerlikar from Prodify Group Play Episode Pause Episode Mute/Unmute Episode Rewind 10 Seconds 1x Fast Forward 30 seconds 00:00 / 00:43:27 Subscribe Share Apple Podcasts Stitcher Google Podcasts Spotify RSS Feed Share Link Embed ' class="input-embed input-embed-2236"/> Summary In this episode of Product Stories, Victor Purolnik talks to Rajesh Nerlikar, Co-Founder of Prodify, which helps SaaS startup founders, entrepreneurs, recruiters, executives, and product team leads become more product-driven by offering advising, coaching, hiring, and product management services. Episode Highlights/Topics: What made Rajesh go into product? Interest in customer problem space and UX Product Discovery: Conduct focus groups to talk and listen to voice of user/customer B2C or B2B: Rajesh prefers B2B2C—product changes consumer behavior at scale Always Be Prioritizing (ABP): Impacts success of a business and solves problems Prodify’s Framework: Vision-led product management w/ innovation, iteration, operation RICE: Reach, impact, confidence, and effort framework introduced by Intercom Prioritization Techniques: Who to build for, what outcomes to deliver, and how they rank Customer Journey: Create alignment to emphasize customer-centric product vision Features/Feedback: Conduct qualitative research to evaluate ideas and align with vision Product Market Fit: Find out if product solves problem right now in market for customers Product Management Tools: Create way to balance and organize information and ideas Resources/Links: Trustshoring Rajesh Nerlikar on LinkedIn Prodify Group Build What Matters by Rajesh Nerlikar and Ben Foster The Lean Product Playbook by Dan Olsen RICE: Simple prioritization for product managers – Intercom 20 Product Prioritization Techniques: A Map and Guided Tour on Career.pm Atlassian/Jira Trello Productboard Notion Read the transcript Victor [00:14]: Hey, welcome back everybody. Today’s guest is Rajesh Nerlikar founder of Prodify. Prodify help SaaS companies become more product-driven. They do coaching, advising, hiring, they work with clients and product management topics such as vision, strategy, KPIs, rope mapping. And so what we will learn from him today is how to prioritize our rope roadmap and how to decide how to spend our precious R&D budget to build what matters. Rajesh, welcome to the show. Rajesh [00:45]: Thanks Victor for having me, excited to be here. Victor [00:47]: Yeah, absolutely. What have you been up to the past years? What made you go into product? Rajesh [00:54]: Yeah, for sure. The core answer there is just kind of a keen interest in the customer problem space and user experience honestly. I’m super high level about my background. I’m an engineer, turned to MBA, turned product guy. So I worked at as a software engineer at Accenture here in Austin, Texas, and part of their government practice. Found myself drawn a little bit more to why our clients were asking us to build the software that I was building, than I was actually building. [01:21] And so I stepped into a business analyst role and started working with clients directly to design the user experiences that they were using to serve their citizens. It was kind of like public assistance benefits, food stamps, Medicare, Medicaid. That was kind of my first step in. And then I did an MBA, got into the world of startups and then have spent a decent amount of time doing product at startups. And then about four years ago left a role after a company I was at got acquired by a slightly larger company in the financial services space and have been doing product advisory and coaching work now for four years. [01:56] So as you mentioned, Prodify does exactly this. We’ve probably worked with about 80 companies in the last seven years. I’ve probably worked with about 35 now myself as a product advisor coach. And as you mentioned more recently, a little bit more as a recruiter as well. Victor [02:09]: Oh, nice. I mean, that’s very impressive because I always say product managers come from various backgrounds, you seem to come from all of them, which is very good and very helpful. Now how did you get into UX specifically as well? Is that a part of the interest? Rajesh [02:24]: Yeah, so I think I’ve always thought about UX and I’ve been always drawn to the consumer product side of things. And so honestly, one of the things that drew me at Accenture was trying to think about what does the citizen experience look like as they’re applying for these public assistance benefits and how do they find out about the application status and all those things? And so that was actually what triggered a desire to work more closely with clients. [02:44] And then I was so interested in consumer products that during my internship at business school, I went to go work at general mills. I thought maybe I should go all the way into the CPG industry, which is of course very consumer-driven. And I worked in consumer insights and honestly ended up missing the tech side of things than what I was doing before at Accenture. And so I ended up turning the offer down. But what it helped illuminate for me is basically today we would call it product discovery or customer development and just conducting focus groups and standing in a grocery store and talking to people while they were shopping. [03:17] Those are things I really enjoyed because I immediately got to hear the voice of the user and the customer. And so it’s been something that I’ve always thought about and I appreciate the time because it helped to kickstart my interest in customer discovery and brought some of those concepts over to the digital side of things. Victor [03:32]: What do you like more B2C or B2B? Of course there’s also a customer user that the role is the same, but I guess it’s also different. Rajesh [03:40]: It is. I actually have basically specialized my entire career in B2C and I like that because I have the customer and the sales side of things. And how do you figure out what the buyers are looking for? But then at the end of it all, it’s like the job of the product is to change behavior at scale with some group of consumer. And so I’ve worked in AutoPower. The utility companies bought our product and the energy reports were intended to encourage people to reduce their energy usage at home. [04:10] But that was hundreds of thousands of households across the utilities, like coverage, area [04:15 inaudible] wallet. It was an employee benefit for financial wellness. So the HR department usually bought it and then we rolled out to employees and we helped them build savings, pay down debt, prepare for retirement. And so we had to think about the consumer experience as well for all the employees afterwards. And so I’ve enjoyed that. It’s a good balancing act between the business side of things. And why do B2B buyers buy things and then how do you change behavior once they do so at scale on the consumer side. Victor [04:41]: That is what I wanted to say. It’s a lot of stakeholders you got to manage. So right up your alley probably as a product manager, great challenge. I guess that is the perfect segue to prioritization in the end. Why is that so important? Why shouldn’t I just start building things, throwing tasks at developers? How does that impact the success of my business? Rajesh [05:05]: I think it’s foundational and I think early stages of startups it’s fatal if you get the prioritization wrong and I know we’re going to do a deep dive here into prioritization. I think about this in two different ways if you’ve ever read Dan Olsen’s The Lean Product Playbook, he introduces the problem space versus the solution space. And I think there’s a set of tech and prioritization is at the core of product management. I use this ABP acronym. A lot of sales people say ABC, which means always be closing as a salesperson. For product folks I’m always thinking ABP, always be prioritizing. So I think it’s something that I think about a lot, which is, where do I spend my time? [05:44] Is that the right place? Is it meaningful to my clients and all those things? And so I think there’s the problem side of things, which is like, what are the problems we’re solving for customers? Or we’ve started using more of a vernacular, talking about what are the outcomes that our clients seek or our customer seeks. And there’s an infinite number of ways to answer that question. And I think a key question on the prioritization side is what are the top two or three things that people are really trying to accomplish or what’s keeping them up at night. And that’s how you know that you’re solving a problem that’s meaningful that they’re willing to spend time or money or both with you and your product to help them achieve that outcome in their life. [06:20] And of course we’re complex. We have person lives, we have work lives. And so it’s important to understand that context where this problem ranks on the list of things that someone is worried about or that they’re really trying to achieve. So I think there’s that problem, safe space prioritization. And then there’s that solution space, which is, even once you found a problem that they’re trying to figure out or that they’re trying to solve or an outcome that they’re trying to achieve, the solution space prioritization is, what is their existing solution and what’s wrong with it that they would even consider switching away from what they’re doing today? [06:51] And sometimes what they’re doing today might be sort of nothing. And they’re like, well, I’ve never thought about how to solve this with a digital product at all. Or it’s often something, and I think if you get into the B2B space, you’re often competing with spreadsheets in the SaaS world, or maybe there’s another SaaS product that they’re using that just isn’t cutting it. And so I think prioritizing solutions in a way that it’s meaningful to the customer or the user and they would be excited to switch away from what they’re are doing today, or once they’re using your product, kind of zooming into, well what’s the next set of problems that they have and some of those problems and the prioritization exercise might be. [07:28] What do we need to fix with the existing product versus what are some of the big things strategically that we need to start doing where our current product doesn’t even support our customers and their needs in certain areas. And it makes sense for us to expand. So like I said, the prioritization is foundational. I think there’s startups, if you prioritize the wrong problem or the solution is just not there, it’s fatal. So I think that’s kind of why prioritization is so important. Victor [07:52]: That’s very interesting the way that it’s twofold. Firstly, what are the biggest problems and secondly, what are the problems that just haven’t been solved yet as well or not in the way that we want to tackle it? So I understand now prioritization is key. Got to make sure I solve the right problems. How do I go about that? What frameworks exist? How does a product manager do that essentially? Rajesh [08:20]: There is no shortage of frameworks for product folks. And before we did this, we have our own framework. We call it vision-led product management. In that context, we think about prioritization in trying to achieve a vision for what you want your customer experience to look like over the course of a few years. And so we have three categories of product development and we suggest a different prioritization techniques for each. One is innovation, which is, what are the progress you’re making towards the vision? [08:47] Hopefully customers and employees and investors would consider your vision exciting and innovative. So there’s innovation, there’s iteration, which is what are the changes we might want to make to our existing product, to like resolve usability issues or optimize conversion, funnel rates, adoption, feature adoption and all those things. And then there’s a third bucket that we call operation, which is basically the cost of modern SaaS platforms. Performance, security, uptime, bugs, internal tools. [09:15] And what we realized is these are the three categories that most product teams are sort of grappling with at any given time. And so we had a prioritization framework for each, with the first bucket innovation we kind of talked about, Hey, what you really need to do is sit down and think about a vision for what you want your customer journey to look like at some point in the future. And once you have that, you can work backwards and identify a strategic plan is effectively a multi-year roadmap for why you would sequence the things that you don’t have today versus what you would need to have in order for that vision to be alive, come to life. [09:47] In a particular way once you’ve done that and gotten some alignment internally and with customers, that’s the right sort of like multi-year roadmap, then you can start plucking things off the top of the list and saying, well, one of the first gaps we need to fill is this one, as an example, it might be like, well, we don’t have the data that we need in order to do this next thing that we know we want to do later. So we need to build the product features that allows us to collect the data so we can go build the cool features on top of it later. [10:11] And so that’s an example of how you might prioritize at the strategic level of multi-year and sequencing. Why would you do this thing first versus second? I think a classic example of this that I just mentioned with the data one was LinkedIn. They create the professional social graph first to figure out who worked where, and who worked with who and what did the connections look like before they decided they were going to monetize it with, recruiting and sales products and charging money for those folks was to go reach out to people. And once they knew where they worked and what their title was. [10:41] So that’s an example of on the innovation side On the iteration side, I think one of the most common prioritization frameworks I see out there is one called Rice. It’s kind of made famous by Intercom, or at least they wrote the blog post on it. It has the R stands for reach, impact is the I, confidence is the C and then E is the effort. And so what this does is you basically say, okay, we have a lot of ideas for what we can do with the product. Let’s score them on each of these four categories. [11:08] So reach means how many customers or users would be impacted. Obviously the higher, that number is the better it’s going to score. Impact is how big of a deal would it be if we actually made this change to our product, some changes are small. We talked about iterative changes. You may move around a button or two, or clarify how a feature works. That helps more people to adopt it or use it. That’s different from launching a brand new product or launching a new feature. The impact is probably a little bit different. [11:36] Confidence is how sure are we, that this is actually the right thing. And I think that this comes from a few different sources. I typically break it down into three. One is quantitative. Can we look at the behavior of our users as an example and identify that this would be meaningful. And we see that they’re dropping off at this point in the conversion funnel. If we built something better here, we could increase this from 20% to 40% and that’s meaningful to our business for these reasons. [12:00] So there’s quantitative, there’s qualitative, which is we’ve talked to a lot of folks and anecdotally, we’ve heard either directly from customers, directly from users or through our sales team, through our customer success team or our client services team that these are the issues that clients or customers are complaining about inside of the product. And then I think in some instances, the competitive source is another place where confidence comes from, which is that you look at how your competitor’s product works. [12:26] And the reason sometimes you may say we should prioritize working on something or that we’re confident that this is the right thing to build is because you realize that your customers themselves now consider the way that your competitor’s products works to be standard or default. And they have an expectation that all products inside of your category, kind of do X or Y. And if you don’t, then it’s almost you got to check the box to stay in the game almost. And so I think that’s where confidence. [12:53] And then the whole framework, Rice framework divides by effort. And so what this means is you think about how much time would it take to build this thing? And so the one caveat I’ll just say about rice is that if you look at the math, when you divide by effort, what this means is you’re really just going to identify all the quick wins. It’s pretty rare that rice is ever going to spit out something that going to take you 18 months to build. Because if you stack rank it with something that’s going to take one month, that’s always going to end up at the top because of the denominator is there. [13:21] So I think you just have to be cautious. This is why we typically recommend using rice as a part of the iterative category of work, which is what are some of the quick wins or the small changes that could have a meaningful impact? And you want to have some balance of those during the course of time. And then that last bucket was operational. And I think rice is probably a framework there. I think you might look at the KPIs, which is you might have a uptime SLA, even with some customers, 99.9% uptime. You might have performance one, which is like, Hey, the API will return a response within like one millisecond and 99% of the cases or something. [13:53] You might have some security requirement where you might measure risk, both qualitatively and quantitatively, especially if you work in a regulated environment. And so you might look at those KPIs and say, what are the things we need to do to really move the needle on these KPIs? And I think gets a little bit into sort of outcome-driven prioritization, which I’ll talk about in a minute, but I’ll pause there and just see if there’s any questions about how we recommend different prioritization techniques for innovation, iteration and operation. Victor [14:19]: That makes a lot of sense, actually. So we basically looked at rice, which is the quick wins because I check, what’s the opportunity that I have divided by how much effort does it take versus which is short term, which identifies low hanging fruits versus your vision led approach, which basically gives the multiyear outline towards a certain state. So I think here, it would be great to explain what is a future customer journey, because I think that plays a big part of that? Rajesh [14:53]: Let me back up and provide a little bit of context on why we even created a framework that we called vision led product management in the first place. Like I said my co-founder Ben and I have worked in mostly startups for like decades, basically, if you kind of combine all our experience. And then in the last seven years, as I mentioned we’ve probably worked with about 80 companies. And during that time we started identifying some patterns and trends and some commonalities of the things that companies were coming to us with in terms of the product problems or challenges they were facing. [15:21] And we realized that for a lot of them, they had sort of found some early product market fit. So they had a handful of customers, the product was doing relatively well. And one of questions that comes up there is like, especially as you think about fundraising and telling the story about what could we do if we were going to grow faster is, well, there’s like three or four viable pathways forward. And it’s not exactly clear which one is the right one to sort of pursue because all of them, you can make a case for. [15:48] And so again, it comes into a prioritization problem, which is like, which of these are most meaningful to solve. It’s going to help grow the business and create investor returns and create insane customer value in the world and those types of things. And so we realized that the framework kind of includes some prioritization techniques to identify who are you building your product for and what problem or outcomes are you trying to deliver for them? And how might you rank those against each other to identify like, Hey, this product opportunity space looks drastically bigger than this other one for these reasons. And therefore it’s probably worth us thinking about and pursuing maybe even pursuing it. [16:21] But in order to say, where is all this going? I think there’s a storytelling element of like, Hey we do have a product vision. And I think that vision is so important for a few reasons. One is, with investors, you got to tell a story of where’s our product headed? Why is it exciting? Why is it innovated? Why is it game changing? How could this be the next billion-dollar company? For customers I think it’s really important, especially if you sell into the B2B space, especially with enterprise clients, they’re not just buying today’s product, they’re signing like a three year deal with you. [16:50] And so they’re buying today’s product plus a direction of where you’re headed. If you never explain where you’re headed, then this is where the sort of like random customer feature request starts becoming a problem. Because if it’s not in line with where you were thinking about taking the product, then it creates a lot of tension internally between the customer facing teams and the product development teams, is that there’s no alignment. And then you feel like you’re just constantly responding to feed back. That’s irrelevant to where you’re trying to take the product. [17:16] And so we talk about this future customer journey as an artifact, that is a way to express the product vision. It’s not just a single statement that says we’re going to be the number one company in this product space or this market. And it’s not like a bulleted list of features, which taken out of context wouldn’t mean anything to a given employee who you’re trying to inspire with your vision or a customer who you’re trying to explain the direction. So what we think of is that it should be a customer centric artifact that explains how a customer’s life is going to be better, in some future state, typically a vision. [17:53] We usually start with three or four years into the future for most companies. And so there’s a lot of different ways to express that vision. We have a preference for a couple of formats that we found to be extremely powerful. One is a comic strip that explains what the customer journey looks like. And that journey isn’t just, Hey, from the time that you log into the product to the time that you log out, this is what it’s going to look like. It’s very holistic. And it thinks about what was the triggering moment where a customer or a prospect said, man, my existing product solution, isn’t working well to help me achieve this outcome. [18:26] Then it moves into discovery, which is like, how do they find out about a product. Evaluation, what’s going on in their head as they learn more about your product? What are the check boxes they’re trying to check? What are the criteria that they’re using to decide whether your product is better than something else that they’ve used or that they’re considering using? It moves into a trial phase, which isn’t just like a free trial, like in a consumer app or something that you download from the app store, but also like, Hey, I’m going to kick the tires a little bit. [18:50] We’re going to do proof of concept and run it for a few months or a few quarters, test it out with a few employees in the B2B context, then moving into kind of ongoing engagement or retention, just like normal product usage once you’ve proven that it is valuable. And that the journey should also identify like, sort of, how do you retain customers at a moment where they have a choice to walk away from the product in the B2B context, this would be the renewal conversation, right? Hey, it’s been a year or two years, do you want to like re-up with us. [19:17] In the consumer space, it might also just be like, Hey, you stop paying for our product or you’re thinking about canceling. Do you want to stay with us and why, and thinking about what is the experience that a customer is going to have at those moments. And so that’s the sort spirit behind the vision led framework and why we choose to express that vision in a way that’s very customer centric. The other benefit is that it aligns, it sort of emphasizes the customer centricity. So as you take the vision around, start talking to sales and marketing and engineering, you’re putting the customer at the center of all the discussions and it sort of emphasizes that customer centricity. Victor [19:52]: That’s a very valid point because how should I as a product manager or also the founder, as the person in charge, what should I do with other feedback? You mentioned marketing, you mentioned sales. If I’m not the founder, but I’m the product manager. What should I do with the founders direct input? Or if I’m the founder, how should I even think about my own ideas for the product? Rajesh [20:19] Yeah. Well, in the framework, as you might imagine, we get a little bit into the process side of things, and we talk about evaluating the ideas that make up your vision and how do you make sure that the direction you’re headed is actually the right direction. So I think, like I said, I think qualitative research is sort of a technique that isn’t used as often. But that we recommend, which is, how do you go talk to your customers, your prospects, your advisory board, whatever it might be to make sure that the direction you’re headed is in fact exciting. [20:48] And as a founder, I think you have to get alignment. We were talking about the B2B, B2C business model and how you’ve got the buyer and then you’ve got the consumer and it’s like, it is a lot of stakeholders and you have to prioritize your time and, and your energy against each of those personas. Same thing as a founder, you’ve got your marketing team, the sales team, their livelihood depends on building the right product that they can actually sell in the market that’s going to win and that’s going to help them pay their bills every month. Because their paycheck is dependent on it. [21:15] Similarly for marketing. How do you make sure that they know how to position and talk about the product in a way that’s meaningful to the actual market or the buyers out there? So I think, what I’ll say about the framework is we have five big components of the framework, each one, there’s a recommended artifact that produces like, Hey, there’s something tangible that the team can react to. And actually the specific artifact doesn’t matter that much. [21:39] The point that it’s down on paper is what’s most important because if you can’t get that alignment internally and sometimes it happens like verbally. You might just think about how, oh, and we’ve actually met a lot of founders where they’re like, no, everyone at my company knows what the vision is. We talk about it, every single, all-hands meeting. But talking about it and having it written down are two very different things. The intent of the vision should be that someone could reference it periodically and say, oh, I’m about to make a decision. Is this decision going to take us closer to that vision or further are away? [22:09] And if it’s just something that’s verbally communicated, what we found is, even at a small company with 15 people, you might end up with 15 different versions of what that vision means to them, if it’s only verbally communicated. And so the intent behind the framework is to drive alignment on the vision so that you can make sure that everyone’s rowing in the same direction and that everyone understands where we’re headed and why it’s the right direction, why it’s good for the customers, why it’s good for the business and all those things. [22:33] And so I think there is some of that feedback that needs to get there. And I think at the product manager level, it’s a little bit harder because you may not be able to influence that direction as much, but I think you can apply some of these concepts, even at the feature level, which is like, Hey, this is what we think this feature is going to look like and by the time we’re done in a year or so, let me explain to you why it should be exciting and what success looks like, what the metrics are going to be that we’ll use to measure the value of this product or this feature. [22:59] And let me explain, sort of work backwards from an end state and talk about how we’re going to slice this into sprint size chunks and start building this feature and hopefully releasing it and putting it into the hands of users and getting feedback along the way to verify or sort of evaluate whether we’re headed down the right path. Victor [23:15] That’s very valuable. That makes perfect sense. How does that even differ potentially before or after product market fit? Is there a big difference? Do I have more or less certainty on different things or do I even apply different techniques to get there? I guess the most important thing when a before product market fit, is obviously to get to product market fit. And how does that change after? Rajesh [23:38]: It definitely changes how you think about prioritization in particular. And like you said before you found it, there’s nothing else that matters. In fact, what we typically talk about with our vision led framework is like, it kind of is irrelevant until you found product market fit. Nobody cares about your vision. What they care about is does your product solve a problem for me today, right now? And that’s how you find that product market fit. And most of those first few, whatever months or quarters or years for early product, a new product is spent iterate on feedback from different customers. [24:07] And you may cast a wide net, I’d say this is a pretty common technique. And it’s probably a reasonable one. Hey, I don’t know, maybe there’s a handful of different verticals or sort of markets we could try to sell this product into. Maybe we should try a bunch of them simultaneously and figure out, I call it the product path of least resistance as an electrical engineer. Where are we seeing the best traction, where people are interested in what we’re doing, they’re using it, they’re willing to pay. And like maybe there are some differences in how different markets where buyer personas think about our product. [24:35] And I want to find out where that is, and I might have some hypotheses, but I need to, I’m constantly learning as we iterate towards product market fit. And once you find some of that as early adopters, then you might spend a lot of time iterating to get their feedback. And hopefully what you’re doing during that time is also saying, well, what about that sort of early majority or the next wave of people who might want to buy inside of this market? They don’t look exactly like these early adopters who might be much more willing to try something out or be willing to put up with some bugs and some like weird usability issues as a alpha tester almost. [25:06] But could I sell this product into the rest of the market? And if so, what changes might I need to make and be thinking about? Is this actually scalable? Have we found a product market fit just with these early adopters or is there a broader market and audience beyond them that would actually buy this product? And I think this is an interesting thing, as you might imagine. We talk about product market fit a lot with our clients. We actually do these monthly workshops where we pull all our clients together and we talk about different topics. Product market fit, as you might imagine, is an annual topic, comes up for this, coming up for the last three or four years. [25:36] And I think maybe a month or two ago, we did the sort of like 2021 version of this. And my key takeaway was that you kind of have to find product-market fit multiple times because you might find that fit with the early adopters, but as you try to take that to that next wave of people inside of the market, they might have different evaluation criteria or price sensitivities or they may not care about certain features that the early adopters did. And so it’s kind of this never-ending cycle, but all of it is about finding scalability, which is identifying the things that matter to certain groups of people and making sure the product is just better than everything else out there that they’ve seen. And that you might have to go through this many times and the prioritization techniques may vary depending on where you are in that sort of life cycle. Victor [26:17] That’s very smart, actually. So if I have my early adopters who also oftentimes maybe probably know me, know myself, or know a lot of background or are in a community that, depends how you reach your early adopters. But they probably may find that quicker than with totally different customers who’ve never heard of you where you have bigger switching costs. It’s probably one of these hypotheses I’d have here. Rajesh [26:46]: Yeah 100%. And like I said, look, this is really hard to do, but ideally while you’re building for those early adopters and trying to figure out what their feedback is that you’re also verifying or evaluating whether that next wave of customers would actually find value in the exact same product today, or do you need to make some changes to it in order for it to be valuable or meaningful for them? Obviously all of this is in the [27:09 inaudible] of scalability, which is ideally that next wave of target audience or adopters would say, yes, that product that you already have today is exactly the thing that I would want to buy too. [27:18] And then now you’re really circling that product market fit. And you can sort of like, I’m able to create that scalable hockey stick type growth, because the same product can be used to create value for them. And therefore they’re willing to buy and pay for it. Victor [27:31]: Perfect. Perfect. And now obviously most people listening have, I guess everybody listening, I’d assume, I’d hope is using some sort of project manage software, [27:44 inaudible] Jira, Trello, something like that. You can prioritize within Jira and Trello. Jira as a roadmap-ish kind of view where it can drag and drop things around. That’s not really so helpful for the prioritization techniques where we’re talking about here it’s quite limited. Do you recommend any product management software out there specifically, or what do you use? Rajesh [28:11] So the quick answer is I personally tend to come back to spreadsheets and decks. And what I find with some of my clients is that they’re in similar boats and I think there’s been some great advance is in product management tools and sort of like products in the last few years. Companies like Product board and Atlassian and Notion and things like that are coming up with products, Aitable, even. That can be used by product teams to help manage their work. But I think that the prioritization side, I talk to my clients a lot about the art and the science of product management. And I think that there’s, I see a lot of these sort of the data driven product camp saying, well, everything should be sort of quantifiable. [29:00] And I need to be able to have this scorecard that sort of has different weights and it spits out an answer, but it’s like, you would never just take the answer that the spreadsheet spits out and say, okay, well, the spreadsheet said we should do, these are the top three things we should do. You always layer that on with a little bit of a judgment call of like, do I agree with these things? Are they naturally what I would’ve expected? And if so, is there anything insightful about the data that sort of help surprise me, impact, reach, revenue implications, whatever it might be. [29:29] And then there’s a qualitative side, which is like, do I agree, based on what I know in my gut, do I think that this is actually the highest priority thing, the most valuable thing that we should have, design engineering, working on right now. Is this solving a customer problem that’s burning and urgent? Or is it just like a modest, like tweak? And so I think that there’s sort of this balancing act. So I sort of go back and forth. I think that some tools are good at this. And I think if nothing else, they create a way to organize information and ideas. And that’s a good thing. [30:01] What I’ve seen some teams struggle with though is getting adoption across even, one across the product team that every product manager agrees that this is actually better than their spreadsheets or their Google docs or whatever it is that they’re using. And then two, a lot of the value comes when your stakeholders also look at the tool. And I think one of the challenges I’ve seen with, as an example with Jira is very few executives have access to Jira or know how to use it. And so you end up having to create this deck or a slide outside of Jira that explains the roadmap. [30:33] And now you have two things that are probably not synced up. And then there’s a question of like, where do I go when I want to find the latest roadmap? Really it’s probably in Jira, but I don’t know how to get into Jira or I don’t remember what that Jira exists and stuff. It’s not a knock against Jira. I think a lot of product tools like this have this challenge, which is why I think a lot of teams fall back on the tools that the entire company has access to. [30:54] And so I think collaboration is kind of like one of these challenges for product management tools. And I know that a lot of collaborative features have been built to share snippets of roadmaps are in [31:04 inaudible] And then the likes probably have a lot of those feature sets. But yeah, that’s what I use. And so with our framework, we’ve created a bunch of templates in Google sheets that help you create the balancing act between the innovation and iteration and operations. And there are some score cards and then there’s a handful of prompting questions we have after the scorecard’s, like put out an answer. [31:26] And we typically do like the sort of like now, soon, later kind of template for products. And I know we’ll probably talk about outcome oriented roadmaps too, but I think that it’s a powerful trend we’re seeing. And I think if you can combine those two, that’s powerful. Victor [31:41] Yep. And you’re right about that. The smallest common denominator within a bigger organization is usually Word, Excel sent via email, but yeah, the things we have to live with. Yeah, you just mentioned the outcome oriented product roadmap. Why don’t you say a bit about that? Rajesh [31:58]: Yeah, sure. I would say that this is like, obviously kind of thinking about product. There’s a lot of trends and I would say this in my mind, this outcome oriented product roadmap is like cutting edge. Very few of the teams we’re working with have started adopting this. The big transition is we talk about outcome oriented roadmaps as opposed to output oriented roadmaps. And I think the output oriented roadmap is focused on feature delivery and timelines. And it’s like, a lot of teams still use what I call the sort of like [32:34 Gantt] chart style roadmap, which kind of looks like a project plan. [32:37] It’s got like some timeline across the top. It’s got some detailed tasks of things that are going to be built and maybe there’s a little star next to different feature releases or product releases. And those are of course necessary and relevant and needed in order to communicate what is changing about the product and when However the format itself. And I think the visualization creates such an emphasis on the timeline that a lot of product development teams get caught up in this sort of like world where the success of their job is basically dependent on whether they stuck to the timeline that they created. [33:08] Well, in reality, that project plan that looks like a project plan was probably never created the way that a home construction company might create a project plan for building a house, where they know exactly what needs to happen because the first house is pretty similar to building the second house. You’ve got, the structure, electrical, plumbing, walls, roofs, windows, all that stuff. It’s like, it’s pretty common, one house is pretty close to another. That’s not the case necessarily with software, every feature could be different and requires different infrastructure or the technology side. [33:41] You might need to like revamp the architecture, all those things. And so those estimates are often just that, they were estimates and they’re often done in an hour or two or three hours just putting t-shirt sizes on there. But then they’re presented as if they were like very concrete timelines. And so I think what this has created is a world where product management in particular, one of the implications of this is I think trust has eroded very quickly at organizations between product and their stakeholders, when every quarter they have to stand up there and say, well, we’re delayed here. We’re delayed here. We’re delayed here. [34:15] And it was because really the estimates were off and we learned something new. And in some ways you would say that’s a good of thing? Isn’t the point of agile product development to constantly be learning and iterating and sort of adjusting. And so there’s a trend now to move to these outcome oriented roadmaps. And I’d say that my interpretation and how we talk to our clients about using this is that the first thing you need to do is identify what outcomes and hopefully they are quantifiable outcomes, is the product intended to move? [34:45] And of course there’s the sort of financial ones, so every product probably has something with a dollar sign in front of it. This is some KPI related to revenue or cost savings or whatever that’s important. And I think it’s really good to have that as a starting point, you get the business layer on top of the sort of product layer, which is like, how does the software development work actually impact the business? Is it helping grow top-line revenue by adding new clients? Is it expanding with existing clients? Are we trying to reduce churn? [35:11] And like, even those three things in and of itself can be the outcomes you’re trying to drive towards. But I think another variation of this might be thinking about what are the outcomes that customer is trying to achieve and how does our roadmap relate to those? Because one of the things we talk about in our framework is identifying key outcomes for a customer before you identify the key outcome for your business. Every company has some business level KPIs financial ones. But creating value for your customers is actually the leading indicator of business value. [35:41] As long as you’ve got a reasonable pricing and packaging plan, you should be able to capture some of the value you’re creating for customers and sort of realize it in the form of revenue and profits for your business. And so one of the things we push clients on is thinking about how might you orient a roadmap that sort of talks about what outcomes your customer is trying to achieve, whether your B2B product that actually helps them grow top-line revenue. And so is there a world where you actually measure whether they’re achieving growth or not? [36:09] And maybe there’s a feature set that you build to sort of help track or increase their revenue. Maybe you exist to help them reach regulatory compliance and there’s some way to track whether they’re compliant or what percentage of the time they’re compliant, or how much work they have left to do to be more compliant? Maybe you save them money. And so you need to track like employee efficiency and those types of things. On the consumer facing side, it’s a little bit more straightforward because you can probably ask directly for what value or what outcome they’re trying to seek and quantify it. [36:37] And the general idea is once you’ve aligned on those outcomes, then imagine for a second, a world where the swim lanes on the roadmap become those outcomes. And the point is, if the columns in a roadmap are typically timelines. And I think rather than having sort of like very specific dates, I think now soon or later gets at the point of sort of the intent of a roadmap, which is to communicate priorities relative to each other. Even if the specific dates aren’t clear. Now you could have sort of this swim lanes that say, here’s the outcome that we’re trying to drive. [37:07] Here’s what we’re working on now that we feel is going to move the needle the fastest on this outcome. And it creates a real forcing function for the product team to rationalize why the work they’re doing is actually going to move the needle on some metric that’s important to the business or customers or ideally both. And this is sort of the trend towards outcome oriented roadmaps that we’re seeing. And again, like I said, I think this is still pretty early days in terms of adoption for product teams taking this on, but that’s kind of the theory behind them. Victor [37:34]: Awesome, awesome. This is really helpful. And so now if anybody listening wants to have this discussion about the more cutting edge approaches and product management with you directly, what do you guys do at Prodify, exactly to help software companies and maybe who’s the right fit here to talk to you? Rajesh [37:56]: Yeah, for sure. So there’s kind of three personas that we typically serve. One is startup founders and entrepreneurs. And I think some of the things that we’re typically helping with is, there’s a product strategy side, which is like what help me make some decisions on where to take the product? What market should we go after? We found some initial traction here, we could go, like we talked about setting a few different directions. How to do we decide which one is right? And how do we prioritize what markets to go after next? [38:24] And I think this is where some of the vision led framework could be helpful and sort of synthesizing the directions and the personas and all those things. And so that’s one aspect. There’s a product team development side of things. And so one of the major things is should I make my first product hire? And that’s actually one of the most sort of like common ways where we’re helping on the recruiting side, is helping them decide, do I need a product executive? [38:45] Typically we recommend having more of a senior PM level person who’s going to join to help execute on the roadmap, knowing that founders are probably not yet willing to kind of like give up the product vision strategy and rightfully so because they’re the storytellers and sort of the arbiter of all of that with investors. And they’re probably still in the sales cycle and all those things. So that’s another big one. Sometimes they come to us and we’re looking for a little bit more structure on the sort of like product development side of things. The way I think about product operations, it’s kind of like, Hey, how do ideas turn into software releases? [39:14] And it get into prioritization and tools and process and [39:17inaudible] structure and a handful of those things. So those are another area. Another group of folks that we help are product executives. And I’d say a classic one is actually people who are stepping into the VP product role for the first time at a startup. So series A, series B is usually where this starts happening and they start hiring VPs. And there we do kind of more executive coaching. [39:38] So we kind of help service a sounding board for major product decisions or thinking about how to structure the team, maybe helping a little bit with hiring, looking at resumes and thinking about the profile of product person you might need. Maybe looking at the strengths and weaknesses and sort of like overall diversity of team in terms of thought process and sort of natural personalities and making sure that there’s some good balance across the team. [40:01] And then a third group that we serve is product team leads. I kind of think a director and group product manager level, there it’s a little bit kind of still more on the coaching side of things and helping them become product leaders. Helping them mentor their product managers. Think about the execution of how product is done at their organization. So touches probably a little bit more tactically into the product operations side of things. [40:23] But yeah, those are kind of the three big things that we help with. And so it’s like, product, vision, strategy, product team development, coaching, hiring and product operations, kind of like how do ideas turn into software releases. Victor [40:34]: All across the product board. Awesome. Do you have any resource, anything more about prioritization, vision setting, road mapping that I can said people to? Rajesh [40:43]: Yeah, for sure. So on our site Prodify.group, we have a whole section dedicated to resources. One of the things we offer to our clients is what we call the Prodify library. It’s basically a Google drive folder full of worksheets, templates, real world examples of product artifacts. And we have a lot of step by step guides there to help people make some of these product decisions or get down their product vision, or learn how to do customer discovery interviews and those types of things. [41:08] And so we’ve exposed a handful of those through our website. There’s a resources tab at the top of the site. You can find access to the library. And then I think I might have sent you a link to an article that I found helpful on the prioritization techniques. It’s probably a few years old, but every time I look back on it, I’m like, well, I think most of these still apply it. It’s like, it used to be called folding burritos. I think they’ve rebranded to, to Career.pm. [41:30] And so basically, it’s kind of a cool visual, it’s the periodic table of product prioritization techniques. And I think they’ve kind of oriented around sort of how qualitative versus quantitative it is and how sort of internally focused versus externally focused it is. And I think they have 20 different prioritization techniques. So it’s kind of a good article to get, the kind of like high level 50,000 foot view of different prioritization techniques that exist out there. [41:54] Like I said, we picked some very specific ones as a part of the vision led framework, which you can see about on our site, but this article and visual might be helpful just to get kind of a high-level overview. Victor [42:03]: Yeah. They’ve almost prioritized prioritization techniques. No, it’s very complete. It’s a great article. We’re going to link it in the show notes Rajesh, last one. So your site is Prodify.group and where can people find you personally? Rajesh [42:21] Yeah, me personally. Linkedin is probably the best place. I’m active there. So yeah, just search Rajesh and Prodify and you should be able to find me on LinkedIn. Victor [42:29]: Perfect. Thank you so much for coming on the show. It’s been super helpful. Rajesh [42:35]: Yeah. Thank you so much for having me, Victor. I love talking about prioritization, because it sit at the heart of product management. Victor [42:42]: Awesome. Thank you.