Should you talk about the impact when you change your roadmap? | Cliff Gilley

In episode 48 of "Talking Roadmaps," Justin Woods interviews Cliff Gilley, Vice-President Analyst at Gartner, about the importance of discussing the impact when making changes to product roadmaps. Cliff shares insights from his extensive experience in B2B software and product management, emphasizing the need for agile and customer-centered approaches. They delve into best practices for product teams to mature their practices and improve customer outcomes.

Cliff is a former product manager and current Vice-President Analyst with Gartner for Product Teams. He's spent his career largely in B2B software helping companies to migrate from on-premises solutions to SaaS, and pushing them to be more agile and customer-centered in their approaches. In his current work with Gartner, he helps product teams to mature their practices, advance the profession, and to evangelize for product-centered practices to improve customer outcomes and business success.

Have a watch and if you enjoy the video don’t forget to subscribe to the channel, like it and maybe sign up to our mailing list!

Here is an audio-only version if that’s your preferred medium - and you can access it through your favourite podcasting platform if you prefer (Apple, Spotify, Amazon).

In the next episode we are talking to Dan Olsen, he is a product management trainer, consultant, and speaker. So watch out for Season 1 - Episode 49!

• Transcript

  - Hello, and welcome to the "Talking Roadmaps Channel." My name's Justin Woods, I'm one of the co-hosts here, and today I'm joined by Cliff Gilley. Cliff, please introduce yourself.

  - Hi, everybody, I'm Cliff Gilley. I am a Vice President Analyst at Gartner, which might surprise some people that I'm actually here talking about roadmaps, but I work for the Gartner for Product Teams Group. So what we do primarily is to assist product management teams and organisations to do better and do more. Personally, before I joined Gartner five years ago, I was a product manager in the Greater Seattle area for about 20 years. Worked with a lot of different organisations, size, shapes, markets, you name it, I'm actually also a trained lawyer with a licence to practise. So there's a lot of stuff that brought me into product management, and hopefully I'll fill in some of that as we talk about roadmaps.

  - I love that, all roads come back to product management, right, I love it.

  - I tried to leave a couple times and I keep getting pulled back.

  - [Announcer] If you're enjoying the channel, subscribe, hit the bell icon, and give us a like.

  - So Cliff, I'm gonna get started and jump in and say from your perspective, what do you think is the purpose of a roadmap?

  - To me, that's actually a super interesting question. And it sounds so simple, but the reality is it's actually really, really complex. I think fundamentally, and people will say it's about documenting strategy, it's about communication, I think it's about collaboration. I think it's a tool that allows us to do all those things, to communicate, to collaborate, to document strategy. But the goal to me is to make sure that everyone is aligned, that everyone has a say, and as a roadmap changes, because it should be a living thing, it shouldn't be a set in stone thing, that's where the collaboration becomes key. This change has happened in the roadmap, how does that affect you, sales, marketing, support, dev? And then responding to that. I've talked with a lot of organisations and worked in some where it was much more strict or product owned the roadmap, and we'd make changes and we'd be like, okay, this has changed and that should never be the case. This has changed, now how does that affect you? And I think that builds that collaboration. Product still owns the roadmap, it's not that product is asking permission to change the roadmap, but we need to give others in the organisation the opportunity to respond. In one company I worked at many years ago, I built this regular review, every two weeks we'd talk about, right after the sprints were done, this is what happened, this is what changed. And when marketing came back and said, "Hey we can't do that, we have a demo at this conference, and now you're saying it's gonna be two weeks later or four weeks later." We were like, "Okay, well, what do you need?" What do you actually need? And we'll make sure you have something, right? And I think a lot of times in that communication, in that strategic place, we forget that the changes we make have downstream ripples. And that's the piece that makes people not trust product. If we make changes and we don't tell people about them, or if we make them kind of at a fiat level, like I'm gonna move this over here and that over there it really decreases the level of trust. And if you decrease trust in product, which is already kinda low in many companies, you wind up with that micromanagement level of the CEO coming in or the COO or the VP of marketing trying to make those changes themselves, right? Be open to that. And I think that's to me, the core of a product roadmap. Strategy is still important, communication is essential, knowing where you're going, all of those things are important, but to me, that collaboration piece is the part that I think is the most important and often missing in organisations.

  - Yeah, wow, I mean, so much to unpack there, but I think you're absolutely spot on. And the key bit is I'm hearing collaboration, communication, and alignment, but actually potentially the roadmap is a prompt for dialogue, and that's a really important piece.

  - Absolutely, I think all too often, because we're in that roadmap all the time, we view it as kind of the key artefact for product, right? And sometimes it is, sometimes it's not. I think the critical piece is that prompt, is understanding that it's not the most important thing for marketing or sales or support or the c-level or exec. We're the only ones that are in it day to day, I think dev is probably the second closest to it. They're not looking at it every day. and that whole idea of if I put it out there, then people will go look at it. I've worked with knowledge managers for probably 20 years or so. It just doesn't work, that pull model doesn't work. We have to have a push model and we have to realise that it's likely someone hasn't fully read everything that we're talking about. So let's go through that process, kind of the Amazon, everyone sits down and reads the note before they discuss like, let's do that and let's do it regularly. And yeah, the first time we did it, it was like an hour and a half meeting, it was pulling teeth, it was super painful. No one really knew what was going on, but we got it down to like a 15 to 20 minute meeting every two weeks, and that's great. And I did the same thing with sprint planning, we can talk about that at some point too. When you do the prep work, when you do the work that's required to get that narrow scope and everyone knows what they're there for, and everyone knows what's gonna happen, it shrinks down considerably. I mean, it's scary to think I'm gonna have a representative from sales, marketing, finance, support, implementation, and possibly our CEO sat in, it was a relatively small company. Those are six people that we don't want in a room together to try to disrupt what we're trying to do. And that was the first meeting, the first meeting was very disruptive. It was like, well, why'd you do this? And what's going on with that? And we went on all sorts of tangents and we kept pulling people back and saying, look, this isn't a discussion about making the decision, this is a discussion about the effects of that decision. If we have to change that decision, we can, but you've gotta come to us with a really compelling reason because we are working with the developers and the testers and the ops people, we know that realm, we know that very well. So this decision was made, if we need to backtrack it, maybe, but more importantly, like, what do you actually need? And that got so many great conversations as we went on to the point where even marketing stopped asking us for screenshots, right? We were like, okay, hey, you know what? We'll set up a test environment for you and you can do the screenshot. Well, we need them them closest to release. I'm like, no, you don't, you can do all of the documentation you want and then put a placeholder screenshot, or don't put a screenshot, right? And then at the end we'll keep telling you what's changed, and if anything, significant changes, da, da, da, dah, right? Then you've got what you need. And it was also a little bit of teaching them agile practises, because I'm a big agile guy. So it was really interesting to kind of approach it that way.

  - I think that's phenomenal, we should run our roadmap review meetings like an Amazon meeting, and why not, right? It shouldn't be that we present it, and that's a surprise, they should have digested firsthand, and then we can have a conversation on it.

  - And that's how we structured it. It was present what it was, so confirm what we talked about last time, present what it is, because it's changed since the sprint, or maybe it hasn't. And then call out, these are the changes, and then ask openly, like, how does this affect you? And sometimes it was like, it doesn't, okay, great. Everybody leave, five minutes, we're out. But often it was like, oh, well what about X? What about Y? And then sometimes the conversations went off on other tangents, like that marketing discussion, that wasn't about the roadmap, that was about them wanting more fidelity than we were capable of delivering right now.

  - Yeah, absolutely. So also in that conversation, I was picking out some things around the audiences of the roadmap, and you mentioned a plethora of that. I think even we should consider legal, from your background, legal can often be an important stakeholder of that. From your perspective, who owns the roadmap, who owns and maintains the roadmap?

  - So I think that I firmly believe that is product management's like most important job in an organisation. And I say that hesitantly, but confidently, I'll put it that way. Because discovery and validation is super important, going out and finding new problems to solve, and validating your solutions. But if you are not fundamentally aligned within the organisation, you can't do those things to the right level. And again, back to that trust thing, if your organisation doesn't trust you, then marketing is gonna argue with what your customer insights are, sales is gonna argue with what your customer insights are, support's gonna argue with what your, 'cause they all have their own lenses. So we need to build that trust and that collaborative approach, so that people understand that we really are the most neutral customer contact, right? We are not out there with any kind of, well, we shouldn't be, we shouldn't be out there without any kind of bias. We're that blue sky thinker of what are the problems that you have? I just need to hear them. Marketing is hearing, what problems do you have? But I wanna position it. Sales is hearing what problems do you have? Well, how can we solve those? Support is hearing nothing but complaints, right? All of those different other parts, other customer touchpoints, have inherent biases that we should be trying to adjust for, or, I don't wanna say nullify, but challenge, I think I went off on a tangent there.

  - And that's the beauty of these sessions, Cliff, it's like we go down the avenues, the paths untrodden. So I love where this is going.

  - It was who owns

  - Yeah, absolutely.

  - Yeah, that's what it was, it was who owns, it's product management. I mean, with input from all of those stakeholders. It's never product management in a silo, in a black box. And I've worked in places that when I came in, that's how it was, it was like, product decides the roadmap, but no one knows until it's decided. And that was a horrific experience because no one trusted any of our choices.

  - Yeah, a 100%. And I've been there as well, that's when you get the classic product management says no, or it's on the roadmap or kind of all of those other ways of kind of pushing back illegitimately from my perspective. One bit that you talked about there was kind of the problems we wanna be solving, and I want to go down into that a little bit more. Because I think that's the way that a lot of modern road mapping now needs to think about. It needs to get away from delivery and more about those problems that need to be solved. What's your perspective from kind of the roadmap and maybe its relation to visions, strategy, objectives, problems, there's a constellation of other things that exist around the roadmap, what are your views on those?

  - I think any roadmap that's not tied to strategy is pointless. And any strategy that's not tied to vision probably isn't very useful. And I say that knowing that, and we've done research around this at Gartner, that the alignment between business strategy and product strategy is not good. Like, I think, what was it, 60-ish percent, of our annual survey respondents said that it was poorly aligned, poorly documented, poorly communicated. Like every bad thing you can say about those two things was in that survey. That said, I also firmly believe that in the absence of a strategy, you have to have a strong roadmap and you kind of have to create your own strategy that that roadmap represents. Because the roadmap is a representation of I almost wanna say the execution of, but then we get into that whole is it a feature plan? Is it a release plan? It shouldn't be, right? It's the kind of representation of the steps we're going to take to realise the strategy. So we have to have that strategy first, otherwise we're just throwing things on and being like, oh, we're gonna do this and maybe that, and this is a problem we might wanna solve, and they wind up being completely disconnected.

  - Absolutely, just to feed you a couple of words, I mean, Saeed Khan, who's been on the show before, said it is the output from a strategy process. We've interviewed Janna Bastow from ProdPad, the inventor of the now, next, later roadmap, who often says the roadmap is a prototype of your strategy. So I think all of those things are things that we can really nod against, and I think it is summarising where you were going with that.

  - Yeah, definitely. I mean, and I love and respect both of those folks, they're great thought leaders. But yeah, I mean, and too many times, and Saeed you probably said this and I'm sure Janna did, it's actually a release plan. It's we're going to do this, then we're going to do that, then we're going to do this other thing. And I still remember having a conversation with the CEO many, many, many, probably over a decade ago, about trying to transform to agile. And I pulled out the roadmaps and I said, okay, here's three year long roadmaps that you've created, and note that the last thing is the same on all three of these. He's like, well, oh, that's interesting, like, why. He's like, oh, well, things changed. I'm like, yeah, there you go, you've got it, you're already planning in a somewhat agile way because you're not sticking to that plan just because it's a plan, you're changing. And that like major light bulb moment for him was like, oh, this isn't some weird, esoteric, philosophical thing, we've actually kind of been doing it. I was like, yeah, now let's just take that kind of in the moment decision making and make it actually part of the process and let's not plan a year out or two years out. I think they were actually like three year roadmaps, but whatever, they were insane. Let's not do that because we don't know and we know that we don't know. And that's where I struggle with people that are saying they're agile, but they have two year roadmaps, or they say they're agile, but they have a year roadmap with specific features called out throughout the year, right? We talked in our research about the cone of uncertainty and yeah, that first section of your roadmap, whether it's a now, next, later or a year, quarterly. That first, you should know exactly what you're doing and exactly when it's gonna get done. Absolutely, not gonna argue with that at all. If you can't do that, we have a whole tonne of other conversations to have. But as you get out further, the next quarter, you should probably don't, maybe you know roughly what feature you might be working on, but once you get past that, then it's thematic, it's epochs, it's goals, objectives, where do we want to be two years from now, right? Do we wanna focus on user experience? Do we wanna focus on speeds and feeds? Do we wanna focus on integrations? We don't need to know which integration because we can decide that as we get closer. But it's good to have an idea of, okay, yeah, we're gonna slot two quarters worth of work on user experience, which I always advocate for, but no one seems to do.

  - It's so important, Cliff, I love the fact that you talked about the cone of uncertainty there. and I think what we need to do better in the product management world is actually translating that uncertainty into our roadmap views. So the problem is, is when they see it in black and white or colours and bold shapes, and there's a definite block in the later column, or in Q3 next year. The problem is, is that doesn't really, we don't do ourselves any favours by conveying the level of certainty we have on whether we're gonna actually work on that. So I'd love to explore ways of being able to do that. Rich Mironov talked about kind of coloured gradients or different shapes even, maybe a cloud, something that's nebulous out the front there, but I think that ties really well into what you were talking about with the cone of certainty.

  - Yeah, and I think most of the, that's actually why I'm a big fan of the now, next, later roadmap, that's actually how I've functioned as a product manager. Whether I've represented that in reality to others or not, I may, I haven't, or priority lists, right? I won so many battles by just listing the top 10 things each of my teams was working on. And when someone would come to me, sales would be like, oh my God, we need this feature to seal this deal. And I'm like, okay, there's the list, there are five things on that list. Which of those five things is this more important than, and are you willing to advocate for it? If I say, oh, well Justin said we needed to do this, so therefore number five dropped off, are you willing to double down on that? And some I think 90% of the disruptions went away right there, probably 5% got escalated to the sales management, and then I pointed to the list and nothing happened. And then the other 5% actually were important things and we diverted resources to do them. I think there's been a lot of talk, I think Saeed's been talking about this, or was it Rich? One of the two. No, it's Steve Johnson, that's right. So many great people to learn from, but he's been talking a lot about that in B2B, right? In B2C, you've got a lot more flexibility to not do something. But in B2B, there are times when I don't know, a Walmart comes in and you're an e-commerce advertising company, you're not likely you're gonna wanna say no to Walmart all the way up the chain. So you're gonna have to do some of that work. And I think a lot of times, that's actually, there is a roadmap connection here, I'll get there, I promise you, Justin. That's the other part about this uncertainty piece that I think we fail at, is we don't account for maintenance and customer requests in our roadmaps. So when we paint that picture of here's all the feature work that we're going to do, that's taken both as a certainty statement, which has issues, but also as this is the 100% allocation. And I've been working with many clients to add that maintenance, ongoing maintenance, you don't have to call it what it is, just like those themes, right? But have a maintenance line in there and make it sized, sized, there we go, make it sized appropriately for the amount of maintenance you're doing or custom requests, right? I'm working with a lot of service organisations that are trying to add productization to speed and streamline, right? But if they have the slot, it's same size as everything else, it needs to be bigger, it needs to reflect that. And I've had so many conversations with CEOs, with VPs, in my life about, look, we don't have dedicated dev teams to these things. So when we're doing these things, we need to make sure that people understand there's a line for maintenance, there's a line for clients, and it might be a big one, it might be 33% of our allocation to maintenance.

  - Depends where we are in our product life cycle.

  - And if we don't like that, then maybe we need to increase that for two sprints so that we can decrease it ongoing. But unless you reflect those in those roadmap documents, it doesn't bring it to the attention except when something breaks and then either it's too late or it's a fire drill and no one cares, right? The fire's out, move on, go back to feature work. So I think when we're talking about certainty, it's not just in the certainty in each block on the roadmap, and visually we can represent that in different ways. Again, that's why I love now, next, later, because everything's in the later. If we're not considering it, it's in that later stack and I don't really care about it. But also I wrote a research note around removing safety blankets, right? And a roadmap is a safety blanket for a lot of people. It implies a level of certainty, implies a level of knowledge that we may or may not have. And that's one of those pieces is look, let's be real about the resource allocation or that these things are ongoing. Because if we don't call them out, sales certainly won't know, marketing probably doesn't know, Our VPs may know, but want to pretend that it's not there. So we just need to make sure that when we're building those roadmaps, we're reflecting the reality across all of the things that we're doing. And not just the feature work, because honestly, in some companies, that's the smallest amount of actual work that you're doing, but it's the biggest thing on the roadmap. And if you have that disconnect, you're never going to make people happy with the delivery.

  - Oh man, I'm gonna nod with you so violently that my head's gonna come off in a minute, Cliff. I mean, the bits I'm hearing that are totally agree, If we only show a functional roadmap, it paints the picture to the rest of the organisation that all we do is build stuff and I'm a big proponent of having things like technical debt, it might be research, it might be discovery and exploration. All of those activities should be on there to provide a level of transparency. Now, we might have different views of that roadmap, so that we show somebody that is only interested in functional stuff, that roadmap. But I think we don't do ourselves any favours. And I think what will also resonate with you is that in the development perspective, we need to carve out time for tackling bugs, technical debt, for solving some of those other problems, the spikes that we go through, and realistically reflect that back up. Does a dev team only show 100% of their resource to product? Or is it 100% of what product can have from them cause they've got other things that they're working on?

  - And I think the other thing, when you start reflecting those realities in the roadmap, and discovery is a key thing, if you're doing dual track, it gets a little trickier to fit that into a traditional roadmap, throw out the traditional roadmap, do what works for you. But I think when we reflect those realities, we build the confidence of the dev team in what we're doing, right? I've always said that the product management role is the sword and the shield for the development teams. It's a sword when the development teams need someone with business capability and influence to fight for them. And it's a shield for everything else, for all the one-off requests, for all of the, well, why didn't you do it this way, for all of the oh my God, we have bugs, why do we have bugs? That's when we put up the shield and block for them. But we still sometimes have a competitive relationship when we don't reflect that reality, right? If sales and marketing and our execs think that that roadmap is everything the dev team is doing, they're likely to shrink what they're telling us they have available. And we want that open and honest because that's the reality, the business is paying for a development team, one way or another, and we need to understand what they're doing. And if that balance is off, we need to do what we need to do to fix it. And maybe that's do less tech debt, I'd hate that, but maybe it's double down on tech debt for a three month period, and I've seen organisations do both. But I think reflecting that reality builds that, strengthens that relationship that we have with the dev teams and exposes the challenges that they have. Most business people don't know or understand what the developers are doing on a day-to-day basis. And that's okay. But that lack of understanding leads to assumptions that we as the product team need to make sure are called out and either challenge or reinforce.

  - And I wanna pick up on one thing that you said earlier, which was that sometimes we don't necessarily have a clear strategy, but the roadmap is a little bit more specific in those things. Some of the clients that I've worked with where they're trying to get organisational change internally, I've actually recommended that they actually create some strategic initiatives around tech debt or replatforming, to make sure that it goes from the technical team that's not just in Jira or whatever tool they're using, but actually into our roadmap and up into strategy. Because otherwise, if that doesn't get exposed to the leadership team, they're just gonna be demanding new features. And actually replatforming or tech debt should be a strategic consideration and something that you share with other stakeholders.

  - Absolutely, I have probably the worst war story on that ever. We had a reporting system back when I was doing some ad tech support and it was four hours off, right? It wasn't required to be real time, there was no expectation on the clients, and then it was six hours off, and then it was eight hours off, still no big red flags. The dev team's like, this is gonna turn over, this is gonna flop, this is gonna die. But no one was listening because it wasn't part of the strategic plan. It got to the point where it was going on 18 hours, almost a full day before clients started to complain. And once clients started to complain, it became a big deal. And then we're like, oh yeah, no, we've scoped that, that's a six month project, right? We have to completely redesign all of the database and reporting infrastructure and all of this. And I was like, and we've been telling you this for six months, so yeah, we'll do it and you're gonna lose this eight man team for six months. Sorry, right? We should have done this when we first told you about it. But it was because we hadn't, and it's not, I don't blame the business for that, I blame myself and the dev team for not communicating the strategic importance of that work. It got seen as, oh, well the reporting system works, it's fine, no big deal, and you're projecting that it's gonna flop over in a year and a half or whatever the projections were. We didn't advocate for ourselves and we didn't put it on the road roadmap, we didn't tie it to a strategic goal. And I think that's critical for the business to understand, that there's tech investment to be made that's not feature development. Because they don't, they don't think about dev teams and technology in that way. So we need to be that voice for the dev teams, be that voice for the ops teams, to kind of convince the business that these investments are important or why do you have a team that's dedicated to infrastructure where they could be doing feature work? Well, here's why, and here's an example of what happens when you don't have an infrastructure team. So I think it's really critical that, one, in the absence of strategy, we create one, because whether it's right or wrong doesn't really matter, it's a straw man for other people to react to. And it's a forcing function to make the business think about what the strategy is. And if they don't want to, then we at least get to define a strategy that we know we can succeed at, that we know we can build to.

  - Yeah, absolutely. Oh Cliff, so many value bombs in there. And I think we're gonna have a great time getting some quotes out here because again, thank you for being so transparent with your stories and your experiences, because that's how we learn, that's how we can make sure that other product managers don't follow in similar challenges as well. So we're really grateful for that story. I've got an interesting question for you, which is, what tools do you typically prefer to use for managing and visualising a roadmap? And you might know my background, but it's not a loaded question, I'm actually a big fan of just sometimes whiteboards and stickies, but do you have a preference, Cliff, and what's worked well for you?

  - Anything other than Excel. Anything other than Excel, PowerPoint or Vizio. I think there's different tools to be used at different times. And I'm actually along with you, I'm a big fan of whiteboards and Sticky Notes, at the ideation phase, it's super easy to move stuff around, you can do dot voting or grouping, like there's so many, and things like Miro and others have kind of opened that world to even virtual whiteboards. So I think there's different phases. Like I'm absolutely all for collaboration tools at that point. I don't think enough product management teams have invested in the right road mapping tools for visualisation, for updating, things like Aha! or Productboard or ProdPad, all of those have kind of taken different directions, they've got different focuses now. 10 years ago, there was pretty much only Aha! as the the road mapping tool that was out there, built by product managers for product managers. Actually, it might have been a little longer than 10, but we'll go.

  - No, it 2013, 2013 they started.

  - Okay, so I'm close. And then like five years ago, a lot more companies had kind of taken root in the space, ProdPads, your Productplans, your Road Monks, and they were all kind of doing the same thing roughly. Some were a little bit better at some things, Aha! has always had its strategic ties, which I think is pretty cool. Now they've all gone completely different directions. Like Productboard is very focused on insight-driven product roadmaps and you can integrate with Zendesk and you can highlight some words, click a button, and it sends it as an insight over to Productboard . I think those are cool, but you really have to be careful to pick the one that fits your workflow. And even if you don't think you have a workflow, you have a workflow. So if you bring the tool in that's wrong, and this I think was the problem with the very first era of product management tools, like Pivotal back in the day. And that's seriously dating me, I don't know how many people that are listening even know what that is, but it was tied to the Pivotal process. So you couldn't buy the tool unless you were doing the way, and if you bought the tool without doing the way, you had to change everything you did to fit the way. And that's of course how they made all their consulting dollars, which is far more than what you paid for the software, which was still extremely expensive. Now we've got enough options out there and some of them are more flexible than others, to kind of fit the tool to our process. Now that's not easy, necessarily, if our process isn't a perfect match, but I think it's an important consideration. Like if you're not interested in insights-driven product road mapping, Productboard probably isn't the best choice for you. If you struggle with strategic design and strategic understanding and setting kind of that OKR or KPI type approach, that cascades down from these, then Aha! is probably overboard for you. You could still use it, it's still a great tool, but I think that's the shift that we need to see is away from the Microsoft Office and Google Suite approach of it's good enough, I've got it all in an Excel, I can update my PowerPoint in 12 different places, in 15 different SharePoint sites, to a tool that this is where the data lives, and I can slice and dice and cut off whatever roadmap view I want, whether that's a public roadmap, whether that's a private roadmap for sales, one for engineering, that goes really, really seriously in depth, one for the CEOs that's just, the c-suite, that's just literally the top level, right? That creates so much efficiency. I actually did a quick presentation, I did a presentation at our last year's Tech Growth and Innovation Conference about this. Like, if you reduce time by two hours a day, five days a week, that's 10 hours a week, that's 520 hours a year or 500 hours a year, we'll give people a couple weeks off, even though product people probably don't take it. That's like a, what is it? I'm trying to remember, it's like $150,000 savings at least. And it's a $6,000, no, it's 190, it was $180,000 savings on a $6,000 investment, for a team of five people. Knock that down, like go ahead and cut that down, maybe it's one hour a day, maybe it's two hours a week. The multiplier is still gigantic. And the fact that we're still using all of these not fit for purpose tools to do this is pretty ridiculous to me. And I get that product doesn't have budget and all that, but if you go back to your finance people, like this will have a 32 times return, this will have a 15 times return, you'll get the money, and you're not asking for hundreds of thousands of dollars, you're asking for less than 10, for a team of five people, for a year. Like, the fact that we haven't adopted these tools more broadly really is sad to me because the opportunity is so huge, but the willingness just isn't there. And I don't understand it. I've talked with people that even want to, but don't have that next step motivation. And some of it's, yeah, the adoption is difficult sometimes, but marketing has their tools, sales has their tools, finance has their tools, support has their tools, dev has their tools, why are we using Jira as our product management tool? It's an issue tracking system, no matter what they've bolt on, and I think their new product discovery tool is actually kind of interesting, but they're fundamentally a software development supporting tool and they always will be, and that's Atlassian's bread and butter. Let's find someone that's built something by product managers for product managers and let's use those tools to save us some time, to make things easier. You can tell, I'm frustrated by this because I talked to so many companies and I see the PowerPoint roadmap and I'm like, how long does it take you to update that? And how many different copies do you have? And are you sure sales is using the right one? I wouldn't be, and I wouldn't even be sure every sales person's even using the same one.

  - Yeah, absolutely. I wanna pick up on two things that you mentioned there, which again, really resonated with me, which is a lot of these tools out there, it's very easy in this modern day to replicate features and things. So I think one of the differentiations between the different tools, and like you said, how you've seen these diversify is really around the founders and the leaders and the influencers within these companies of how they think about product management. And so I think one of them is finding the right one, like you said, with Pivotal, that for you to go out and choose those, go and explore, go and do some trials, use the tool that best resonates with the way that you work. And I think the other thing to add to that is don't be overwhelmed by some of these tools and try and choose the Ferrari or the Rolls Royce of these. Use the one that best supports and just gives you what you need from a roadmapping perspective at the maturity that your team or your product function has it. I see a lot of people come to me as an Aha! consultant, going we've gone from a very basic process to now feeling overwhelmed, and it's like, yes, Aha! can do a lot, but sometimes it's just finding the thing that maybe supports your current needs a little bit further. You don't always have to go up to the top end system in order to get a benefit from roadmapping and the processes around it.

  - Absolutely, and all of these tools integrate directly with the major code management and issue management tools, right? So that alone is a win, right? Being able to have your roadmap automatically updated with the status of the tickets in Jira. I don't have to go run a report in Jira and then look at my PowerPoint and then change the colour of this and then, no, it's all automated. That connection to the tactical is automated. And it allows you to step back and look at it not as a tactical thing, not as a list of backlog items for the teams, let your product owners manage the backlogs, you as the product manager, care about the strategy, care about how you're executing, care about what's changing and how can we respond to it. And all of these roadmap tools make that super easy. Like we actually used Aha! at a company I worked with last, and we did not use all of the capabilities by any stretch. We used the roadmap view and we used tags, and that was enough for us to get alignment, to be able to communicate, we had tags that we would use when something had changed, so that when we had that next review with the marketing teams, we knew exactly what it was. We didn't have to then run a Jira report and look at it and say, oh wait, did that change? Oh, I don't remember, right? None of that, that need to remember, that need to understand at a deep down to the trees level kind of disappeared. We weren't quite sky level, but we were maybe like the tops of the trees, looking down, and a lot of that we couldn't see, and that was okay. And again, back to that trust thing, that builds trust in the dev teams, we trust what you're doing, right? We're gonna report on it, but you guys can do, execute the way you want to, execute the way that's valuable for you. I, as a product manager should only care that your sprint items were done or not, and that we can demo them or not. That's really the level I care about.

  - I want to think what you consider to be a best practise in roadmapping and maybe a biggest mistake. What do you think of those areas?

  - I think the best practise, again, would probably go back to tying it to strategy, right? Make sure that everything on your roadmap ties back to some kind of strategic objective. If you have OKRs, that should be very easy. You should be able to just tie it directly to an objective or maybe to a key result. I am in awe about that a little bit, but everything should at least tie to an objective. And if it doesn't, call that out. I think the mistake related to that, that product managers make, is not being as, I guess assertive might be the better word, when it comes to outliers, when it comes to that one-off thing. If you're working on something that's the CEO's pet project-

  - I was gonna say that.

  - That doesn't tie to strategy or doesn't tie to some objective, call that out, right? Say, hey, we're working on this because Jim said it's the most important thing for him right now. That should not be a controversial statement. If it is, we have a whole bunch of other cultural problems, and maybe everyone nods or maybe someone at the VP or C-level goes, wait, Jim, that's costing us resources that we could be spending here, right? We can create, I'll say something fun, we can create controversy, we don't have to resolve it. But to create those controversies, we need to make sure that they're called out, we need to make sure that the reality is reflected in the roadmap. And if that's things that aren't connected to strategic objectives, then so be it. And maybe we have to defend those, right? Or maybe marketing has to defend them, but if we hide them, if we just say, hey, here's the roadmap, don't look too deeply, we're really not doing anyone any favours.

  - Cliff, you've clearly got a lot of experience and knowledge in this space, I think that's phenomenal. I'm just really vibing by chatting you with you on it. I'm curious whose advice on roadmapping you listen to and maybe any resources you typically refer to or recommend as well?

  - I think we've already listed off many of them, right? Janna Bastow, Steve Johnson, Saeed Khan, Rich Mironov. I think I really like Teresa Torres' stuff on continuous discovery. And while that sounds like it's not directly roadmap related, I think it very much is. Because again, back to that reflecting what we're actually doing. If we're doing continuous discovery work, we need to advocate and allocate that for the roadmap. And we need people to understand, and maybe some of it is that each block on the roadmap has just a little bit of discovery to it before you do the thing. Or if we really want to get fancy, we could have a slide that's the project and has discovery, execution, discovery, execution, discovery, execution, something like that. We assume, we often assume as product managers, that what we do is obvious. And I learned a lesson many years ago that it is not, if you get the trains running on time and people don't actually understand what you're doing to do that, you are actually not seen as a benefit to the company, which is hard to understand. I've done all this work, I've gotten everything running smoothly, it's almost as if at that point they don't think you need to be there because everything's running smoothly. So we need to be strong advocates for the things that we're doing that are delivering value, right? We saw this with the Airbnb thing, with the Snap thing. One, product management isn't going away in either of those companies, and Chesky even said that, but it's that the people doing that job either weren't delivering additional value, and I got called out on LinkedIn for saying that, or the management didn't understand the value they were delivering, so now they're not there anymore. And that responsibility has shifted to another team. We need to be very aware of that, right? As booming as the economy is, we're seeing layoffs from tech companies all over the place. And if the first people to be cut are those that don't appear to be delivering value, whether you are or not, doesn't matter, perception is reality in that case. So the more that we can do to reinforce how important discovery is, how important validation is, and our artefact that we communicate with people with is a roadmap. Building off of that, I think another mistake people make is the roadmap is one thing, it's just one view. Every one of those slots, every one of those spots, should have a supporting slide or a supporting document to it. Maybe we don't call in the continuous discovery on the main roadmap, but on each detail slide, that has discovery, execution, discovery, execution, or long discovery or validation at the end or in the middle, wherever we do those things. One, because we need to advocate for those things, but two, sometimes someone wants that detail, what is that? Why are we doing that? That shouldn't be on your main kind of Gantt chart or now, next, later roadmap that should be easily digestible right away. But we've gotta allocate for that next level of information, what's the business justification? What's the ROI? What's the problem, what's the solution? Like that mini business case should be on a slide for all of those things. And hopefully that doesn't change much, right? The intent is not for that to rapidly update, but we need to be able to bring up those details.

  - Incredible insights, Cliff. Wow, I just so agree with this. It goes into conversations around the roadmap being an artefact, it shouldn't tell people stuff they don't already know, that we haven't had conversations about already. I think that's amazing. I wanna be respectful of time, so I've got a few more questions for you if I may, and maybe possibly the hardest question I might ask you, so don't be too worried, but if you had to distil your philosophy of roadmapping into just a couple of sentences, and often with other guests, we've gone on for paragraphs, but if you could try and bring it to a couple of sentences, What would that be?

  - I'm gonna try words, I'm gonna try words not sentences. We'll see if this works. Collaborative, strategic, accountability comes to mind. Because I think the one piece there that we actually didn't talk about and maybe you've talked about with others is the roadmap being the primary artefact that we create, also creates the accountabilities that we should be responsible for. So I'd go with those three words and kind of leave it at that. I could go on for hours, as all of us can, but I'm gonna limit it to three words.

  - That was very constrained of you, sir, but I totally agree and I think that's a nice way of putting it. Cliff, I wanna give you an opportunity just to tell our audience what you guys are doing at Gartner, because it's not actually necessarily what people might think. So share with us how you can help the community.

  - Yeah, absolutely. It is very different from what people think of Gartner, everyone thinks of Gartner as tech and industries and markets, and we have that. And if you subscribe to Gartner for product teams, you get all of that, it's actually a really attractive deal. But in addition to all of that, we've created what we call our role-based services over the past five years or so. And the realisation that Gartner came to was that we've got a lock there, there's very few competitors out there that reach our level of information on tech and industries and markets, but there are gigantic gaps in support for product marketing and product management and tech CEOs and general managers in a way that's focused on the things that they're doing. So we built these programmes out, there's about 50 people on my team, almost all are former product managers. We've got different, we've got a cloud team, we've got a services team. I'm on the product management philosophy team is what I kind of call it. But what we do is we help teams to improve their product management practises, kind of at a fundamental level. So we work with organisations that are either struggling or not, who want insights into what are the best practises for roadmapping, what are the best practises for defining and cascading OKRs, which I still don't understand why it's so difficult, but apparently that's the most difficult thing people struggle with sometimes. But more importantly, it started intended as like a research and advisory and doing surveys and things like that, typical Gartner, it's kind of morphed into more of a, I think of myself more as a counsellor and a psychologist for product managers because we talk with people both who are a brand new CPO, who was a CMO who doesn't have any experience doing product, those are great people to talk to, 'cause it's kind of blank canvas, let's start from the basics. But we also talk to people who are super experienced who just want that outside opinion, that view on like, I want to try this out. I've got a client that's trying to do kind of a jobs to be done approach to general work that needs to be done across the product team, but not specific to a product. And we had some really interesting conversations about that. So we talk with companies that are mostly larger, like 150 million and above, we have offerings for smaller companies too. But it's really just, I love it because I get to hear new approaches, I get to talk to people about the problems that they're having, and either obvious solutions which they haven't thought of or validating the solutions they want to build. And really, getting a perspective from an organisation that has the ability to do that level of research, right? There's not many options for product managers to receive data-driven advice. and I think one of the biggest challenges we have as product managers, generally, and if you've read my LinkedIn, you know this, is that we still don't know who we are, right? As a profession, we are 10,000 different things because there's 10,000 different companies and everyone does it differently. I am trying, we are trying, to kinda set some of those boundaries and say, look, product management is a tactical, external, sorry, strategic, external customer oriented role. Product owners are an internal, tactical, development oriented role, those two don't mix. And I know that's kind of a controversial thing to say right now, 'cause the movement now is product managers should go back to owning everything, life to death. But when I talk to clients, that doesn't work in reality. and what you call it doesn't really matter. But if you're supposed to be a product manager, but your entire day is spent with the development team, you're not a product manager. And whether that's driven by the culture, whether that's driven by the role, whether that's driven by leadership, our goal is to transform those organisations into real product management teams, with product owners that are on the product team, but doing that tactical execution. So lots of conversations, lots of research, lots of data, we do a yearly annual survey and I've been here for five years, so apparently I really like it.

  - Cliff, that's absolutely phenomenal. I want to thank you so much for geeking out with us today, being so humble and sharing your experiences, letting us know how Gartner and yourself can help with your thoughts, your views, your leadership in that space. We're gonna drop some comments down or some details down in the description box. If you're following on the podcast, you can go to the "Talking Roadmaps" website as well and go and see those. But Cliff, it just leaves me to say thank you so much for spending some time with me, I've absolutely loved it.

  - Yeah, me too, thanks for having me, Justin. I know we've been trying to get this together for a while, so I'm happy we finally can close it out.

  - Absolutely, and to the audience, if you've enjoyed the conversation today, found some value from Cliff, please do give him a follow on LinkedIn, engage in some of his posts. Please subscribe to the channel and share us with others where something that Cliff and I have said has really resonated, please do share that on as well. If you wanna be on the channel where Cliff is, in the hot seat, do get in touch. We'd love to speak with thought leaders, practitioners, and experts in the space as well. But other than that, Cliff, thanks so much again. I'll speak with you soon.

  - Thanks Justin, take care.