Do you have everything you need upstream of your roadmap? | Dave Martin
In episode 23 of Talking Roadmaps, Dave Martin and Phil Hornby discusses the critical elements needed upstream of a roadmap. He emphasizes the importance of communication and alignment, shares insights on his role as a fractional CPO, and highlights the concept of a roadmap as a "prototype of your strategy." Dave also talks about his experiences with companies like Contentful and Adobe, offering practical advice for product leaders and early-stage businesses.
Dave is Founder of RighToLeft and the creator of the Product VCP. He coaches leaders to scale products and lead effective product management functions. He is trusted by leaders from scale-ups and large companies such as Evotix, Adobe, GitLab, Synk, MentionMe, Contentful, BT, Rotageek and many more.
Dave is a qualified executive coach with over 2 decades of experience in product leadership. In CPO roles, Dave has exited multiple SaaS businesses, including a 9 figure revenue company.
His experience includes leadership roles working on products for Google, CompareTheMarket, Tes Global, ThoughtWorks, PepsiCo, Bauer Media, Adobe and various startups. He also has book coming out soon with a previous guest Andrea Saez, look out for the Product Momentum Gap.
“Most companies have a missing piece upstream of the roadmap to know if it is any good”
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).
Next up we have Michael Morris who’s Head of Product at TrueLayer. So watch out for Episode 24!
-
- Welcome to "Talking Roadmaps" everyone, the channel where we talk about the good, the bad, and the ugly of roadmapping. Today I'm joined by Dave Martin. Dave, introduce yourself for us please.
- I'm a product leader coach, I spend most of my time helping product leaders and founders of early stage businesses learning how to scale up and get their product function working brilliantly. And, you know, the road mapping piece when you invited me on is such a key part of that. So I'm super stoked for today's chat.
- I think I saw the phrase fractional CPO on your LinkedIn.
- You did. Yeah, you did. I always have been nervous since I started being the coach and consultant that, you know, I've become one of those people that no longer knew how to do the job. So I always have a fractional role and that means part-time and interim. I was fractional CPO for Contentful for the last year and a half, but we sold it in November to Adobe and we've just finished that transition into the Adobe world. So I'm rolling off that and now just joined an exciting business called General Systems doing some amazing data infrastructure work with Geospace time stuff.
- We'd love it if you, you know, hit that whole like, subscribe and bell icon to follow us. So, I mean, let's get straight into it. What is the purpose of a roadmap in your opinion?
- The number one most important thing has to be communication, communication and alignment. Those two things, without the roadmap won't happen. While many other things the roadmap can do can still happen without it, we won't get visibility, communication and alignment.
- You hit on some others. Maybe you could unpack a few more of the other purposes.
- Yeah. There's a phrase I didn't make it up for sure. I think I heard Janna Bastow say it first, and she used the phrase, "It's a prototype of your strategy." And I love that phrase. I think it works so very well. The challenge with that, though, is that most companies don't have their strategy articulated in a way that would allow you to know if the roadmap was a good or bad prototype. So I totally agree it should be the prototype of the strategy, but most companies have a piece missing upstream of the roadmap in order to make that work.
- I was asked for some advice on running a road mapping workshop, a really short one yesterday, and my first reaction was, well, have you got X, Y, Z like vision strategy, clear problems to address your objectives, how you're gonna be measured? Are they in place because if not, you've got no chance of doing a short session and actually having any value. But like I said, if we're communicating and aligning, who is it for?
- For the business first I mean, a lot of people show the roadmap outside of the company externally as a marketing tool. And that's awesome and I love it when companies do that, but remember that is a marketing asset at that point. And we predominantly and product don't want to, we're not marketers specifically. Our job is to align the business and make sure we build the right thing and create the most valuable outcome towards our goals with the limited resources we all possess. So I don't like the idea of the roadmap becoming an external asset. Primarily we're gonna remember it's an internal tool to help our business inside the organisation. But if our marketing teams can do a wonderful job of using it externally, then I see even more value from the same thing.
- If we're articulating internally and perhaps, you know, marketing and remixing externally, who owns it, though, and who maintains it?
- A roadmap is definitely a product responsibility. Our accountability is are we building the right thing? Are we generating enough value for the business? And the roadmap is clearly helping identify what we think is the most valuable next thing for us to do in an order of priority. And that's why it's a living document. That's why it shouldn't be so static, which is always a little tricky when it becomes a hard and fast marketing asset that's committing you to things externally for a long time in the future. Because we've gotta predominantly remember that as we learn about those problem spaces and progress, our learning should change our understanding and there's a very high probability then that's gonna mean the thing we thought was the most valuable next thing to build isn't the most valuable, right, next thing to build. In that instance, we have to be empowered for the roadmap to be flexible for us to change it. And whether it's committing to using it to commit to investors for the next 18 months worth of resources or using it to commit to external customers of what we're gonna build, both, as long as the commitment is fluid, we're okay.
- Well, if in six months' time we still deliver what was exactly on the roadmap, then either we're gonna disappoint the customers because it wasn't what they're really wanting, what we guessed or we're just not learning I guess is the other risk which happens in many organisations. So, I mean, you already started hinting at it, so it feels like it's a specialist area. Vision, strategy, objectives, how do they link into road mapping?
- Yeah, I mean that space is definitely the area, you know, my company RightToLeft working in the most as the space we help organisations with. And I think the key there is that, you know, especially smaller businesses like series A businesses, VC backed series A and series B, they're often a single product business. So what I hear a lot is, "Oh, we don't need a product vision because it's our business vision is our product vision." And whilst that's true that the business vision of a single product business will stray into the product side, what it regularly doesn't do is provide the important experiences that we expect our product to deliver, the best product visions, not business visions, but product visions, which I prefer to call product concepts just to differentiate from business lingo. The best product concepts are describing the experience we want for our customers and different personas within that, whether that's the end user or whether that's the company that pays for it in B2B specifically. So we need a clear product concept that really does articulate the experience we're trying to aim for, not just, you know, hard KPIs or market share percentages and all that lovely stuff that you'd expect in the business strategy. From there we normally go, we see companies go straight to the roadmap, what's the objectives we're gonna do? And that's where I think the mistake happens quite a lot. We need that strategy piece first. And the strategy has gotta define how we're gonna deliver this value of which many would argue the roadmap articulates that, but better where we found more value is articulating that strategy as something called the product VCP, the product value creation plan and the product value creation plan, it's a lot of words, but it's super simple really. We look at, especially in B2B software, we look at what is the behaviour we're gonna change for the user because at the end of the day, all the product, all every time we ship a release, which is actually what we end up doing when we create value, we change the behaviour of a user. That's what what we do. So we focus on what's the behaviours of users we're changing or could change to achieve that experience. And then we focus very much on how do those behaviours being changed impact the paying customer in a B2B software. That's our first value assumption. And then we focus on how does creating that value for the customer create value for us as a business. And that's our second set of value assumptions. So we think about those two sets of value assumptions and we define them, we write them down, we collaborate on creating them, we go and validate them if need be. We get really high confidence and alignment on those value assumptions. When that's in place and we've got that across a wide ordinance sector of the business, especially across the C-suite and leadership, we've reached a point where we can now say, well, if we all have agreed those key value assumptions and we know that they're the right thing to do and that's how the product will generate value for the business and for the user and customer, we can now focus instead of on the value end, the business KPIs, which are always laggy, incredibly interfered with from, you know, lots of interference, hard to understand attribution of what's actually made them go up or down, very difficult to measure. We can now just focus on some value indicators around those user behaviours because we've agreed that those user behaviours are gonna equal value at some point to us. With that in place, we can now look at building our roadmap because now we've got some value indicators that describe how we want to change user behaviour to impact the business that we know generators, the goals hit our strategic goals that we're trying to hit. So now value is no longer ambiguous, value is now very concrete how product creates value and they're typically leading metrics naturally because user behaviours are normally leading metrics and we now have a plan to build that roadmap against. So now we can look at our efforts around the roadmap, that was the right next best thing. And when we have that typical value effort conversation everybody has for value, for strategic bets they're gonna put on the roadmap. Now the word value isn't ambiguous. Now the word value is very concrete and strategic and we've removed bias, quite a lot of bias from the phrase value. So when we are looking at value now we can go, how does this strategic bet impact the VCP rather than let's have a discussion about its value. And what happens there, of course, is salespeople who are professionals are articulating value. That's their job. If they can't articulate value, they will never sell something. They obviously will have strong bias in those conversations without the VCP simply because they're extremely good at articulating value, nothing else. So we have to, with our VCP in place and clear definition of value in a way that product can actually impact, now we can look at our roadmap and really evaluate and view it as a prototype of strategy and we're prototyping it against these VCP numbers going down.
- I love that whole kind of flow that you just articulated there. I'm gonna have to watch this back myself and kind of dig into it and kind of step by step, how do I take myself down that path, the product concept as an alternative in the main literature to product vision. Yeah, I can see how that would work. And because it was always a battle to almost even at a business unit level in some places get a vision in place because, "Oh, we don't need it. Let's just execute."
- I mean, we have to recognise that the tools I've just described, you've gotta be a business that wants to be a product business, you know, and that is the first challenge. The space we work with quite a lot where we see this tool fly, you know, really generate value is where companies are at that pivotal point where their product leadership is growing like a series A business, whether it's their first head of product or their first CPO in place. And they've been used to making those decisions and that vision and all of that used to be the founder and in the founder's head and they were probably doing that very effectively, but that doesn't scale obviously because it's from one person's head. So you see this point regularly where when a company tries to scale this product function, growth continues. So we feel good, but it's actually average growth, it's not high growth. And we see this point and we call it the growth scale ambush where at some point you suddenly realise you're not scaling it anywhere near the pace you wanted. You thought you were, but you're not because it's bit like a trojan horse almost. You've had this average growth for so long and then you look and go, wow, we're celebrating those short-term wins, but we're not getting anywhere near exponential high growth. And it's often because the prioritisation of what we're building is suddenly become marked client fit, it's not market fit. We're trying to support gain big deals over the table, especially in B2B versus the take market share. So the VCP helps at that point to ensure we stop making client fit decisions and get back to making strategic market fit decisions.
- I'm sure there's some downstream artefacts that are linked into a roadmap as well.
- My favourite view is Sabrina, you hear Marty talk about it, Marty Cagan talks about the roadmap is really a set of objectives for potential OKRs. The idea that their big strategic bets on the roadmap and we're gonna use those downstream to drive our teams with targets and goals. Whatever framework you are obsessed with, whether it's OKRs or something else. I'm not religious about any of this stuff, but the fact that you are using the roadmap directly to drive its outcomes on the roadmap and you are using those to drive the targets for teams to deliver for those cross-functional teams that way we're ensuring that the teams are working on the right things that it's strategic, everyone's got visibility of it. We've prioritised that roadmap using the VCP so we know it's strategically prioritised, not overly tactical, but which happens by mistake quite often. And the teams, therefore, are then on the most important valuable things and they can see how the value maps so they can be more empowered. As soon as we start to drive, we make sure that we aren't mistakenly giving the teams the solution too quickly, solutionizing too early. And we have to make sure we aren't using the roadmap to solutionize too early and dictate to the teams because we need them. If we want them to be empowered and we want them to innovate and do things in the marketplace that is game changing then and be bold, then we need them to have that space.
- So let's switch gears a little bit and let's think about the design of the roadmap, what goes into it. So what in your perspective are the key elements that go onto a roadmap?
- I think it depends, obviously we talked about how it's been used downstream and what I typically, when I'm in these fractional roles, we'll have more than one version of the roadmap, more than one view of it. I will definitely have one view, almost one export of the roadmap, if you like, that is high level, doesn't show work streams. It shows the big things we're trying to achieve that I'm using at board level for big strategic conversations and for, you know, obviously creating confidence that we're spending the money in the right way and for getting more money. I mean, as we go we wanna reshape the roadmap that's a bit more work stream orientated so we can, our teams can identify where they fit on it and hopefully that's around big themes and really it would depend I think on the topology of our business, depending how we're structured. I see some teams where their topology is all about the users or some others where it's about the one I hate the most, where it's about the tech, but then others will be about parts of the journey or business goals. So however that is articulated, shaped, we wanna make reflect that in the roadmap so that individuals understand where they sit in it when they look at it not otherwise it's really hard for anybody to, it doesn't create the alignment. I can't look at it and go, "Oh, this is how I contribute to this thing." I think that's important internally, less so, of course, for investors or as marketing are gonna reshape it to go out the door. We get rid of all of that. I think that we want, what I'm really keen on is that we don't have dates on the roadmap. Now, that doesn't mean we shouldn't as product be beholden to dates, dates in the world of our world and product engineering is effectively how much money we spend and we should be accountable for how much money we spend to deliver an outcome. That's perfectly fair and perfectly understandable that the business and the investors, decision makers, at these want to have an idea of how much cash they're gonna have to throw in to get the outcome. You know, we wouldn't build a house without knowing how much personally, without knowing how much we're gonna cost us. We wouldn't just say to the builder, "Well, I'd like this beautiful house, but keep building it until you've reached there and I'll just pay the bill." Of course, we wouldn't. So it is fair and correct that we have that planning process, but I think the important thing is that's not the roadmap's job. That's the job of a release plan and that's why we should keep the two very separate and not confuse them. A release schedule is a document that is where we are able to commit to when we think things will end and more detail over what it is, more detail over features. Where on the roadmap, we're articulating the problems we're trying to solve and the value we're trying to create and in much order part is so that they're, you know, the typical now, next, later approach works perfectly for that. And that's the approach I always use.
- But I do want to probe. Are there ever any times that you would include a date on a roadmap?
- Yeah, there is. When I'm working in FCA regulated organisations and there's hard compliance dates, I'm quite comfortable not putting the date on the roadmap as a commitment, but putting the date on the roadmap as a constraint so that we're all very clear. Like, you know, we might, I've worked in organisations where we had to go through certain compliance changes with especially finance, you know, and there are certain outcomes that must happen by a particular date or we're gonna, we've decided that we're not willing to take the risk of being illegal, you know, which is it's a business risk decision all on its own. So, you know, typically we do wanna be compliant and I think that those things, it's important the date is there so we understand that when we're making priority decisions and everyone's aware of it. But probably that would be the only one where I'd be comfortable having where the date is properly truly hard and fast.
- Yeah, it's those hard externally driven dates sounded like not the commercially ordeal driven dates, though.
- No, most definitely not the commercially deal driven dates. I mean, and that's what the release schedule is for. That's exactly what the release schedule is for. I think the other thing that I'm, and I'd love hear what you think, I'm not a fan of tactical items being on the roadmap, and I see some companies try and do that and I see no point in it. Personally for me if we've got BAU work, I'd rather us manage that separately and be very clear about the two, like some companies will have, you know, onboarding customer X, that's BAU, that's business as usual. That doesn't have a place on a product development roadmap. If we need a schedule and there are things that are projects like onboarding a new customer, supporting a new feed for this customer, getting them live, training them, all that jazz, that is a project and I don't see the need to mix the two up. All it means is when we're planning, we know we have less resources during that period and that's gonna impact the speed that we get through items on the roadmap. It's not gonna change the order of priority on the roadmap.
- I can imagine some scenarios, you said you're interested in my perspective, for example, when it says first 10 enterprise customers, maybe where actually it's so strategically important and all about our product market fits. So maybe I could imagine aligning some of that and that early adopter stuff there. Maybe just for the, again, you talked about different views, maybe there is a view that has a bit more of that tactical stuff kind of almost annotated on it. Not necessarily saying it's part of the roadmap but kind of annotated around it for context. I can imagine for the operational development team internally that guess would be my thought there.
- Yeah, I could definitely buy into where, like you mentioned the top, the first 10 enterprise clients, et cetera, you know where you are actually the roadmap item is about being able to support enterprise clients rather than, you know, the thing we're doing there is improving our processes and capabilities and features so that those enterprise clients can buy us. That's a market fit thing. There's probably more detail I'd hope than, but that there may or may not be needed depending on the level granularity. And that's always I think a tricky thing, how granular the roadmap goes. That's always hard. And I think that's down to the maturity of the teams. If you've got mature product teams to execute, you can have broad guides, broad guides on the roadmap. If you've got less mature teams in working, then you're gonna have to have narrower guides and that's a leadership decision of how broad or narrow they want to go. We don't wanna get so narrow we're dictating solution, but the roadmap does provide us, so the OKRs and all these mechanisms, they provide leadership, a way to give guardrails to their product teams to help make sure they're going to support them going the right direction and support them working on the right things. So I think where it needs to be more granular if the guardrails need to be more narrow, which is the case when you've got young teams, teams with lots of people where there's a lack of IQ about the technology or a lack of IQ about the business, the domain expertise for example, but, or a lack of, you know, they haven't been working well together yet. They haven't got their stream, et cetera, they haven't got into their rhythm, but when they're more mature and the teams are working well together, then they can be much broader.
- What about how you visualise things on that roadmap then? Any favourite approaches there?
- I have to admit I'm a little bit biassed. I use a product called ProdPad pretty much exclusively, you know, I mean I've known Janna, the founder of ProdPad for a very long time. I've known her since she worked with me, the company before she started it and her next venture after she left was indeed to make ProdPad not a prototype tool that we were using, but a full-fledged business. So I always use ProdPad and so the way that visualises it is nice. I like the exports where you can easily reduce or increase granularity of information or include objectives or exclude them and themes, some of the annotation you just mentioned and it's never a Gantt chart, it's always 9 weeks later. Similarly the product tend to favour the old Gantt chart, which I refuse to use. So I have to go back to ProdPad. So I guess that's the true visualisation. I think the next thing is the actual words and they've gotta be, you know, my view, we've gotta make sure those words that we're putting on there are outcomes rather than exact features unless we're very concrete, very, very confident about the feature, then it can be a feature. If we're so confident it has to be this, it's so obvious this is the solution, but and there are places and times when that's the case, but normally it's an outcome and I'd like to try and make sure we get those words in an inspiring way that's inspiring people to wanna solve the problem rather than, you know, dry boring grey context. We want something that inspires me. I'm gonna remember that at the end of the day, if we're helping change the behaviour of users that we talked about earlier, that means in some way we're helping improve their lives. Whether it can be very bold how, you know, if you're a health tech road tech business, you know, you can be changing lives in a very bold way, but if you are a, whatever tool it is and you create whatever product, you're improving somebody's life some way. So if we can try and make that roadmap inspiring to read, then that's a win.
- So what do you think is best practise on a roadmap?
- I think best practise has gotta be keep it simple, clear, easy to understand. We wanna avoid heaps of business lingo and complicated words. You know, we wanna write it stupid simple and we've gotta remember that it's fluid, that it is not, this isn't stone.
- Okay, now let's go the opposite way. What about the biggest mistakes or anti patterns you see on a roadmap?
- You wanna avoid hard dates all over the roadmap that are fictitious and not true hard dates. I think that's a huge challenge. We're gonna try and avoid the roadmap being a wish list, just a list of features that we've already decided are not gonna solve the problem. I'm not sure who's decided that if it's done straight off the roadmap and how, which is obviously a mistake. In other words, it's normally the exec team, some leadership group in a room somewhere have gone, we should build all this stuff, it'll change our direction of travel and that's most certainly gonna fail. So keeping it, helping encourage leadership by having a roadmap with outcomes. When the roadmap is just a list of customer requests and there are a few businesses I come across where, you know, CS get requests, Customer Success get requests for new features or sales get requests during the process for new features and all of the roadmap priority processes is how do we order these new requests? Not should we build these requests, not how is this gonna help us actually generate a future income which is most valuable for us or the business or the companies we're serving or the users we're serving, just how do we put them in an order. And when the roadmap just becomes a list of feature requests from customers directly with no value addition in the middle, then we know again that there's no point in having a product team. We're just a requirements gathering function like in a project management function and a PMO function. And the worst outcome of that, which is the typical one in B2B software is it means we're gonna end up writing lots of lines of code that is only gonna get one X value, it's only get the value from one customer rather than us selling it to 10 customers. It's the same companies that when you go back a year later and try and put product analytics in, you learn that most of the features are either used by nobody or only ever used by one client.
- Or even worse one user in that one client.
- Yeah, perfect. Yeah. Yes. Yeah. In other words, yeah. And that there, that leads us to a place where product has failed because we're not getting an ROI on the product engineering investment. We're not a very big one. And that's a game when we get stuck in that average growth, we can see, we can still grow year in year as an organisation and deliver value to the shareholders, but it's average, it's just linear growth. And any tech business at that early stage where we were with them series A, series B, you know, the promises they made to their investors was never, I never seen a pitch deck that just showed a linear line for revenue. It's always a healthy stick.
- Now, I always like that what's your pet hate to see on a roadmap? Then that's, you know, getting even worse.
- I see quite a few of these documents in different startups and different organisations and I think there's two, two key pet hates. The one is where it just looks like another business document that doesn't really reflect what the product team can impact. You know, where, for example, outcomes on it, they've tried to do a good job and put outcomes on, but the outcome they've written is so broad and so hard for product to directly relate to. In other words, it's not meaningful, it's not useful. And so too much high level such as, you know, make market share 20% higher. How am I gonna do that? It's a little too high level and then on the other end, even though I hate the dates thing, which I can put up with it, but I can't put up with the features being so that the solutionizing happening up front. It's the solutions that are really that really grate me, the dates I can cope with. If the business hasn't really made it yet to being a product organisation and is still thinking project, then fair enough. They're on journey and a transition. But when we've said in three years' time we're gonna build this widget, it's just complete bs. It's just like, "Well, how in earth do you know that now?" That's rubbish. And the problem with it in those organisations that are on that transition and it's normally businesses that've got the data who would know it's three years time, on those organisations that are in that mindset and on that journey from project to product or maybe a better phrase is from client to market, stop thinking about the client and start thinking about markets. Then if the features are listed out in such granularity and such clarity for so long and so concrete so far ahead, it just shows that the product function is pointless. It may as well not exist because we've already committed to what we're gonna build, whether it's the right or wrong thing. So I don't really know what a product team is doing in those organisations.
- Just thinking about, you know, we've been listening to your advice, your thoughts, who advice do you listen to about roadmapping?
- Oh, great question. You know what? I listen to everybody's advice to start with, I think, and that includes customers I work with and, you know, everybody. You're always learning and there's an opportunity from everybody to pick up some new nugget, an exciting thing. I've mentioned Janna a few times, she's probably my go-to person when I'm thinking about roadmapping challenges. Yeah, in fact, she definitely is. She's my go-to personnel roadmapping always. We'll check in to see what Pagan's views are at some point for sure. And Petra in Hamburg, who the author is strong, she's got great views, great experience, always great to chat with her.
- Now, the hardball question. If you had to distil your philosophy on roadmapping down to one or two sentences, what would it be?
- It's a prototype of strategy, a sentence one. Simple stupid so everyone can understand it. There you go, sentence two.
- What should I have asked you about roadmapping that I haven't?
- The roadmap is if you truly use that roadmap as your plan for the product function, you know, it's effectively your, it's how you're gonna operate. I think it's important that we remember that if we're using it as an artefact to drive how the team operates and works, we've gotta remember it's gotta reflect where the teams are at. So it's easy for us to go, "Hey, it's got dates on this is wrong," or moan about features and customer requests or BAU being splatted all over it, which feels meaningless. But if the teams are on a journey, they can't, we can't expect people in organisations and ways of working to change overnight, but we can change a document overnight. So we must make sure as we improve the roadmap, we improve it with the journey the team is going on. What looks like an excellent roadmap for a highly mature product function in a product focused, product driven organisation where a product is at the DNA of the org, what that looks like, which we've been talking about at length today, we can't expect that to work for a business that's not in that place yet. So I would encourage people not to try and rip up their roadmaps and rewrite it to look exactly how it should for one of those organisations when they aren't yet one of those organisations. Let it evolve with you on your journey.
- Absolutely. Love that insight, Dave. That's like gold to us right at the end there. Here's the last little chance then, Dave, please give us the pitch for RightToLeft.
- Oh, the pitch for RightToLeft, easy. We help businesses build that product VCP we talked about earlier, and then we help them execute and help product leaders run and execute product teams that are trying to scale and avoid that scale growth ambush. So, you know, whether it's coaching or whether it's one of our consulting programmes, we've got a solution to fiddle budgets.
- Dave, it's been wonderful chatting to you today. Really loved having you on the show. Thank you very much. Just a reminder to everyone else out there, please do like, subscribe, hit that bell icon, follow us so you hear about updates. And if you'd like to sit where Dave is and have a chat with me or Justin, please do reach out either in the comments or via info at talkingroadmaps.com. Dave, it's been a pleasure. Thank you very much.
- Thanks, Phil.
