Can your roadmap take a punch? | James Mayes

In episode 10 of Talking Roadmaps, Phil Hornby interviews James Mayes, co-founder of Mind the Product. They delve into effective roadmapping strategies, addressing common challenges and best practices. James shares insights on adapting roadmaps for resilience and growth, emphasizing the importance of flexibility in product management. He also discusses the evolution of Mind the Product and its integration with Pendo.

James’ first career was 15 years of building high-performance technology teams for startups, tech giants and the banking world. From there, he moved into startups, joining the founding team of Mind the Product. He’s spent the last twelve years growing the firm into one of the most recognised and respected brands in the Product Management space, with conferences in five cities, meetups in over 200, and an enviable blue chip client list. The firm was acquired by Pendo in February 2022, where James remains heavily involved as an Evangelist for the Product Management discipline and especially Product-Led Growth. 

“Your roadmap is going to get punched in the face. Do not get emotionally attached to it”

— James Mayes

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).

Can your roadmap take a punch? | James Mayes

Phil Hornby and James Mayes

Next up we have Radhika Dutt she’s the author of Radical Product Thinking as well as a highly experienced product leader and advisor. So watch out for Episode 11!

• Transcript

  - Welcome to Talking Roadmaps, the channel where we talk about everything roadmapping from good practise, bad practise, odd and the ugly and between there. Great to have you today. James, why don't you introduce yourself?

  - Thanks for having me on the show. So I'm James Mayes. I'm one of the co-founders of Mind The Product. If you've not Mind The Product before, we started at a community of product managers in London and it grew to conferences, training, podcasts, newsletters, and most recently a premium content subscription business, which was our way of surviving the pandemic and going deeper on some of that material. Earlier this year we became part of the Pendo family, who are the leading product experience platform. So happy to take some questions on that as well, but I've been in around the product circuit for more than a dozen years now. Where do you wanna take this? Go on, fire away, sir.

  - Well, obviously we're gonna talk about roadmapping, but obviously I'm gonna do that little mandatory thing at the start of every podcast. Please like, subscribe, share, and all the rest of it. If you'd to be here where James is, do get in touch with us as well 'cause we'd love to have other people on the channel. Where to start? Let's start with that most fundamental. James, what's the purpose of a roadmap in your perspective?

  - Yeah, this is one where I think lots of people do have a slightly different perspective on what purpose it serves. Fundamentally, it's a communications artefact. I think everybody gets that. It's a way of communicating what you're working on next and where you're going. But I think more interestingly than that and a line that I'll borrow from Janna, who you mentioned earlier, it's a prototype for your strategy. It's a way of saying, "These are the things that we're doing, these are the places that we're going." Sharing that with your customers and actually starting to take some feedback and get their thoughts before you go commit expensive engineering time on actually building and shipping things.

  - Oh, it is challenging as you say, there's lots of different things there. I mean, so we've asked about the purpose, but what about the audience? You talked about being the communication, so who is it communicating to?

  - Well, I think if you go back to roadmaps 10, 20 years ago in the world of product, and let's remember the world of product management is an incredibly fast-changing discipline right now. It's still pretty nascent. And by that I mean if you ask 10 chief product officers, "What's a good product manager?" You'll get 10 different answers. It's far from structured. So who's the audience? That one I think continues to change, continues to grow. 10 years ago product manager might have been buried in the backlog one day, looking at the roadmap the next, and maybe involved in a little prototyping here and there. Whereas now we're getting drawn into what's our market positioning, what's our competitive benchmarking, what's our go to market strategy for this? So not only are you communicating with the engineers and the designers, but the sales folk, the execs, the marketing people. So I think it's kind of hard to define that audience. That audience is fundamentally anybody who's engaged with the product, both internal and external. I see some companies who do a great job of using roadmaps to actually communicate with their customers, and they might well have three different versions of the roadmap. There's the version that they show to the engineers, "Here's what's coming up next." There's the version that they show to the customers, "Here's the stuff that we think is interesting, but we haven't yet decided to commit to go for it. What do you think?" And then the version that you're working with your execs on and saying, "This is where we're going with the business strategy. These are the things that we need funding for. These are the problems that we want to put budget behind." So I think roadmaps don't necessarily need to be just one roadmap for the company. There's no reason why one company might not have three or four different versions of a roadmap for those different audiences.

  - Yeah, funny, you've hit on my three out of my core target audiences for a roadmap. I also think partners perhaps and prospects might be slightly different from customers. There might be an argument there, but yeah, but I do argue it should always be a single source of truth. One roadmap with different views on that perspective, on what it contains.

  - Absolutely. Absolutely, I think a single source of truth is right. But you can choose which bits of that you actually want to expose to different audiences, sure.

  - Yeah, totally agree. Yeah, I mean, it's interesting in that journey you talked about, what a product manager might have done 10 or so years ago. I've gone the opposite journey. I've seen the opposite. Like I was doing that strategic stuff as a product manager 10, 15 years ago, and the journey I've seen is to get more and more heavily involved with the tech. So it's interesting to see your, again, different experiences of the evolution. It was an American company I was working for back in the day, so maybe it was a this side of the pond, that side of the pond difference as well.

  - And again, I think it does speak to the diversity of the role. I think it's one of the most interesting roles in tech because it is so diverse, and that's also born out by the routes that people take into product. I mean, was your background on the computer science, engineering side of things by chance?

  - Yeah, yeah, I was on the tech side originally. Yeah.

  - Right, so that's one route into product, but I also know many of the senior product people that I know that are really killing at the moment are people who actually come from more of a customer success, customer solutions background. So they're people that spent a lot of their time actually dealing with customers, understanding the problem, understanding the pain point, understanding what those customers are trying to achieve. And then they learn how to talk engineering so they can go work with developers and actually get stuff built to solve those problems. Likewise I've seen a number that have moved in one way or another from the marketing side of things into the product world. So there's so many different routes in, and again, that gives you a different flavour of product manager every time.

  - Yeah, it's the circ called accidental profession, 'cause none of us went and trained in it, and we kind of found our way there somehow circuitously.

  - Yeah, I think you're starting to see some of the business schools now that are implementing product management degrees in education of one sort or another, but still the vast majority of people that I come across in product, "Oh, what was your route into product?" "Ah, well I was working on this and then..."

  - I was training someone early this morning. He said, "Yeah, well, I was the technical lead on the product and the product manager left, and so now I'm filling the gap and yeah." Like, "Okay, well I'm glad that you're on a product management training course to try and figure out what it is then."

  - Yeah and like I said, there are an awful lot of people who sort of stumble into it by accident and then within a month or two they're like, "Ooh, this is interesting. I might stick around."

  - Yeah, I think that was my journey as well. So we've talked very much about product people and we talked about the audience and the purpose. Who owns and maintains that roadmap, though? Is it the product person or is it somebody else?

  - More often than not it's gonna be the product person because that is the person who collaborates most widely within most technology units that I see. Now, you're gonna get feed into that from an awful lot of different sources. The engineering team, the customer success team, the business execs are figuring out what their business strategy is, where they're trying to go. But typically it's the product manager that I see owning that in most cases, yeah. There's still a lot of businesses figuring out what shapes of team actually work best for them. And again, I don't think it's a static thing where all organisations have the same shape of team with the same ownership. I'm seeing some teams where one of the key parts of the collaboration is a product manager with a compliance and legal person as firms assess new markets to go into and figure out how they're gonna make it fly. And typically when you talk to a product manager and assess, "Who are you gonna be collaborating most?" Legal and compliance isn't often at the top of the list of things that people come up with.

  - No, no. In fact, it's usually the one that you think, begrudgingly, "Damn, I've gotta go and have a chat with them 'cause otherwise I've got a problem." But it's gonna be a bit of a pain.

  - Well, if you're building financial services apps and you're going into new markets, that's pretty crucial to get that one right.

  - Yeah, I remember actually one of my old team, he really, really, really wanted to know about contract law and intellectual property. So he wanted to get onto the legal side. It's like, "Okay, I'm more than happy to fund you on training to figure this stuff out 'cause I don't want to go any deeper than I already know. And if you wanna be my go to expert, that's perfect."

  - There are some cases where you see that actually making stronger product managers. I mean, I think there are cases where you get product people who've come from, as you say, that computer science or engineering kind of background, where they kind of keep hold of that and they feel like they're still the best person to come up with the solution and they lose sight of the fact that actually the product manager should be spending most of their time in the problem space defining the problem cleanly, defining what it is the user is looking to achieve with that. And then actually letting the engineers take an awful lot of that lead in terms of, "How are we gonna solve this? What kind of solution are we gonna build and how are we gonna do that?" 'Cause the engineers still have a lot of that knowledge and product people who've come from a computer science background might be moving a little bit away from some of that technology, might not be as up to date as once they were.

  - Oh, definitely a journey I went on. I mean, my challenge became even deeper 'cause I used to write some of the standards for ISO for example, so the International Standardisation Organisation that were for the things our products were ultimately going to implement. And so engineers naturally looked to me to bring the guidance of, "Well, how are we supposed to work with this?" It's like, "Well, I'm not gonna tell you that because you're the smart people. I want you to understand it yourself. I'm gonna take a step back. If you want to have a conversation in a conference room about how I would approach it, cool. Yeah, that's two humans collaborating, but that's not my job as a product manager. That's just me being a human that you can talk to."

  - Absolutely. Yeah, I think that that collaboration part of it is actually the bit that makes the role most enjoyable for a lot of the people that I speak to. That ability to say, "Well, this one I'm gonna work with marketing and sales and engineering and design. Let's get our heads around a whiteboard and see what we can come up with." And every team I speak to that are about to go into that, they're always energised by the opportunity to do that.

  - So I'm gonna circle back now you, you mentioned OKRs. Now, I guess there's maybe a slightly broader group of artefacts like vision, strategy, objectives. How do they all link into roadmaps in your perspective?

  - I mean, I was listening to a number of people in Hamburg earlier this week talking specifically- Or sorry, late last week, about OKRs particularly. One of the themes that kept coming up repeatedly was a key missing component, which is the initiatives part of things. So people talk about the company vision, they talk about the mission, they talk regularly enough about the objectives, they talk about the key results. "What does success look like? What's the thing we're looking to here?" They don't talk as much about the initiatives. What are the actual steps we're going to take in order to unlock that objective? And that's one of the ones where if you really get into the detail of and start breaking that stuff down, that's kind of intriguing. I think the other one to throw up is to actually flushing back a couple of weeks to the product tank we did in Lisbon, and one of the guys in the audience was talking about this idea of when you have your OKRs, how many is reasonable? How many is actually manageable? Now, you might take a sort of hard line purist view and say, "Well, priority is a word that works best in the singular rather than the plural. So when you start adding up multiple priorities, clearly none of them are the priority." So let's talk about that North Star. But this guy in the in the audience had a particular horror story that I wanna share and just put out there very briefly so that everybody's got this one clear in mind. He was talking about previous organisation where he worked for, where his team, not the company, just his team had 46 OKRs. That's how bad some people have got this. That's a point where this is absolutely killing your team. This is not proving helpful in any way whatsoever at that point.

  - I think we've gotta start calling that OKRitis or something like that. We've gotta coin a term for that.

  - Yeah.

  - Wow, yeah. 46 OKRs. How do I manage, remotely figure out how I'm driving any of those, nevermind which one to spend time or to focus on?

  - And again, so much time going into the documentation that actual progress made has gotta be minimal at that point.

  - Yeah.

  - Okay, so we've talked about OKRs in particular and OIKRs, I think I did see a post on that following Hamburg.

  - You would've done, yep. That was definitely called out on stage at one point.

  - Are there other artefacts that kind of link in or kind of relate to a product roadmap that we need to consider and how they relate?

  - I think the world in general and certainly the tech stacks available to product people now are getting an awful lot smarter on customer feedback, making it easier for customers to provide that, but then also providing sort of systems of growing intelligence in terms of how that's triaged and surfacing up the things that customers asked for most frequently or things that customers perceived might contribute most value to their experience. Now, you can't always trust what a customer tells you. You've gotta go do some validation with that, but I think that customer feedback is gonna become ever more important and ever more accessible over the next few years with some of the software that's being built at the moment. Our own Pendo teams are always standing, and there's a bunch of others out there as well, but some really interesting stuff happening there. And I think if you couple that with the backdrop of actually what's been going on in the last couple of years, you bearing in mind the the pandemic, the global economy changes that we have right now, the difficulties in travel that we're still having, I think it's fair to say that consumer behaviour has changed more in the last two years than it has in the last two decades. And yet we are further from our customers than we have ever been. It is more difficult for you now to get in a room with a group of your customers and watch what they're doing than it's ever been. So that customer feedback, that product data, the analytics data in terms of what's going on, what are customers doing, what are they trying to do, where are they falling out, where are they hitting problems with onboarding, where are most of your support tickets coming from, all of that stuff I think is growing in importance and feeding into the roadmap in terms of being able to add its voice to, "Actually maybe this bit's more important than we think" or, "This bit here isn't a new feature, but we are seeing an enormous amount of support tickets coming from it, so perhaps we should prioritise actually doing some work here, cutting the cost associated with that part of the product."

  - Yeah, and I mean heck, that flow of data suggests a whole growing skillset around data for product people, or at least having associated other, shall we say, disciplines like product analysts and so on to help us make sense of it.

  - Absolutely, I think one of the things that we've heard very, very strongly over the last couple of years is the growing importance of product ops. People who actually focus on the tool stack, the data, what we're collecting, how we're collecting it, who else within the organisation needs to see it, how we're going to empower them to not just get the data but then understand it, draw more useful, meaningful insights from it and go and action that. So those product ops teams are becoming more and more important, partially for the sheer amount of data and the value that it has, but also in terms of actually enabling the product managers to do what they do best, which is work more closely with customers, figure out what their problems are and how we can solve those most efficiently.

  - Yeah, totally agree. I mean, it's definitely a growing trend that I see a lot of power. In fact, I think back to my last team and I know who was doing the job, I just didn't have a title for it back in the day. So definitely something that was needed and you stumbled upon these things.

  - As I say, product is very much a nascent discipline still, it is very much evolving. And I think what we see over the last couple of years is the tool stack is evolving quite quickly with that. You wouldn't have found many people 10 years ago who had an idea of what product analytics was, let alone the idea of an engagement score or an online customer feedback portal that also had the ability to feed into your roadmap. These tool stacks are completely different. The idea of session replay tools being so readily accessible, again, this is new stuff within the last few years. And a product manager does not have the time to stay on top of all of that tooling integrated properly and then, "Okay, so we've got 17 different tools. They're all integrated through APIs. Tell me again which one was our single source of truth on that number?"

  - Yep.

  - So the importance of product jobs is becoming more and more so.

  - If I'm looking at a roadmap, and it's your roadmap, what are the key elements of content that you think should be on there?

  - I think it's less about the key elements and more about the changing granularity. So a lot of people look at the roadmap and they expect to see the next year or two. And what I find proves difficult with a lot of that is they expect a similar level of granularity throughout. Whereas what I tend to be looking for is to say you should see a vastly different level of granularity, the stuff that our team is working on over the next few months, absolutely. You should see real detail there. We should be able to talk to customers, we should be able to talk about what we're working on, how it's gonna impact them, maybe give them some loose idea of, "Yeah, this is in the near term, this is in the next couple of months, that sort of timeframe." But if there's stuff on there where we're talking a year or two out, we should be talking much more about the problem space more than anything else, not getting into that detail of how we're gonna solve it. 'Cause if it's two years out, chances are the exact nature of that problem is probably gonna change by the time we get there. So I think that's the most striking aspect of a good roadmap that actually takes a few people by surprise, is that you should expect to see that difference in granularity as you move through it.

  - And so there any, do you probably preferred way of trying to visualise that different granularity, different content?

  - I don't think a roadmap necessarily needs to be that complicated. It can be as simple as a Trello board, you know? It doesn't necessarily need to be huge. I think it's just that ability to show people what you're working on now versus where you think is going to be interesting further down the line. So give them an indication of the solutions that you're working on right now versus the problems that you think are gonna be interesting next. As I say, I've seen this laid out on whiteboards, Trello, Jira, there's half a dozen product roadmapping tools, all of which do an amazing job. So I think the, as I say, the tool that you use and the way you lay it out is actually slightly less important than making sure you're still holding true to those different levels of granularity.

  - Now, I might ask a controversial question here though. Do you have a preferred tool?

  - Ooh! I've used a number over my time. From a Mind The Product perspective, we work regularly with the likes of Pendo, ProdPad, Product Board. I think at the moment, the engineers are using ProdPad for a number of different things, but also experimenting with one other tool. So from my perspective I actually look more at how we've grown the team over the years and where we're going next in terms of our geographic locations. So the product tooling to me is actually less of interest. I don't get down in the detail of it. I'm more interested in saying, "Can you present me something that gives me confidence that we're working on and well into the detail of stuff right now, gives me a clear indication of where we think we might be going, what we think is interesting further down the line, and ideally, can you give me a version of that that you as the product person are comfortable I can take to a customer?" A lot of the time our customers are saying to us, "Where's Mind The Product going next? Are you going to a different location? Are you introducing a different type of training service? What are you doing?" Now, obviously there's some stuff on the roadmap which we know is questionable. We don't know much about it yet. We certainly don't know what kind of priority it is. So I don't wanna take the whole roadmap to a customer, but there's definitely instances where we're wanna say, "What can I show to a customer? What would you be comfortable with?" And I think that's probably one of the key areas where sales and product comes into conflict most often. 'Cause you see those hungry sales people, like, "I'm really keen to show the customer where we're going next. Oh, brilliant, a roadmap. I'll put that in front of a customer." And then you've got a product manager weeping tears of dismay back at the office, like, "Well, that wasn't ready to go external just yet."

  - But then on some levels, show that you can also, I guess, use it as a bit of a discovery tool to have that conversation with the customers to validate is it worth going there next or not.

  - Absolutely. No, I absolutely think that should be done. It just needs to be handled in the right way. And the best way that works is actually when you have sales and product working in partnership and you might have a salesperson saying, "This customer is so interested in this, can I show the roadmap? Can I tell 'em what we might be doing here?" That's an opportunity for our product person to say, "Actually, don't show 'em the full thing. Here's a little indication you can give them, and if they're interested in what's here, I'd love to jump on a call with them, talk through it in a little bit more detail" and then use that opportunity for customer discovery.

  - Yeah, I mean I used to have a framework I used, I called it "Ready to Listen, Ready to talk, Ready to Tell," which was kind of the, "Okay, 'Ready to Listen' is we think this is interesting. Salespeople out there, I'm gonna expose you to it, go and listen for this. If you hear anything relating to it, get that name on the list. I want to be in the room with them soon. That's the time to talk. We're gonna have just an open conversation." And then "Time to Tell" is, "Okay, now we've spoken to a few people, can we play it back to you and see if we're still in the right ballpark for you?"

  - Yeah, no, I love that. I've not heard that particular breakdown before, but that's great.

  - One of my old colleagues in Vodafone, he used to use a simple red, amber, green code for a very similar sort of thought process.

  - Yeah, that's beautifully simple. I mean, you know as well as I do, salespeople are often, they're chasing their tails, they're incredibly busy, they've always got their number hit and that's the thing that's most important to them. So if you can make it really, really simple, "This is our framework, this is how we do it, you've got that clear." That's great. Love it. I'll be stealing that at some point, I assure you.

  - Yeah, I just try to avoid greens. One in 15 males is in the West is like red/green colorblind. So I try to avoid red, amber, green colour codes wherever I can these days.

  - Fair enough. Yeah.

  - 'Cause it can be a problem. So okay, best practise on roadmap. I think you've kind of almost distilled it in a second ago, kind of how you judge a good roadmap. But is there anything else you wanna say on what is best practise for roadmapping?

  - Yeah, don't yield to the pressure to put dates on there. There are some instances where you need a date on a roadmap. And by way of example, I would say occasionally regulation changes in banking and you need to change a feature in order to comply with the law. Yes, that needs a date. Your engineering resource needs to be crystal clear on when that needs to be shipped by, and ideally some room in there for testing and improvements as needed. But by and large, roadmaps shouldn't have dates on them because the vast majority of the time, even when that first early release goes out the door, that's still a learning opportunity. You're putting the thing in front of the customer for the first time. Chances are it's a long way from done. So this is why I'd lean towards that cadence of saying severe granularity on the stuff that you're working on near term, but less and less granularity as you move further away. And don't put dates on there. You might well say, "Towards the end of the year, we expect to be getting towards this problem." Cool. So you're saying latter half of the year. You're not saying, "In November, we'll be working on this" because if you say, "In November, we are working on this," somebody somewhere is gonna hold you to that. Now, you know as well as I do just how much stuff changes. Now, I was having a conversation with somebody recently and we managed to reframe it in a way that was a lot more comfortable for them in their organisation. He said, "My CFO, me CEO keep insisting that I put date on a roadmap. 'When are we gonna ship this feature? When are we gonna ship that feature?'" So we flipped your around the other way and said, "There's two questions I'd love for you to go back and ask your exec. Firstly, are they able to guarantee you that the engineering team you have right now is going to be exactly the same in nine and some? There's a lot of people resigning and changing jobs right now. If you lose three engineers in the next six months, does that change your ability to deliver?" "Well yeah, of course it does." "Cool, well, if your exec recognises that that is a legitimate possibility, maybe putting a hard date on there isn't the wisest thing. Now, let's go and have a chat with our revenue and sales side of things. Have they given you a 100% cast iron promise that that is the number they'll hit at the end of the year?" "No. They've told us they expect to hit that. That's their target. But we also build in a certain amount of contingency 'cause it may or may not be happening." "Right, so by saying you expect to be working on this by then, but you can't necessarily commit to exactly when it would ship, you are asking for no more or less freedom than other people in the organisation."

  - Yeah, yeah, true. I've not heard it put that way, and that's really actually, yeah, it's quite a nice way of being able to challenge back, but in a respectful way as well. 'Cause that's often the challenge. It's like you want to challenge back and push back, but sometimes it just almost comes across as petulant and you're trying to find that respectful way of doing it.

  - I think with product people particularly, it's very much a case of winning hearts and minds. So if you can tell stories around what you are trying to achieve and why, but also point to data points of, "People in other teams do it this way." Okay, well now we're talking sort of a bit of emotion and a bit of logic. That's a better way of winning the battle and it's a little bit more respectful than just saying, "But I wanna do it this way because." No, no, no, let's give people sort framing as to why.

  - It's almost like the Amazon model of bringing data and anecdotes. You bring both sides to it.

  - Absolutely. Yeah. 100% agree.

  - Now, we've talked about best practise, now let's go the other side. What about the biggest mistakes or biggest anti patterns you see on a roadmap?

  - I mean, the two obvious ones to call out are firstly putting dates on there when you don't need to. Try to stay away from that, and then secondly, getting granular too soon. Like, "We think we might be working on this in six months time." Cool, that's probably enough. You might know more or you might have a hunch about where you think that's gonna go, but the moment you put that in black and white, again, somebody's gonna try and hold you to that. When you're starting to look further into the distance, put the minimum amount necessary to facilitate a conversation. Once you start going beyond that, you're starting to make things public that you may not wanna be held to.

  - I love that phrase there. Facilitate a conversation. It's one I use regularly. It's like, I often consider that's the product manager's job is to facilitate the conversation in the organisation that ultimately leads everyone to the same conclusions, and therefore delivering.

  - I would say there's two key points to it. First, it's to facilitate that conversation. Absolutely. And that happens throughout the organisation and externally as well. The second point then, and one of the descriptions of product management that I love most, fundamentally it's decision making as a service.

  - And lots of micro decisions. But then there's the argument, the counter argument there. Does that mean that people are not kind of also choosing to not make decisions and they're just kind of giving over and saying, "Product, I don't know the answer, you decide for me" when maybe we should be actually insisting on them taking more empowerment to actually make some more decisions themselves in a frame.

  - We can, but we have to give them good principles and good rubrics by which to make those decisions. And the opening keynote in Hamburg last week that Martin Erickson talking specifically about the decision stack, how you give people principles against which they can go make those decisions. And I know that's something he's planning a fair amount we work on over the next year or two, but by doing that, you empower your team to say, "Okay, I know the basis on which we make our decisions. So if I can evaluate this current issue against this rubric, I now can take a decision quickly. I can do so autonomously and I can do so with confidence." So as a product manager, you don't have to make all those decisions, but you can create the environment to empower your team to do that.

  - I generally talk about a good strategy is a plan, a great strategy is a framework, and I mean the framework provides that context, the guard rails, the things for people to make those decisions. So I think it's very much in the same sort of same perspective. Perfect.

  - And that decision framework can be some fairly simple, very, very high level stuff as well. It doesn't necessarily all need to be down in the details. One of of the ones that we drove through Mind The Product very, very early on was a core value of the customer breaks the tie. And the idea behind that is very, very simply if you're stuck with a question and you're not sure which way to go on it, what would the customer want us to do? That is almost certainly going to be the right thing.

  - Yeah, I remember one I had in a product many years ago was if we can get the data without asking the customer, get it that way.

  - Yeah, absolutely!

  - Let's not put friction in the process for them. I guess it's more of a UX or design principle, but it was something I wanted to get across to the entire product team because they were building in these complex forms for people to kind of fill in as they onboarded with the product. It's like, do we want people to just fail in onboarding?

  - Absolutely, and as I say, you're seeing more and more enhanced tool sets now that support this in various different ways, whether it's gathering analytics for inside the app or popping up little pointers in just the right way to smooth that onboarding, which I think is gonna make all the world of difference, particularly to finance product offerings over the next few years, where they're getting more and more complex with know your customer and anti-money laundering and things like that, and consumers are struggling more and more with it. This tooling of, "Here's where the support tickets come from, here's where people fall out, here's where we can add a tip in to help guide them through." This is all stuff that we can improve the experience without ever asking the customer.

  - Okay, so we've explored quite a few subjects here and my next question is really, I think you've named a few people as we've gone along, but who in particular's advice do you listen to when you're thinking about roadmapping?

  - I'd call out the top two as being Janna Bastow and C Todd Lombardo based over in Boston. C Todd was one of the authors of "Roadmaps Relaunched". Brilliant book on roadmapping. He's spoken on the Mind The Product stage a couple of times, and always does so with a sort of energy that lights people up and gets them interested in the topic again, but is just absolutely full of solid tactical advice. "Here's how you can make your day to day life as a product manager better." So he's absolutely worth listening to.

  - Perfect, and funny enough, a previous guest and a future guest that's already booked mentioned there, so that's perfect.

  - Excellent.

  - And okay, so going beyond that then in terms of resources that you might look at, I guess the book by C Todd and Bruce McCarthy and co. is gonna be on that list, but anything else you look at?

  - I think probably the one that I love here is kind of that core part of where Mind The Product came from originally, which is this strong belief that there's not necessarily one right way to do product. There are lots and lots of different right ways and also lot of horrible mistakes. So our effort over the last 10 years has largely been focused around going into the community and finding the best stories we can from product people around the world in startups, in enterprise, in banking, in mobile apps, in gaming, in travel. And then we either get 'em as guest posts on the site or podcast interviews or as videos from the Product Tank meetups, and we make as many of them available on the site as possible. So what I'd say to people is go on search and search for roadmapping and key terms that are relevant to you, whether it's finance or compliance or banking. Find someone to talk about roadmapping that's actually really relevant to you. I am almost certain we've got a story up there that will help almost anybody. But listen to people in your industry. Listen to people who have similar challenges 'cause the chances are whatever you're dealing with right now, somebody somewhere has had a crack at that before. So don't reinvent the wheel, try not to make the same mistakes as them, go be a product manager, make a whole new set of mistakes all of your own, and then come back and tell us about those too.

  - Sounds great advice. And yeah, I mean, I guess I would say look at the people in the other industries that have had the same problems as well though, because there's sometimes that insight that you can bring across industry that just solves a problem that you've been stumbling on.

  - Absolutely. Yeah, I was having this question about that sort of cost pollination a couple of days ago. Somebody was saying, "Could you do product events that are just for startups or product events that are just for enterprise?" Well, a lot of enterprise organisations come talk to us because they've forgotten how to innovate, which is what startups are great at. And a lot of startups come talk to us because they're struggling with scale, which is what the enterprise has nailed. So putting those two groups in the same room together is exactly the right thing to do! That's absolutely about taking those lessons wherever you can and figuring out how you can apply that to your current situation. Not necessarily saying, "I can only take a lesson from somebody in my country who's working in the same problem in the same vertical with the same tech stack." Not at all, you can take lessons from a variety of different places. As I said, that's very much the core ethos of a lot of the content that we make available.

  - I always like to ask the hard question towards the end, which is if you had to distil your philosophy on roadmapping down into one or two sentences, what would it be?

  - I'm gonna repeat the line about using it as a prototype for your strategy. I think that's actually crucial to having a roadmap that is so much more valuable to your business. And then secondly, remember that it's almost never gonna survive contact with reality. Somebody was misquoting Tyson at a meetup to me recently in Berlin and was saying, "Everybody's got a framework until they get punched in the face." Your roadmap is going to get punched in the face. Do not get emotionally attached to it. Expect a customer to pick it up and say, "That doesn't solve my problem. I'm no longer interested." Or an exec saying, "This is taking this way off piece. That might be interesting, but I have an issue with that." You should expect your roadmap to get beat up. Don't take it personally. That's an opportunity to learn.

  - Although I have to say, even Tyson was just paraphrasing. It was von Moltke the Elder, a Prussian general from the 1800s that said, "No battle plan survives contact with the enemy." The original quote, at least the one the earliest one I know of.

  - Oh, beautiful. I think the product people, we do sort of deeply invest in what we do. We deeply attach ourselves to our products, to our roadmaps. And I think people just need that little bit of a reminder of, again, step back, it's not a personal attack on you, treat it as an opportunity.

  - Well, I think we call some of our own faults. We call the product our baby. We talk about taking it cradle to grave. Well, I don't wanna kill my baby. I wanna look after it and nurture it and grow it, and sometimes actually I think we've gotta maybe think of it more like livestock perhaps. We're rearing it, we're taking it on a journey, and I guess for the vegans out there and the vegetarians out there, maybe not the the best analogy, but at some point it's probably gonna be slaughtered.

  - Yeah, that's fair enough. I mean, as I said, they do all have a limited lifespan. Very few products live forever. And actually some of my favourite talks over the years from Mind The Product type stuff has been people saying, "We've got zombie products. Let's talk about how we decide what to execute." And we've got some great talks up on the site about that side of things. And again, that's the kind of thing where if you can be aggressive about making those choices, it can then free up the resource and the energy to go and do something that might have way more strategic value for you.

  - Okay, last question for you James. What should I have asked you about roadmapping that I didn't?

  - I think there's something in there, which firms actually do a great job of sharing roadmaps publicly. I think you see a lot of software examples of roadmaps, a lot of vendors sharing webinars or templates, screenshots and things like that. One of the things I'm on the lookout for is customers who do a great job of putting their roadmap in public. Sharing that with their audience, sharing that with the customers. So yeah, let's ask that some more in future and let's start encouraging a few more companies to be a little bit more public.

  - Last few seconds, pitch Mind The Product, pitch Pendo. What can people get? How can they find you and how can they get help? What can you help them with?

  - Mind The Product is obviously the community conferences training business. We focus on sharing stories and helping people to level up, bringing product managers together to further the craft. And Pendo is obviously the world's leading product experience platform right now, whether it's analytics or engagement or whatever. Fundamentally, my role for both organisations now is that of an evangelist. I'm here to help raise the value of product management generally. Help people to understand where it's valuable, where it can help, and wherever possible, help connect the people behind it. So if people want connections to advisors, whether they're interested in software, meet up training, whatever it might be, just feel free to reach out and I will help connect you to whatever I can that makes your life better.

  - Thanks, James. And we'll make sure that some links below and things like that so that people can find you and so on. James, really have appreciated your time, the discussion today. It's been insightful bringing all sorts of different sort of perspectives. And what I love is you've been in so many of these product communities to kind of bring in all the different perspectives and kind of gather some of those many thoughts together as well, and almost curate some of those answers. It's wonderful. Please, to everyone out there, do like, subscribe, share, all those good things, follow the channel so that we can hopefully bring you more and more content going forward. And if you're interested in getting in touch and taking part, please to get in touch. We'd love to talk to you. James, thank you you very much for today.

  - My pleasure. Take care.