Loading summary
Transcript43 lines
- [00:00]
A
Welcome back to Product Therapy. Today I'm excited to be joined by my good friend and SVPG partner, Leah Hickman to talk about a topic that sparks a lot of confusion and even more opinions inside product teams. The topic of roadmaps. Now, whether you're working with executives that are asking for a quarterly roadmap on a spreadsheet, or trying to convince stakeholders that your timeline of features or their request is not a strategy, the way we use roadmaps really indicates or says a lot about how we work. And more often than not, roadmaps become a battleground of alignment, trust, and product thinking. In this episode, we spend time trying to understand how we coach leaders through the most common roadmap dysfunctions, how you create roadmaps that empower teams and what it looks like to shift from Fisher list to outcome features, directions. Leah, such a pleasure to have you back. Welcome to Product Therapy. I know this is a tough topic, but an important one. You know, in our industry, there is this love, hate relationship with roadmaps. Maybe we can start today by giving you a common definitions you've seen of what their roadmap is and why people love them or hate them.
- [01:14]
B
I think that people love roadmaps because it gives them a view into the work that's being done and when it's going to be delivered. And I think that that particular definition is typically from leadership and it's typically from the internal stakeholders of an organization. So they want to understand what's the team working on and when is it going to be done, Mostly because they have some sort of interest in those things.
- [01:38]
A
I think roadmaps are demanded by a lot of executives to try to answer two critical questions. You know, the first question is, you know, are we working on the most important thing? And the second question is, well, when are we going to get that important thing or those important things? And for many people, they are searching in their head. Communication tool, clarity tool, alignment tool. Roadmap by the name means I know where we are going tool. But why do we hate it? What is the problem with it then? I mean, it sounds philosophically sound. We want to know what's important. We want to know when we're going to get important things because we need to coordinate our efforts or align our organization. Why do people hate them so much?
- [02:21]
B
Well, I think people hate them because it assumes that there's some commitment to deliver something that we're unsure of by a particular date. And usually when we're asked for roadmaps, it's done because it needs to be presented at some particular timeframe. And we haven't been able to do the right level of diligence or testing to be confident that we can actually deliver the thing that we're being asked to deliver.
- [02:48]
A
Oh boy. I mean, you, you're calling out a lot of things here. You know, people always ask me, you know, first of all, I gotta be clear. I am not an anti roadmap person. But people are very quick to kind of see my frustration with roadmaps. And I say, well, I don't think they are philosophically bad. I do think most traditional roadmaps, what by when are wasteful. They are not bad. But he's like, why? I said, well, because most of the things on your roadmap will fail. They will not help you get your desired outcome. They will not actually do what you think they are going to do. You know. And I say, if a roadmap were just a list of ideas, it is harmless. Like these are some ideas we have. But the second you put a date beside an idea, it turns from an idea into like a commitment, a promise, you know, an expectation. And I have always said I have seen even the best intended roadmaps destroy a company because one stakeholder had a missed expectation of failed commitment. Like just eroding trust you put on your roadmap, I will get this new future by Monday. And I didn't, you know, you are not worthy of trust. And I say, well, we are locking ourselves into things that should change, you know. So, you know, pointedly, if I was asked what my problems are with roadmaps, I will say, look, I want most of the things on roadmaps. Traditional roadmaps fail. Two, you know, they are based on assumptions like you talked about. Like there's no did we do discovery before we committed to them. 3. I always say I think it's because of where most of the roadmaps come from. You know, it's kind of like if you were building a house or building a pool and your spouse said to you, this will be done on Monday. You're like, how do you know? But if the builders of the pool told you this pool will be done on Monday, you're like, okay, they are the ones building the pool. So often you see a roadmap coming from like some executive or some leader or some marketing group. And so you are calling out a couple of things there, which is most of the things fail on a roadmap. It's based on assumptions. You kind of know, discovery. It's not coming from the People actually building it's coming from like leaders or people disconnected from the work. And I also think for me, one of the things that irks me is that most value is assumed in it. The second it is done, there's like, it must be a good thing. And so nobody cares to question is this the best thing? Is this the right thing we should be doing? Now, I know you've seen varying flavors of roadmaps, so maybe I should start with anchoring on what is a good roadmap in your ideal sense. If you really wanted to do a roadmap, what should, what is it supposed to be? What does it look like? And maybe paint a picture of the possibility of a good version of a roadmap, if it exists.
- [05:31]
B
Yeah. I mean, no surprise, I'm a big fan of outcome based roadmaps. The reason why I'm a big fan of outcome based roadmaps is because an outcome based roadmap typically ladders up to the business results that we're trying to achieve. So I'm a big fan of having clarity around the business results and making sure that the teams who are responsible for building anything understand the impact that they're going to have on the business. A good outcome based roadmap is based on the outcomes or objectives that the team is working on, how we're going to quantify success. A lot of times those are the key results and then they might have a hypothesis of the capabilities in the product that are going to achieve those results, but it's just a hypothesis. So aligning on the objectives, aligning on the measurements of success, I'm 100% behind. If our roadmaps could be focused on that, and then we can empower the teams to actually do the work necessary to come up with the solution that is valuable, usable, feasible and viable, I'm 100% on board. My issue with roadmaps in general is that's typically not how they're working. In an organization, the team, you know, whether it's annual planning or quarterly planning, is asked to let us know what you're delivering within a particular timeframe. And who's to say that we're building the right thing? You know, none of that validation is done.
- [06:57]
A
An ample based roadmap you're kind of describing is centered around maybe customer problems or business goals, not futures. What does it look like? Is it like, I'm just going to write this quarter or today or next week, I'm working on increasing revenue? Like what? What does it look like practically, let's.
- [07:15]
B
Say that we have a business goal to increase revenue by x percent for the year. An outcome based roadmap might have something to do with we need to increase conversion by a certain amount in maybe from a freemium level of service to a premium level of service in Q1. And the way that we're, you know, going to measure that is the number of free users that convert over any particular timeframe. Now underneath that measurement of success, we might have a hypothesis that certain capabilities are going to drive conversion, right? So we might know those predictive indicators of conversion and we might say, you know, feature foo is going to actually help us drive conversion. Or we think it is. So we'll call that a feature candidate. But we're going to test it. We're going to test that and many other ideas before we actually commit to implementing a feature that's going to increase conversion which is ultimately going to have an impact on revenue. And that's, that kind of outcome based approach is much more productive. One, because I want everyone on the team to understand how they're having a direct impact on the business and for the customer. And two, it's something that's actually tangible. Delivering a feature is a means to an end. Like who cares how many features we deliver if they don't yield any kind of positive result for the customer or positive result for the business they have to tie together. Otherwise it's just who cares, who cares about the roadmap? I mean, I can commit to delivering as many features as you want within a particular timeframe, but if they're not going to have an impact, I really.
- [08:48]
A
Love the name you called out, the future. You just didn't say future. Said a future candidate. You know, because you're anchoring, you know, something is like the moment your roadmap becomes a promise rather than a hypothesis, you've kind of lost room to learn. And you know, I'm visualizing as you're describing, your example of what that kind of outcome based roadmap looks like. You're like, you know, maybe it's the team or the problems you're tackling. You know, I want to improve onboarding. Maybe it is a measure of success. I want to, you know, reduce drop off by 30% or something like that. Maybe it's a hypothesis, kind of like, you know, I'm going to simplify the form. I'm, you know, form completion in some ways or, and then a future candidate for what you want to do with that or even like in some ways an assumption or goal of what you want to learn in order to get to that outcome. I really love that idea of problem, measure of success, future candidate or ideas you might try because it feels tangible. Now is this in, you know, this is saying a lot of the what and the why, but is there anything in this outcome based roadmap that is saying the when?
- [09:54]
B
Yeah, but I would not be any more structured. So. And again, this is true for me when I was in operational roles and product and this might be controversial, but I would never commit to a date. I commit to a timeframe, but I would not commit to a date. And when you commit to a date, you're just setting the team up for failure. Right. When you commit to a specific date, so much can happen in product right around technical feasibility. So much can happen when you're testing an idea with a customer where you might get an insight that's going to lead you to develop something a little bit differently. And when you commit to a specific date, does that mean that the date is the most important thing or building the right product is the most important thing? And I would argue that it's more important to build the right thing to drive the value for the customer and the business than to hit that specific date. So giving a time frame gives me and the product team a little bit more flexibility to make sure that I'm confident that I can ultimately achieve the results that we need to achieve.
- [10:56]
A
What is a healthy time frame? Leah, are we talking.
- [10:58]
B
I'll even make it as specific as late Q2. Right. Our second half of Q2. But any more than that, and you know, and I've gotten a lot of pushback from leaders that I've worked with as well as stakeholders. Like I need a date. I'm like, why do you need a date? Why do you need a date? Like, help me understand why that date is so critically important. And if it's a go to market issue, usually we can, we can mitigate that. We can work through it. We can, you know, the only time where it's a specific date that I've encountered is really important, is if we're announcing on a particular date and we want to have that product or that capability in market. Well, okay, let's figure out how we can mitigate that. Maybe we can announce the value proposition and the benefits that that capability is going to be providing, but maybe we don't necessarily have to deliver it on that day. So there's ways to move around that. Again, I think it's more valuable to deliver the right product than to deliver it by A particular date, you know.
- [11:58]
A
You'Re playing out on the pushback and even in some ways, kind of what executives do. You know, let's be honest. Lots of roadmap pressure for teams comes from above. You know, most teams don't wake up to, I'm going to work on a roadmap. There's somebody saying, when am I going to get this? Or what am I going to get? And you've just kind of given us like, I'm going to push back on a date. But how. How would I coach an executive or a GM or a business leader who wants timelines from me and deliverables, you know, versus, you know, these are the things I'm going to learn or the problems I'm going to solve? What. What do I do?
- [12:38]
B
I mean, I think that a lot of that stems from a lack of trust, right? A lack of trust. And I always, when I'm working with executive teams, you know, a roadmap is a perceived tool of control, right? Like, it gives me insight and control over what the teams and all of these valuable resources are working on and when I can get the return of all of the things that they're building. The problem is that it's false control. In fact, I've worked with teams that have been effective at delivering everything on the roadmap and had zero impact on the business. This particular business actually went out of business because even though the product organization delivered on everything that they said they were going to, none of those capabilities had an impact on the business. So the question is, was that product team successful? No, the product team wasn't successful because the company failed. Right. So in order to tie those things together, I usually coach executives on change. What you control. Don't worry about controlling the features that are being developed on the roadmap. Make sure that you control the strategic context. Make sure that you have a clear view on what you need to achieve from a business perspective. Make sure that you align on what the product vision is, what the product strategy is, what the priorities for the business are. Align on that. Hold the teams accountable for that definition of success that they come up with, but give the teams the capability to build the right product to deliver on those results. So that's a very different. And so for some executives, that's. That's a bigger gap to leap over. But for others, like, it clicks for them a little bit because they're like, okay, I'm not relinquishing all my control. I'm actually changing what I can control.
- [14:27]
A
You spend this last Time kind of defining in some sense what a good roadmap really supposed to be. You know, it's kind of, it's like it's not a list of futures or delivery dates. It's maybe it's a communication tool that connects strategy with execution. Maybe it's the key problems we're trying to solve. The desired outcomes we want, how we are sequencing work in order to kind of do it. You know, maybe it reflects what we want to learn, what we want to validate, what we want to deliver, not what we plan to build. You know, when I'm hearing you talk, I'm like most roadmaps in and by themselves are arrogant in nature. Somebody's feeling like I know the solution and we're gonna do this. And I think the opposite is this idea of discovery which we are kind of saying, we know the problem, we know the desired outcome. We are not so sure what the best solution is. I always kind of think they say to leaders, all the time it's, you know, many leaders want predictability, but they don't understand the relationship between predictability and innovation. I think is that Henrik Koberg quote of like a hundred percent predictability equals zero percent innovation. And I have to explain to leaders like what's more important to you? Getting your goal of growing revenue or hitting the date of releasing this feature. And if we want us to guarantee the date, you're definitely not going to guarantee the outcome. But you know, and that's a big mindset shift now. So when you described this ideal state of what a roadmap could be, an outcome based roadmap, what problems you want to solve, what learnings you want to have, what is this is not the reality for most companies and most teams. You know, what are the common roadmap traps or versions or dysfunctions that you see most companies have? What do you normally stumble upon?
- [16:17]
B
One pattern that I see and I'm going to call it an anti pattern just because we love that word anti pattern. I love it because it's a pattern that we don't want. See, one is a stakeholder driven roadmap, which is product team basically goes and asks all the stakeholders what they want and then they create a roadmap. They're basically just putting together a project plan to manage the work and the capacity for the team. The reason why I struggle with that anti pattern is because no one's validated anything, no one's tested. We're taking everything at face value. And usually that type of roadmap is going to lead to a lot of disappointment. It's going to lead to disappointment with the product team because they really don't have a say. They're just a feature team or a delivery team implementing something that a stakeholder says is important. So not very empowering from that perspective. And from a stakeholder perspective, usually we haven't done the right level of discovery or diligence to actually even commit. So we typically don't even meet the dates that we commit to. And that's frustrating from a stakeholder perspective. So it's kind of a lose lose scenario where stakeholders are disappointed, the product team's disappointed executives, you know, like it just creates a lot of unnecessary tension and churn in the organization. So that stakeholder roadmap I'm, I'm not a big fan of. Similarly with the stakeholder roadmap is almost the executive driven roadmap. You know, and this is, I worked at a startup once and every. It's almost like an executive slash competitor driven roadmap. Every time a competitor would come out with a new feature, the CEO would slack me and say when are we going to implement this particular feature? Product team had no control over the work being done because it was very much being driven, you know, by external factors. Again, no discovery work, constant disappointment. It was that same lose, lose scenario. So those would be the two top ones that I would call out and they're just not very effective tools if you believe the value is building the right product to drive the results for the customer and the company. Now if you don't care about customer results and you don't care about company results, maybe that's perfectly fine. And I'm being a little bit snarky on purpose. Most executive teams care a lot about company results and they want to actually make their customers successful. So I don't know why they would choose those roadmaps As a way of having confidence.
- [18:48]
A
Yeah, you know, you're describing. I used to have four common anti pattern roadmap types that I always see. You've called out the stakeholder driven roadmap, which is, you know, you just run around, collect requests from across the organization and you prioritize the nice list of things to work on that can be stakeholder of an executive driven. I've seen what I call the quarterly fill the bucket roadmap, you know, where it's just like our engineering capacity is a thousand story points, you know, like, you know, the roadmap is like a capacity planning tool, not like a problem solving tool. How much work can we accomplish this quarter, let's go find the tickets to match into the work. And obviously I think the most common one is this future factory roadmaps, which is just the list of outputs, no real connection to strategy or problems. You can test that by just asking people, why are you working on this? And you're like, because the boss said so.
- [19:42]
B
Because it's on the roadmap.
- [19:43]
A
It's on the roadmap. Like it's, there's a ticketing system, it's Injira, you know, my name is Injira. Work on this and you will see like fixed timeline roadmaps which happen beforehand. You know, it's kind of like we start with the promise of the date we are going to land and there's no discovery done. It's like an unrealistic expectation. Now let's, let's talk about the practice of it. First of all, who actually owns a roadmap? Whose job is it to create or shape the roadmap?
- [20:10]
B
I mean typically in any organization, and again, I have a bias, I hope it's an outcome based roadmap. It's typically the role of the product manager to drive and manage that roadmap.
- [20:23]
A
In an outcome based roadmap. I like that. But I don't think many people come up with their roadmaps. They kind of get the roadmaps handed to them in some ways from a company. And I actually coach people about what that does in terms of shaping what kind of team it is. If I give you the solution, you become a delivery team or a future team. If I give you the problem, I empower you. It's almost, you know, it's. The roadmap actually can become a significant driver for how a team operates.
- [20:59]
B
Absolutely. Yeah.
- [21:00]
A
It's a very interesting way to kind of see it. It's almost like, you know, the way you turn strategy into action is by giving it to a team. Many companies, I've seen so many companies, you talk with the executives, they know all the right problems, all the critical data, all the right insights. But then yet they give their teams the solutions to those problems than give their teams the problems to solve. And so I've seen roadmaps of futures and projects and I have seen roadmaps of problems to solve or outcomes of business goals to accomplish in an ideal world. To your point, it'll be great if the team has said we've done some discovery, we understand the problem, we know the outcomes, these are the things we're gonna go try or test or go deliver to do. It, but boy, that is so far from it, you know, is there and unlock. If I'm a company today and I have that traditional list of futures and projects, am I trapped? What do I do?
- [21:59]
B
No, I mean I, and this was probably three operational roles ago for me, so quite some time ago I also would get a lot of requests from stakeholders and sometimes it was even the engineers on the team who believed, hey, we want to build this capability, that capability, et cetera. And what we started working on was what we was a predecessor to an outcome based roadmap, which I called a transitional roadmap, which was okay, even if when I'm giving features to build, I'm still going to have that conversation and ask why, right? Like if we deliver this feature, why, what's the benefit that we think that we're going to get for the customer? What's the benefit that we think we're going to get? Even framing those features in the form of the problem to solve or the objective, it helps in a couple of different ways. And it's again, it's almost like a working backward methodology where you're, you're framing up what the problem is, you're articulating what the value proposition is, you're articulating how you're going to measure success. You're still listing out the features with the modifier of candidate on it, you're still listing out the feature candidates, but the conversation that you have when you're presenting the roadmap changes a little bit. So even though you're committing to some capabilities within a particular timeframe, you basically reframe it as this is the problem that we're going after, this is how we're going to measure success. We have a hypothesis that these features are going to help us achieve that definition of success, but we're not sure yet. We're going to do some testing to make sure that we're building the right thing to deliver on those results. And even when leadership was expecting a feature based roadmap, that transition to an outcome based roadmap and how it was presented changed the conversation. And so it is an effective tool to use as you're making that migration or that transformation, if you will, to being more outcome driven versus feature or delivery team. Now that takes some change management. It also takes someone who's willing to take the time to understand the problem, to solve and to understand the outcome that we're trying to achieve. But all of that can be done by asking the questions, right? Like why, why do we need to have this kind of capability, what problem is it going after? What's the value to the customer? Those are simple questions to ask that are going to give you the information to make that transition.
- [24:21]
A
You know, I coach teams on how to move from like a roadmap of futures to having problems to solve. It's almost like I make the argument to people, look, there's not a true need for product management if you're just delivering a future. You're doing project management. And so kind of what I coach them is I like you need to see the list of things as ideas. I always say like that's a great idea. And I always want to say in order to succeed doing it, you need to understand what problem you're going to solve and how success will be measured on this idea. So many times you've done things on a roadmap and like why are they not happy? I give them what they wanted is because you did not solve the underlying problem. It's like I gave you this idea because I went to revenue. Sure it sucked, but like I still want revenue, you know. And so I always tell teams, you gotta convert your roadmap to a set of problems to solve. At least you need to understand that. So go back and say, hey look, what problem are we trying to solve? How we measure success? I wanna ask a controversial question here, Leah. Can you have roadmaps and OKRs?
- [25:27]
B
I think that's where an outcome based roadmap basically is that hybrid right between a roadmap and your okrs. Your objective is your problem to solve. Your key results are basically your measurement of success and then underneath that you articulate the feature candidates.
- [25:46]
A
Many people ask me that question all the time. And I said of course if it's a communications who focus on outcomes, it aligns well. But if you just have a list of futures to build and then you tell me go increase revenue, it's like, but you told me to build this future on Monday. I will never go increase revenue because one is important and the other is urgent in some ways. So it's a very. I love. You know, truly you are describing this ideal sense of roadmaps are meaningful if they are aligned to the why and the impact.
- [26:18]
B
So it's not just the why, it's. I mean I haven't worked with a single Engineer in the 35 years that I've been building products that didn't care about the why, who didn't want to understand the impact that they were having, how the code that they were writing was actually going to have an impact for the business and the customer. And I think a lot of times we forget about that. Right. Engineers are super creative people. They want to understand how they're having an impact. They need to understand that context. A typical roadmap is not going to give that to them. An outcome based roadmap will start giving them that context, especially if it's there to support the overall business mission and objectives. The product vision and the product strategy can become a very effective tool. But it's a living, breathing tool, but one that I have used repeatedly with teams, with leaders that I've coached that it's game changing for organizations.
- [27:13]
A
I love that. I think a good roadmap aligns a team around purpose. And probably a bad roadmap just assigns them work to do. And you know, I think this magic, you kind of called it out when you said you know, what's valuable, feasible, usable or works for the business in some ways that even if a roadmap, the context and alignment is owned by the product manager, you, design is probably bringing insights into users, engineering is bringing feasibility, you know, leadership is bringing strategy. All of these things contribute.
- [27:44]
B
Yeah. So on that, Christian, I mean I would never say, I would never have any kind of roadmap, even an outcome based roadmap where I did not have alignment with my counterparts in engineering and my counterparts in design. Especially if you believe in the model where we have shared objectives and shared accountability around the outcomes, you need to have alignment. And one of the anti patterns that I see a lot in organizations is if you don't have strong product leadership, the team and the organization typically defaults to only measuring the thing that they know how to measure, which is output. And that's an easy thing. So that anti pattern I see in organizations where they're so focused on delivery and so focused on story points and so focused on capacity, all of that stuff is important, but it's a means to an end, right? If we're delivering the wrong thing efficiently, who cares? This is about making sure that we're delivering the right product effectively and efficiently and that's very different.
- [28:46]
A
Now can I have a good outcome based roadmap without the vision or strategy?
- [28:50]
B
You can, but it'll be a more tactical outcome based roadmap and it won't necessarily be tied to those big things that drive impact for the business. So the reason why I like having the outcome based roadmap tied to the product strategy is the product strategy is easiest way I think about product strategy is it's the prioritized list of problems to solve. Right. And that that should tie directly to an outcome based roadmap. And those prioritized lists of problems to solve have to ladder up to where we ultimately want to go, which is your product vision and the needs of the business. Right. So short term impact as well as long term vision in terms of where we want to go. We're balancing those two things in the product strategy and then we're articulating that in an outcome based roadmap. So you can have a high level outcome based roadmap and then you can have a more micro level outcome based roadmap at the team level.
- [29:48]
A
I don't want to finish this episode without going back to talking about dates because that's probably what people when they want predictability or they might be demanding a roadmap of when in some ways in our world we, you know, we send a product model. Like we're not opposed to dates. You know, this is the real world. But we call these things high integrity commitments. Maybe distinguish a high integrity commitment from a typical roadmap date. And why does it matter?
- [30:12]
B
I've actually had high integrity commitments on my outcome based roadmaps, but I call them out differently. I actually call them out as an H I C. The reason why I call them out separately is I want everyone to understand that it's a high integrity commitment and it's a tell. Right. Like sometimes there are things that we need to do from an infrastructure perspective or we need a certain capability. I want those high integrity commitments to be few and far between. Right. I don't want a whole roadmap of high integrity commitments. Because what is that? That's a feature based roadmap. I can blend those things. So if you have an organization that's working on a large initiative, having a high integrity commitment is reasonable. Right. Because sometimes we need teams to do something that falls outside of their regular scope. I think there's room for them on outcome based roadmaps.
- [31:00]
A
Yeah. You know, high integrity commitment. Like you say sometimes when dates are needed, whether it's a commitment to another team, like a platform or you described a release, annual quarterly session. And I always tell people, I'm like, hey, let me tell you one that we all know publicly. It's like what happened last September with the iPhone? You're like, iPhone 16 came out. I'm like, do you know what's going to happen this September? And they're like iPhone 17? I'm like, yeah, you have billions of people. I expecting that. But then I will ask Them what's going to be in the iPhone 17? And they're like, oh, we don't know. In some ways I'm like, you see, it's very interesting. The teams control what have they discovered and validated that it can deliver within that timeframe. In some ways, you know, a typical roadmap date, you know, when I say the prerequisites for a high integrity commitment is that one, there's some form of discovery that has been done, mostly feasibility, we know what we can build prior to the commitment. And two, it comes from the builders, you know, it doesn't come from like the leaders. So pretty much you're saying, this is what I can deliver. Surely a leader can say this is our date. But the commitment of what to be delivered by that date comes from the people actually building those things in some ways. And you've kind of talked about stakeholders at the Mambolia. We are in the real world, probably my last question is around the pressure of our environment. There's a trust and credibility thing of what have you done for me lately that many product teams struggle with? You know, kind of like they want to please their stakeholders, please their business, please, by showing something tangible. Talk about the politics of roadmaps of like making promises or commitments holding true to deliverables that I can use with a stakeholder and maybe the risk of, you know, not honoring those commitments or the benefits of nailing the date.
- [32:51]
B
Clearly there's a lot of trust and credibility to be gained and lost by meeting dates and not meeting dates or meeting commitments. I'm even going to just say meeting commitments or not meeting commitments. And you know, I do believe, especially as a product leader, as a product manager, if you're going to commit to something, you should have a high level of confidence that you're able to deliver on that commitment because you will lose a lot of credibility. It's just the reality in working with stakeholders who are looking for some level of commitment. What I found was one of the questions that I always ask a stakeholder or a product organization, especially as it relates to feature based roadmaps, is how many people have delivered items on their roadmap that have never been used by a single user. And usually the hands go up in the room across the board. And part of the problem is feature based roadmaps when we haven't validated anything that we're delivering. Yes, we might have met the date, but it didn't provide any kind of value again to the business or to the customer. So engaging with stakeholders, the Conversation has to be around. Would you rather me deliver something that has no value by that date, or would you rather have me deliver something that has value to your customers and helps you achieve your revenue targets? Because you allowed me to have some time to build the right thing, you know, that's a very productive conversation to have. And you, I'm sure, can imagine what the stakeholder will say back now. That comes when you've actually proven that out. So all you need to do is deliver one thing that is used appropriately and provides value. That's fairly easy to do. And as you build that credibility, it becomes easier and easier to have that tighter coupling between what we're trying to achieve for the business and what we're doing in product. And that's where that credibility is gained. You have to earn it though, right? It doesn't come for free. You have to. You have to earn that.
- [34:49]
A
I mean, you are giving some practical way to shift from stakeholders asking you for output to advocating for outcomes in some ways. And it's almost like they have to learn. I always joke with teams, like, you know, if you go to a stakeholder that says, do this, and you say, why? And they're like, it's going to help me make $1 million. And you tell them, well, I'm working on something that will make us $10 million. There's no stakeholder that is like, you must do my idea. They just don't know you're working on anything more valuable. And I tell them, if you are not working on something with evidence that is more valuable, you should listen to them like, it's probably a great idea, you know, and we spend so much time trying to say no, fighting what goes on our roadmap.
- [35:29]
B
And you should use the rule of improv. Yes and yes. And tell me more why you think that's a good idea. What problem is it trying to solve? Like that kind of engagement? It's not your job as a member of the product team to say no. That's not your job. Your job is to get insights, get as much input as you possibly can, do your diligence, do the right level of discovery work, but be open to those ideas.
- [35:53]
A
What a gift. Leah, what's one thing a team should start working or start doing with their roadmaps today? If you are providing advice on that.
- [36:00]
B
Yeah. I mean, if they have features on their roadmaps right now, ask the question why? And articulate, what problem are we trying to solve and how am I going to measure success? So even if you have a feature based roadmap, like go through it, try to identify that. If you have items in your backlog, I would ask yourself the question, what evidence do I have that it's valuable, usable, feasible and viable. That's going to give you a sense of, you know, are we asking the right questions? Is this going to have the impact that we want? Are we confident that this is going to do what we need it to do for our customers and our stakeholders?
- [36:32]
A
I tell teams, as a rule of thumb, never tell people what you're working on without telling them why you're doing it. And you've got to annotate your roadmaps with outcomes. You know, people always think like, well they do. They want a roadmap. I said, well, nobody has ever given you the templates you must use for a roadmap. It kind of comes from you. And I say, if they're demanding a roadmap, tell them, sure, this is what I'm working on, but add right beside it. Why? You know, I'm building the new funnel future to increase conversion. I am working on this to increase revenue and I think we have the control to shape or contribute to influencing our organizations to care as much on the outcomes. And if you don't get that answer, probably a good time to do what you just said. X Y understand the measure of success. What a phenomenal discussion. I know it's never a fun one to talk about roadmaps, but I'm so glad we got a chance to do it. Leah, as always, thank you for the gift of your insights and your knowledge. Great to have you again.
- [37:34]
B
Always fun spending time with you.
- [37:36]
A
Want to learn more? Until next time, Please check out svpg.com, sign up for our newsletter that Mary Kagan puts out. Join us for one of our workshops near you and get access to all of the articles and content we put out. And thank you to everyone for joining us. Until next time, have a good day. A quick Disclaimer While this podcast is named Product Therapy, it is not hosted by licensed therapists or mental health professionals and it is in no way a substitute for professional mental health services. We recognize the importance of mental well being and encourage anyone facing personal difficulties to seek support from qualified professionals. See www.findahelpline.com.