Is there just one-way to roadmap? | Greg Prickrill

In episode 64 of Talking Roadmaps, Justin Woods interviews Greg Prickril to explore the nuances of roadmapping and its alignment with strategy. Greg shares insights on defining success, balancing stakeholder needs in B2B versus B2C contexts, and the art of storytelling in roadmaps. He emphasizes context-specific approaches and cautions against overgeneralized advice. The discussion also covers common mistakes in roadmapping, including reactive planning and lack of strategic alignment. The episode offers practical, thought-provoking advice for product managers and beyond.

Greg has spent the last 20 years helping some of the biggest companies in the world deliver better products and solutions by helping them develop a strategic perspective on product development. He worked as a product manager, shipping products at IBM, Microsoft, and SAP before opening his own consultancy focused on enterprise product and solution strategy in 2015. He is a co-founder at coachpms.com, a career accelerator for product people.

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 Dave Barker, Product Management and Localisation expert. So watch out for Season 1 - Episode 65!

• Transcript

  Greg Prickril:
  Think about your stakeholders, think about your context, and be very suspicious, very suspicious of people who are giving you generalised messages about your roadmap, because they don't understand the nature of the programme.

  Justin Woods:
  Welcome, everybody, to the Talking Roadmaps Channel. Today, I'm joined by Greg Prickril. Greg, it's great to have you on the show. Please introduce yourself.

  Greg Prickril:
  I am a product management consultant, trainer and coach. I've been doing product management for over 20 years now. I was a consultant at IBM and had an opportunity to become a PM, spent some time in Redmond at Microsoft, and then got recruited by SAP. I'm an American, but I live in Germany. And yeah, the last 10 years, I've been consulting, and training, and coaching almost purely around product. These days. I'm also now looking at the skills I've developed in product and seeing how I can help more traditional companies adopt a digital strategy. But that is me.

  Justin Woods:
  If you're enjoying the channel, subscribe, hit the bell icon, and give us a like. Well, Greg is one of the experts that we normally have on the channel, along with tool vendors and thought leaders as well. So, Greg, I know you fit into many of those categories, and in fact, we've worked together before, so I'm really excited to chat with you and talk a little bit more about the field of roadmapping. Fantastic. Well, maybe we just kind of think a little bit about, set the scene for roadmapping. What do you think is the purpose of a roadmap, Greg?

  Greg Prickril:
  So, I see the roadmap as part of a strategic progression. I call it the steps to strategic execution. So, before you even think about a roadmap, you need to have what most people call a strategy together, and I divide that into a definition of success, very clearly define what success looks like. The next step is define a strategy, which is the course of action you'll take to be successful. Implicitly, for a given definition of success, I can reach that success a million different ways. Your strategy is your position about how you plan to do it; what you will do, what you will not do. And once you've made that decision, you can build a roadmap which communicates how you intend, how and when you intend to deliver value to the market. It's where the rubber hits the road. So, it's all about, you know, expressing things in terms of stakeholder value, primarily market value, and to a great extent, the things you put on your roadmap, the value, the items of value you plan to deliver should correspond somehow to your strategy. I should see this nice flow that tells me, "I understand this definition of success," this is usually inward facing. "We can all get behind this. I have an idea of what we're going to do and not do to achieve it, and now I know what value I'm going to deliver to the market because the market doesn't really care about the first two things very much. They're very much focused on what value are they going to get from you, and depending on the market, when are they going to get it?

  Justin Woods:
  That's a very clear and considered response to that. I think that succinctly wraps up a lot of my beliefs and understandings of roadmapping as well. So, it thrills me to say that, and think that's a golden nugget to share with our audience right off there is that there are many ways of getting to that end point and the strategies about the game plan of how you're going to get there. And importantly, what you will and won't do. I think we often think about the roadmap as showing a lot of things that you will do, but actually sometimes the roadmap might even show something that you don't want to do on there maybe. Before we chatted earlier on the interview, you mentioned something to me which really resonated, which was that we should product-manage our roadmap, and I think that that really resonated with me in terms of how we should approach that. Wonder if you could unpack that a little bit more.

  Greg Prickril:
  Yeah, it's an interesting way to think about our roadmap. It's a little recursive, but our roadmap has stakeholders, we're just one of them. So, just like as a PM, if you build a product for you, there's a really good chance that the market will be disappointed. They have different needs. So, as PMs, we need to think about who the audience is. And depending on our situation, we almost always have an internal audience. That could be engineering and other folks who use the roadmap to align. Our leadership wants to know what we're going to deliver. Remember: they're usually a step ahead of us in conversations they're having. They wanna be able to talk, you know, other senior leaders and senior leaders at customers about where things are going. And, you know, my background is in B2B, and very important stakeholders were external. And this is a big difference that I've seen between B2C and B2B. And B2C, like, I don't know, Tiktok's roadmap; I don't really care. New features show up. I'm using it for workshops now. I don't need the roadmap, I don't care really. But in B2B, it's very often the case that you are as much selling the roadmap as the product that you have. You know, you're solving very complex problems, and it's very rare to have everything the customer needs. So, what you sell them is what you have and a promise to deliver what they need, so the roadmap takes on a different value. So, we need to think about our roadmap as a product that we are delivering to a market. Who are these stakeholders? They all have different needs, and in a given context, in a given market, there are, you know, different things that they want. So, what I would advise people is you will hear a lot of generalised advice on roadmaps, about whether you should include dates, don't include dates, make them objective-driven. Blah, blah, blah, blah, blah, blah, blah. You know, you cannot generalise. Just like I don't think you can generalise about much in product management, you can't generalise much about roadmaps. You need to understand your context, your stakeholders, and deliver what's going to generate value for them. And if it's not gonna generate value, like, I don't care about Facebook's roadmap, I don't need to hear about it, you know? Just that's one stakeholder you can pay a lot less attention to. But I can guarantee the leaders at Meta want to know what Facebook's roadmap is. There's no doubt about it. And saying, "Oh, I'm not gonna put dates on it," is really cute, right? It's really, like, this naive, generalised guidance that I think you should avoid when it comes to roadmap and product management in general.

  Justin Woods:
  I totally agree. There's a lot of misinformation out there, and I think it's easy to get caught up on that. But you've got to understand the context. You've got to understand the stakeholders. The massive difference that there is between B2B and B2C. I've been a product manager in a predominantly B2B environment, and there's no way I could have got it. You know, I used to look after the Dell e-com basket for the online purchase path, and so that was where 50,000 orders were going through daily to process things. There's no way that I could make changes to that, that weren't involving legal and tax and accounting and things like that. So, absolutely agree. It's critical. And there's something that you mentioned in there that really stood out to me, which was that, in B2B it's very much around what you sell and also a promise, and that just really registered in my mind as something that totally made sense. The way that you approach things is different, depending on your market and how your product set is. So, we should absolutely accommodate that in our roadmaps as well. That was gold. So, you mentioned things around the audience of a roadmap, and so we're creating a roadmap maybe for different audiences. Who do you think owns and maintains the roadmap within an organisation?

  Greg Prickril:
  That is such an important question, and in my consulting practise, I do what are called maturity assessments. And sometimes I do these thought exercises. Like, so I have a whole framework, I gather a bunch of data, pump it through a model. But I ask myself, if I had to ask one question of an organisation to assess their maturity, what would it be? You know, it's a kind of rhetorical exercise. But I can tell you one of the first things I ask when I get there is who owns the roadmap? And there should not be any ambiguity. There should be no pausing. Whether I'm talking to a leader or an engineer or somebody in sales, the response should be product management. And if I see this hesitation or if I hear people say, "I don't know," then that implies, you know, a lot. You can infer a lot from that statement. So, to me, without a doubt, I would put it this way: product management is accountable for the road. It's, you know, a fairytale to think you're gonna go off in a corner and develop that thing by yourself. As we said, there are a lot of stakeholders, and some of them are powerful. Your leadership, you have powerful customers; that's another dynamic, you know? In B2B, you may have three customers that represent 40% of your revenue. Guess what? They have, you know, exaggerated influence on your priorities.

  Justin Woods:
  Yeah, absolutely. It's that balance between... In that situation, in that scenario, it's that balance between delivering your business objectives, and then delivering what some of your customers want. It might be things like funded development. So, if they're, you know, giving some form of revenue or there are commercial agreements that they're gonna give you some of benefit or funding to actually go and build those features for them, it's that balance in product, especially in B2B, of what do we need to build for the company? What do we need to build specifically to be able to get certain financial agreements for those customers and balance that funded development between where we want to take the product and where our customers almost wanna take the product?

  Greg Prickril:
  That is so important, Justin, and I think I kind of alluded to it before, but it's worth calling out specifically that product management all-up is really about balancing what the market wants with what we want. So, just because the market wants, it doesn't mean we should do it. May not be within our core competencies, may not be profitable. There are a million reasons we might not want to do it. So, we have to balance those, and the roadmap should clearly reflect those. And so many things come to mind. You know, the roadmap is at the intersection of so many important processes, right? You've got, like, release planning, downstream, each kind of milestone on the release. You've got strategy, you've got market research. But at the end of the day, this thing should represent this balance. And an important stakeholder on the roadmap can be engineered, right? When you get to mature product, we read a lot about making customers happy and innovating and all this stuff, but I can tell you, you know, I did a lot of new product development. Second, third release, 60% of my capacity was just fixing what we screwed up in rush to market in the first two releases. So, yeah, this balance is really important, and it reminded me I am working right now on a workshop around product discovery, and I found this old slide that I had built, which was basically a problem wave map. So, this is an interesting twist, it just kind of came up to me randomly. You will hear people, you know, normally on roadmaps, we capture what I just call roadmap items. They're not really parallel, they represent different things. One may be a feature, specific feature. One may be a feature area. One may be some broad integration or some broad initiative around UX or whatever; they are all over the place. You'll hear other people say that you should build the roadmap around objectives, or that it should reflect what you want to achieve, which is nice for internal audiences; external audiences don't care. But it just occurred to me, I wanted to mention this, that I think an interesting idea is to build an inward-facing roadmap, probably you can validate it with external folks, that shows what problems you want to solve over time. We don't know how we're going to solve them. We don't know what features we're going to develop. But just a thought I had, something that I saw today that it's interesting to think, as I go forward, not what am I necessarily gonna deliver, let's flip that around and think what problems do I want to solve and not solve in the future?

  Justin Woods:
  Yeah, totally agree. And you mentioned something there, roadmap items, and that's terminology that I've used intentionally with clients in the past because they can get very caught up in the framework naming that they're used to, epics and stories and tasks, or initiatives or features and things like that. And so, actually I quite like that because roadmap items, almost the fact that you have to define it means we don't have preconceptions about what we see on the roadmap. And to your point, sometimes a story or a task can be significantly important that it needs to be on our roadmap, along with a three or four strategic initiatives. But if you kind of level set the expectations of that and say, "Actually this is a roadmap item, that's what our stakeholders care about." They don't really care that this is a story and this is an initiative, it's got significant benefit that they're wanting to unlock and show that on the roadmap. So, that makes total sense. And this, actually it ties back to something we were talking about about different versions, Greg, different versions of the roadmap.

  Greg Prickril:
  Yeah and I told you, I always ask who owns a roadmap, and then when I talk to PM, I look to see versions of the roadmap. That's a sign of maturity to me, because we have all these disparate stakeholders. I can remember, when I was a PM, at SAP, I had basically a spreadsheet that was kind of like the master roadmap, and I did not share that with everybody, because there was a lot of embarrassing stuff on there. And I definitely wouldn't lead with a lot of those items when I talked to leadership, because what I was basically spending most of my capacity doing was fixing what we should have done right the first time. So, you know, there's some massaging in the messaging there. Gartner would come on campus. I showed them something different because I wanted to highlight innovation and all the cool stuff. That isn't what I would show our biggest customers, our close customers. There were certain things they needed to see and certain things I wasn't that thrilled for them to see. And then, you've got a roadmap; again, in B2B, the roadmap is a sales tool. There's almost no way around it. So, what I would show a prospect could very well be different than what I showed an internal customer, different than what I showed the market analyst, different than what I showed my leadership. Now, all these things should map very clearly to, like, some master version. I'm not talking about having just wildly different promises made to different people, but the way you show it, and the way you position it, and you, in a different context use such an important word, which is story. Your roadmap should tell a story. I should be able to look at it, and I should be able to probably infer your strategy, but you shouldn't leave that to the audience. If I understand a little bit about your definition of success and your strategy, this roadmap should be like the other hand clapping and should tell me a story. It's like, "Oh, he said he was gonna go the partner route, and boom, they're developing APIs, they're doing these things. He said that they were gonna try to go down market. I see simplicity, I get it," right? Humans, we are hardwired, I think, to understand and, you know, have stories resonate, and I think that's where you want to get. That's maybe the ultimate task. With a little bit of a preamble, does your roadmap tell a nice story?

  Justin Woods:
  Yeah, totally agree. And that's part, for me, the joy of roadmapping is that it's an artefact that can be stylized, it can look beautiful. It gives important information for the person that needs to read it and interpret it and align with it. So, that's why, you know, I've made roadmapping part of my career as a discipline of product management because it's the one thing that I find really fascinating. Greg, you picked up something, and I think this is massively important. Sometimes when I speak to companies or clients, the roadmap is the highest point of their strategy; that's what they think their strategy is. But I know from your background, that's actually the very end of strategy for you. What are your thoughts on that statement? What's the relationship between a roadmap and maybe the vision strategy objectives? Where do they align?

  Greg Prickril:
  Yeah, so I look at strategy in the context of a broader model. It's called the business motivation model. You can look that up. But it defines means and ends, and the ends are the things you would like to achieve; that's your vision. That is this aspirational thing. You may never achieve it, but it defines this state that you would somehow like to achieve with your product. Then I can go to goals which are general objectives, which are very specific. And then, you know, once I have a definition of success, as I said before, you need to have a position on how you plan to achieve it. Are you gonna go direct market? Are you gonna go through a channel? Are you going to... you know, there are a million things that you'll do and some things you'll explicitly not do to achieve it. And without those, you can build a roadmap without. Most people do it. That's actually at least the 80% case is you're kind of alluding to. But the tendency is, when you don't have these things defined independently is that you become extremely reactive. The loudest voice in the room is gonna dictate what ends up on your roadmap. And you may show it to people. Sales is thrilled with it, your customers are thrilled with it, leadership is thrilled with it, but you are not moving in a strategic direction. You know, the market can drive you straight into the ground. And now, we're seeing a lot of talk around generative AI. I remember, 15 years ago, when people were talking about the cloud, people's customers were telling them, "I will never put my data in the cloud." And the customers that waited lost, and some of them aren't around anymore. So, you have to have this strategy that looks more broadly, looks at the market and says, "Look, where things are headed is here." And as a product manager, if you don't have this strategy explicitly defined and aligned, you don't have any chance at all of ever pushing back on revenue. The people with the money are always gonna win. They're gonna derail your roadmap with stuff that comes from some big deal, and you will be defenceless. And you might lose this argument anyway, but the first element of pushback you have is to say, "Do you remember we looked at this strategy? Do we still believe in it?" You know, another sign of, like, organisational maturity and something that I would ask when they define a strategy and a roadmap is, "To whom did we say no?" Like, "What can we point to where we said no to somebody important, not somebody we don't care about." Because there's a really good chance, if we haven't said no, we are not thinking strategically, we are not making hard decisions, right?

  Justin Woods:
  I've seen that and felt that, you know, I'm almost living through that again as you're describing that into previous experiences that I've had in product management. And in fact, something that I kind of teased out from that conversation is that it feels like a lot of disagreement on the roadmap is that we weren't already aligned on the strategy in the first place. Because if we're aligned on the strategy, we'd understand the roadmap.

  Greg Prickril:
  That's the trick. That's the trick to quick alignment around the roadmap. Make sure you have a clear definition of success, get some validation around that, because building a strategy on something that people don't agree with doesn't make any sense. Once you agree on the definition of success, define a strategy, write it out, at least an elevator pitch. Write out five or six pillars, what are the things we are going to do to achieve that success? Get that aligned and signed off on. And then, the roadmap should be a chip shot. The roadmap should be easy, especially which I believe in this strongly, you explicitly tie your strategy and your, you know, goals and objectives to roadmap items, so that you show, "We are doing this because we said this was our objective and this is our strategy. Not everything will map. Not everything you do in a roadmap is strategic. Some things are reactive. Some things are just, you know, tech debt or whatever. But if, you know, you can tell how strategic your roadmap is by how many things you can explicitly map. And sometimes the right answer is 10%, sometimes the right answer is 80%. But if it's 0%, I guess, regardless of the percentage, you have a question to ask yourself. You know, are we strategic enough? Or are we just kind of thrashing around, trying to please anybody? And in five years, we'll be out of sync with the market and wondering, you know, what happened.

  Justin Woods:
  Yeah, absolutely. And I know from just interacting with you in the past, Greg, following your posts on LinkedIn and the things that you share, that the strategy element of this is extremely important for you, 'cause I think it's what defines companies between each other, and the roadmap is really just the assembly of the Lego blocks of what we said we were gonna do in our strategy into something that's more of a model and, like, a cohesive thing that we're building and say, like, this is the execution of, not the execution necessarily, the direction of what we understand we defined in the strategy. And so, I really appreciate that from you because what I've often found with clients and is that, again, the roadmap is the most strategic thing that they have. In some cases, that's okay, but you have to go further than that in order to really understand the company and where it's going, so.

  Greg Prickril:
  To avoid being reactive, and do you remember just in this engagement that we worked on together, that was one of the key contributions I think I made to that client, and you made to supporting this was actually defining in a tool, strategy, goals and objectives, and then having a requirement that PMs align those things and being able to reason over this. So, this is not just abstract stuff. It's also not rocket science. It's also not something that requires super sophisticated tools. Having it done by colour coding in PowerPoint is way more powerful than not having this alignment at all. So, yeah.

  Justin Woods:
  I absolutely agree. Absolutely agree. And maybe we go into that a little bit actually. So, we've talked about colouring, and maybe we've got some cadences there of things. Do you have some preferred ways to visualise and style for a roadmap, Greg?

  Greg Prickril:
  I do not care. I can tell you I'm old school, so I tend to think about roadmaps in, like, a milestone orientation, and really, people care about releases. Again, your market cares about when they're going to get value, they may care less, they may care more, but that's what they care about. It always kind of shocked me. It's been maybe now 10 years that we've had a lot of these dedicated platforms for PMs, and they tend to represent roadmaps in gantt charts, right, which gives you this indication of the duration of development, which that's good for internal alignment, maybe leadership; nobody else cares. And it's stupid to show it, quite frankly. You know, I should be, you know, kind of pricing my product based on the value I deliver, without any concern about how long, well, not any concern, but from the market's perspective, I don't want them to know how long I spent on it. If I spent a day on it and it adds tremendous value, I don't necessarily want them to know that. If I am spending a long time doing refactoring or moving to the cloud or something, I don't necessarily want to know that. So, I think in milestone. I think of delivery. I know a lot of people talk about continuous delivery and those kinds of things. Once again, in general, like, this is this grand unified objective we should have. It's not. In almost most cases, like, I don't want a new feature every time I open an application, even the ones that I use for my own entertainment. It's disruptive. Certainly the ones I rely on. And, you know, if I am running somebody's accounts receivable, if I am running their CRM, the last thing I want is to distract salespeople with some new widget, gadget, you know, thing that shows up. So, I think there are cases where you're continuous delivery, delivering continuously. I think there are far fewer of those that are actually being done that make sense. You know, you let little things slip. Obviously, you let, like, it's fine to pass through bug fixes and all that stuff. But even people like Salesforce, who are the poster-children for this whole SaaS model, still have releases. Why? You know? And I guess that's an important point about roadmaps is, you know, we tend to think that what limits what we can deliver is our development capacity, but in my experience in complex B2B, it's really your customer's ability to absorb changes. That's the limiting factor. So, when we think about how we represent it, when we think about our cadence, what we should think about, this thinking that the faster I can deliver value is always better is just false, right? There's an optimal point. And based on your customers, your market, they may be overwhelmed with a release per year, right? Because every time you release it, they have to set up a test environment and a staging. Every time you release something new, it costs millions of dollars, you know? They are not interested in having these things. So, again, you know, think about your stakeholders. Think about your context. And be very suspicious, very suspicious of people who are giving you generalised messages about your roadmap, because they don't understand the nature of the product.

  Justin Woods:
  Oh, Greg, that's such great advice, thinking about it in that way. And I've never thought about that in that way, in terms of how quickly can your customers absorb the changes? What can they consume? You know, delivering quick change or iterative stuff isn't necessarily what they're wanting. I actually do agree. I don't if it's that I'm getting older, or there's too many applications in the space now, but I get quite frustrated when new applications come up on my... sorry, existing applications are on my phone and new functionality; they change the look of the icons. I've gotta learn the GUI again. And things like that. And it's just, like, sometimes that's not beneficial. So, really good point around the context of how quickly can people absorb those changes? Yeah, I think that's changed the way I think about road roadmapping and maybe even some form of product management.

  Greg Prickril:
  Very nice. These are fundamental things. And as I said, I've been doing this 20 years. I think it's interesting, for the last 10 or 12 years, I've had to think about this stuff in a very abstract way, right? To express it to clients, really get to the fundamentals, what matters. And again, I sound like a broken record, but I think the most fundamental insight that I've had in the last few years, based on 20 years in product management, is you cannot speak about it in a homogenous way. You cannot say, "This is the way you should set up your org." "These are the roadmaps you should build." "This is the way you should do this or that." There's some principles that are interesting to understand that apply more or less in different contexts, but now more than ever with recent developments, we have to be extremely critical about what we hear. And there are some telltale signs that somebody is just trying to, like, get clicks or, you know, whatever. And chief among them is this generalisation. If somebody is saying something about product management and they don't caveat it, if there's no nuance, that should be a signal to you that this person doesn't know what they're talking about. Because there are precious few, if any, things we can talk about that you can just blanket-apply to every situation.

  Justin Woods:
  Totally agree. And that's one of the reasons why I'm quite keen not to have things. I understand the intent behind them, but templates, frameworks, I think they're useful starting points. But when somebody takes one of those and just doesn't think about the intent, the nuance behind it and uses it, I think sometimes that's where models and frameworks can be harmful. I think we've seen that with agile. I think we've seen that with product management and how it's swinging from one side of product management to the other in terms of, you know, when I was becoming a product manager, it was much more high-level strategic, profit and loss, understanding the customers. We've then seen the shift or the focus being more development or, you know, how quickly can we iterate and build features. And I think we're seeing the harm or some of the challenges around that. And now we're starting to become up the other way again, which is to start thinking about customer centricity and what that means, rather than a focus on delivery and story points and capacity in sprints, you know?

  Greg Prickril:
  As a profession, we are way too delivery oriented. We need to be more business oriented. I've been saying this for a long time; I really see it as a theme, and I think a lot of people are thinking the same way. And my take today is that there are developments like generative AI that are gonna essentially automate a lot of what we do, which is great. We will have time to think creatively. We are underwater, as is UX, as our engineers. We have an opportunity now to increase our productivity to the point that we can spend our time doing more valuable things. And I think PMs who don't show this business insight, who don't make that switch during their career, you may not start out your career. I think, when you start out your career, you should be delivery oriented. How do we make the sausage? But very quickly, you need to think about what does the sausage business look like? How are we going to sell this thing? And I would encourage people to do that. And really understanding the role of the roadmap, understanding how it ties to strategy, and how strategy needs to reflect this balance of business needs and market needs is somehow, like, some really fundamental key formula that I think people are gonna have to internalise and understand, because the times, they are a changing. There is a big change coming. There is a storm coming; it's called AI. And people can poo-poo it all they want, it's not going to replace you. It's going to make other people who are better at using it than you are way more productive, and you're not gonna be needed anymore. It doesn't have to replace you to end your career in product. So, I think we, as a group, need to wake up, and as this thing starts saving us cycles on the things we've done about delivery, we have to fill that space with insight into the business. Maybe it is a swing back, but I think, as a profession, we are gonna have to swing back to this business thing. And strategy roadmap is a great kind of, you know, centre of focus as you start making that transition to start thinking about, okay, instead of just thinking about this as delivery to the market, what are the business implications of the roadmap? How much of my strategy reflects what we're trying to achieve as an organisation? And that's only the beginning, right? But changing this mindset, I really like the distinction you make. Yeah, we are going to have to become more business oriented.

  Justin Woods:
  Right, yeah, exactly. What do you think is some of the biggest mistakes that people make in roadmapping?

  Greg Prickril:
  Yeah, not doing all the stuff I've talked about.

  Justin Woods:
  That's why I wanted to come into that question.

  Greg Prickril:
  You know? Not having a clear definition of success, not having a strategy, not socialising it early enough, not doing, like, very simple analytics. So, something I love to do with roadmaps is kind of mark up the roadmap items, and then do these, like, very simple pivots. So, how much of what we're investing is strategic, how much of it is reactive? How much of this is for the customers we have, how much of it is for the customers we want, right? And it's gonna be imperfect; it doesn't matter. It gives you this broad kind of view, you know, so not really taking a step back and thinking about it as a general, thinking about the story instead of the chapters or instead of the, right, the characters or, you know, this little part. What story does this tell me? Am I not being strategic enough? Am I being too reactive? Are there things that are going to differentiate? That's a whole nother topic. What, on my roadmap, we talk a lot about innovation; it's overrated. Ask yourself what is going to differentiate me? It may not be innovation, but as I look at this roadmap, today, this is what differentiates me. Is that still what differentiates me three cycles down the road? If not, my roadmap better reflect that, because somebody is gonna have to go out and sell this thing. I'm a B2B guy, that's why I think about it. Or it has to sell itself; whatever. And there's gotta be something that sets it apart from what everybody else is doing. And when we get in this super reactive mode, we never even ask that question. It's like, "What customers am I pleasing now?" "What customers am I gonna please in the next turn of the crank?" "In the future, what customers do I plan to please?" Instead of, like, "How am I going to differentiate?" "How am I going to stay alive?" "What do I have on here?" So, I would say that's a big mistake, not doing, like, really simple horse-grained analytics on these things to make sure this thing is, like, coherent.

  Justin Woods:
  I totally agree. When you're saying that one of the approaches I take is a look at the roadmap, and for each of the items, roadmap items, I'll be like, "So what? So, what does that mean?" You know? And it helps to tease out, back to the value, back to the strategy, you know, so what? So, what happens when we deliver this? Why are we doing it? Do you have a pet hate that you really don't like to see on the roadmap?

  Greg Prickril:
  Nothing comes to mind. I think the closest that comes to that are these platitudes, these generalised things, like next generation UX or something. You know? It's just obvious to anybody, and by the way, your customers that you are just full of poo. You know, that you don't know what you want to do. Those things have to be decomposed into something, right, that is meaningful. I guess, if you have a lot of faith in you, or your stakeholders are kind of dopey, they'll look at that and buy in. And maybe sometimes that's an interesting way to get their attention and make them ask, because I've presented a lot of roadmaps. It's very rare for them to be lots of applause or even lots of questions. That's the truth. But I hate to see, like, these really generalised just platitudes, meaningful buzzword things. And now, I guess the rage is now, next, later or something. Roadmaps, by the way, that's what I've always done. I've been doing this 20 years. That's the tendency to have this one bucket at the end that just represents the future, and you just stick every buzzword in the world there, you know? But, I guess, those are the things that bother me, these general things that don't really tell me anything, that are taking up space, you know, that I could put something,

  Justin Woods:
  Greg, that's a great response, and I hope our audience are going to get some value there. I know, again, that going through these, speaking to different experts, I still learn a lot, or it picks up a distant thought and brings it front-of-mind again. So, I really appreciate that. Greg, you've been, since I've known you, maybe for the last 4, 5 years or so, you've been one of the people that I really listen to as a voice from product management, your extensive experience in B2B I've always appreciated and your thoughtfulness around product management because you can kind of have an introspection to that. So, you're one of the people that I really value and take advice on product management in general. I'm curious, whose advice on roadmapping and product management do you listen to?

  Greg Prickril:
  I think I have authority issues. So, you know, I don't care where a great thought comes from. As you're kind of saying now, sometimes you can talk to somebody and they remind sometimes. somebody just asks a question, and it makes you think deeply about stuff. I love the stuff you write about roadmaps because, you know, we're just kind of naturally aligned. So, it's nice to see my similar beliefs reflected there. There are people, like, historically, Rich Mironov, I like a lot of his stuff. It's fairly direct. And I'm trying to think, you know, what I'm seeing now is much more emphasis on the difference between B2B and B2C, like product management. So, I tend to gravitate more towards the B2B folks, but I think there is still, like, very little alignment. There are still a lot of people. What I am seeing is a lot of people violating kind of my basic rule of, like, just trying to tell people how to do their job. We're trying to impose their worldview on somebody else's context without any sensitivity whatsoever. And I guess what I'm saying is I don't know. I think, as product managers, we should take wisdom wherever we can get it. And sometimes it comes from very unexpected places. If you do find somebody who really reflects your kind of vibe, your values, follow and listen to them, but still be super critical, you know? I don't care who it is. Maybe they sold 10 million books. Be critical. Don't be afraid. Nobody can speak ex cathedra on product management. It is way too broad. There're just way too many variables. So, again, broken record. There are a few people I listen to. I try to listen to everybody critically, no matter if they're experienced. When it comes to roadmapping, I highly suggest people follow you and Phil. I think you have the right philosophy. What I love about you, Justin, is you also have the background in tooling. So, really, you know, institutionalising and, you know, really making things happen. So, I've learned a lot from you as well. But I would just tell people, be critical of everybody. Find somebody that you kind of trust and maybe pale, give them a little more.

  Justin Woods:
  That's great attention. We can fall into following the herd and borrow other people's opinions on things, and that can get a little bit too confined. And so, thinking outside of the space, thinking about, you know, I've learned a lot from customers even. So, I think that's a great advice, Greg, just to be critical but learn from everywhere. I wonder if there's anything around roadmapping, as we approach the end of today's session. Is there anything around roadmapping or product management that I should have asked you but didn't?

  Greg Prickril:
  That is a good question. I think an interesting question, and I'm asking myself something I can't really answer, is, like, what is your best kind of roadmapping presentation experience, and what is your worst? So, we didn't really talk today about presenting roadmaps. So, developing a great roadmap is not easy. There's a lot that goes into it, at least in my world. I consider presenting them an art in and of itself. So, a little oversimplified, you can take, like, an average roadmap and have a great presentation and it will land way differently than if you have a great presentation that isn't presented the right way. And I have had a member of the board of one of the biggest software companies in the world turn their back on me during a presentation. I've also really had people that I trust talk about how this roadmap presentation really inspired them and changed the way they thought about the product, thought about where the company was headed. So, I think that is an interesting question, especially for people that have been doing it a long time, because I'm sure there are a lot of funny stories about things that did not go well at all in presenting a roadmap. And then, less interesting but maybe inspirational, like, when have you had a presentation that just, you hit on every cylinder and really, you know, got the points across to the audience.

  Justin Woods:
  That's such a great point is that, actually, one part of the problem is presenting that story arc in our roadmaps. But then, like you said, if you don't then present that in the right way and the storytelling that's involved in that, as well, that can be the difference on whether it lands or not as well. I think there's a lot for us to unpack there, Greg, and maybe some follow-up posts or even a follow-up session to talk about those war stories would be amazing. Greg, I've really enjoyed today's session. I've enjoyed working with you in the past. I've enjoyed learning your posts and getting your perspectives on things. I just wanted to give you an opportunity to share how you help your clients and how they can find out more.

  Greg Prickril:
  Yeah, I have a couple of sides to my business. There's prickril.com, which represents most of my consulting business. Most of what I do is around product management maturity. So, I don't usually act as, like, a fractional CPO or something like that. I go in, I gather a bunch of data, I help an organisation figure out where they could be better, and then put a framework in place so that they move towards continuous improvement. I do, a lot now, I'm trying to take all these different what I consider assets that I have, like, courses, workshops, coaching, this knowledge, and build programmes for organisations. You know, you didn't ask me about it, but I'll pick this opportunity to say, you know, a lot of people wanna upskill their PMs. The quickest way to waste a lot of money is to just send them to training, check a box, and imagine that they're magically gonna come back to work in the environment and apply everything that they learn. It doesn't happen that way. So, I think one of the ways I help my clients is really pitching to them, you know, things that are realistic that will stick, right? Avoiding this kind of checkbox mentality. So, you can go to prickril.com, you can go to Coach PMs. I coach all kinds of people, people who wanna get to PM, into PM, CPOs. At this point, I have, like, a lot of experience that I can share through there. If you're wondering how you can take your product management to the, you know, kind of next level and set them on a course to continuously improve, I consider that something that I'm really passionate about.

  Justin Woods:
  And I've seen you, you know, I've been a part of your courses, I've seen you embracing new things. I think you've been very progressive in that space. So, Greg, I just wanted to end by just saying thank you so much for joining us today. Thank you for your services to the product-management discipline. I've learned a lot from you there as well. And thank you for joining us on today's channel.

  Greg Prickril:
  Yeah, thanks for having me. It was really my pleasure.