Do bad leaders cause bad roadmaps? | Jonathan Gowins
In episode 27 of Talking Roadmaps, Jonathan Gowins and Phil Hornby discuss the impact of leadership on product roadmaps, drawing from his experiences in fintech, drones, and insurance industries. Key points include aligning leadership vision with product strategy, managing team dynamics, and navigating startup challenges.
Jonathan started his product career in fintech, before moving into the drone industry to lead a team of product managers and designers at a startup under Verizon's incubation arm. Currently, he's the Director of Product at Openly, a startup disrupting the home owners insurance industry.
“A poor roadmap is a reflection of poor leadership”
Have a watch and if you enjoy the video don’t forget to subscribe to the channel, like it and maybe sign up to our mailing list!
Here is an audio-only version if that’s your preferred medium - and you can access it through your favourite podcasting platform if you prefer (Apple, Spotify, Amazon).
In the next episode we are talking to Hope Gurion, founder of Fearless Product and Product Leader Coach. So watch out for Season 1 - Episode 28!
-
- Welcome everybody to Talking Roadmaps, the channel where we talk about the good, the bad, the ugly with practitioners, experts, educators, and tool providers. Today I'm pleased to be joined by Jonathan Gowins from Openly. Jonathan, introduce yourself.
- Yeah. Phil, thank you. Yeah, Jonathan Gowins from Openly. I'm a director of product and design. We are a, I'd call us a scale-up at this point. We're sliding out of the startup phase, we've got great product market fit, and we are climbing, and so growing the organisation, putting in place product operating model, and I'm doing this all remote from Boise, Idaho.
- And just for our awareness, what game is Openly in, what do you guys do?
- We are actually in the homeowners insurance space. So this is a new industry for me, something I've learned a lot about since joining. And the reason there's space in that industry is because oftentimes if your house burns down or you have a total loss, it's very common to not be fully reimbursed for that loss. And you think that's why you have insurance, you think you'll get all the money outta your house and you're not. So Openly had a value proposition that we could use technology to make applying take eight seconds instead of 20 minutes, and which we do, and second, if something really bad does happen, we can guarantee to a degree that your house is covered well beyond what that limit might be. So it's a win for insurance agents and it's a win for homeowners like myself. So it's been fun, I've learned a lot about the industry.
- I can imagine with the wildfires in California over the last few years as well, that's starts to play on people's mind that that total loss scenario, little more than it might have a few years ago.
- That, and I think there was some flooding in Texas and those two events, I forget the numbers so I won't quote it, but it was a high percentage of folks who lost their homes who were not totally covered, which is really sad. So one thing you wanna go to bed at night and go, if my biggest asset, if I lose it, I'm covered. That's why I pay insurance every year for years and years and years, so Openly tries to do something about that.
- Cool. Well, sounds like good work. So just as with every YouTube channel and podcast, do everyone out there do like, subscribe, hit that bell icon to listen in, we'd love to have you on the show as well. If you'd like to sit where Jonathan is and tell us a bit more about what your views are on road mapping, reach out at info@talkingroadmaps.com. We'd love to talk to you. So I guess that's enough of the intro stuff. Let's get into it. Jonathan, what in your opinion, is the purpose of a roadmap?
- The purpose of a roadmap? So the academic part of my brain wants to tell you that the purpose is to craft a plan from your current reality to your desired vision, to where you want to be someday down the road. And it is, but I would say almost more importantly, it's a tool for giving other people, your business partners, peace of mind.
- Now there's a loaded word in there, plan. So I guess, how concrete or accurate is that plan?
- That's gonna go into how that plan is devised, so part of it is, I think a big piece of roadmaps it's missing, that was missing in my early roadmaps for sure. I'm like, I did all my homework, here's the roadmap. And I didn't provide any context around the roadmap. Here's my plan, but I'm not gonna give you any context because like I trust all the information I got and I feel good about the future, and when leaders, leaders are gonna be my primary audience, although roadmaps are for basically everybody in the company who's impacted by this and customers, but senior leadership is probably most impacted. And when they say like, "What's next? What's the plan?" They're rushed, they're busy. What they mean is, I'm trying to make money for this organisation and I'm wanting this organisation to win and I need to know what you think we should be doing and are there risks and are you planning around those risks and what can go wrong, and how confident are you and do you need anything from me? And that's all in a very rushed, what's in the plan? And so we give a plan, a list of features spread out over time, but we're missing all the context. We share the context, once the roadmap goes off the rails, well, that was because this and this and this and this and this. So that's how I view it, is a lot of context needs to be tacked on to this little list of features that's laid out in a plan.
- Great. You went there and told me who your audience is as well, so we had senior leaders as the primary audience. We then had anyone internally and customers as well. Great. And yeah, I think I broadly on the same page there. That external audience, I slice up a little bit more myself, kind of partners and prospects, as well as existing customers sometimes, just different layers of interest or trust perhaps.
- Yes, I've been on sales calls where I'm not the sales guy, even though I've got the same goal I'm helping them get revenue, but I sit down and I just walk through the roadmap with a lens on problems. You know, you list features 'cause problems take a long time to write out on a little slider presentation. But telling a company like, we understand your problems and this is how we plan to attack them, their credibility is huge, so I'm glad you called that out.
- We're all coming from the same place. We're all trying to achieve the same thing. And you know, the senior leaders, their motivation is really, they want to know that you're helping them on that journey to make money for the organisation, which we're all ultimately there for. I really liked that nugget of insight. We know who it's for, we know it's what it's for, who owns it, who maintains it, who's got the hands in this roadmap, this artefact?
- A younger version of myself , would've had a different answer. I would've said, you know, product manager owns it. And then I saw an online comment the other day by Matt LeMay, he had a post and it was humbling, just talking about ownership. And he's like, "You don't own everything. Like no company has some perfect ownership model, but you can be humble about that, you can partner with others, you can still dive in and I forget how it all worked out in the post, but it was really encouraging and full of humility. So I would say the, I'm gonna actually say when it comes to a roadmap, I believe that the product manager should be responsible for it. They should be the one trained in road mapping and thinking about trade-offs and getting information from engineering and being closest to the customers in a lot of ways, so they should be responsible, but accountable, I'm gonna say that leadership is accountable for it. And they get to say, the C-suite gets to say like this, we have to sign this deal because the investors need this in order to get the next round of this or whatever, and our job is to share a voice back up, say, okay, I got it, or like, I disagree and here's why, and I commit. And I had a job or two ago where I did this, the CEO was like, we need to build this thing. I felt very strongly it was not the right thing to build. It would not result in an outcome, a positive outcome for the business. I laid out all my reasons why, and I knew where they were coming, I understood where they were coming from, we listened to each other and said, "I am totally against this feature, but I will completely disagree and commit." I didn't have any tone or negativity, I was just like, these are some facts and it's on you, you're the one accountable for this business. And they disagreed with me and we went with their direction and it was fine, like it wasn't on my shoulders to feel like I had to carry the company, it was on the CEO's, and so it was a really good relationship.
- I absolutely love that concept of disagree and commit. I remember having similar conversations as the head of product with my sort of product people when some things were getting passed down to me, it's like I've already had the arguments with the senior leadership, I don't agree with it. But there are certain frame commissions, certain business context, sometimes just simple, they're the boss, that's where they are. They've got that position. Whether you agree with it or not, you just kind of get on with it sometimes.
- I do have one more learning that I'm excited to share with you that in my own personal journey, and it kind of ties two of your questions together on who is it for? And I've mentioned leadership is a big stakeholder and then who owns it? Being a PM that's responsible versus leadership. I have shifted, in the past, you get the question, what's your roadmap and you scramble to figure out the best features for what you understand about the business and the customers, right? And you lay those out. I would have so many debates on if something was the right thing to do or the wrong thing to do and I'd get frustrated 'cause I was close. And so what I use it as a tool to facilitate accountability with leadership. And what I mean by that is, a roadmap is not the starting point of strategy. It cascades down from if you have a mission or vision statement, which most companies, they're reasonably murky I'll say, right? And then you get down to strategic initiatives. Okay, we need to double in sizes here. We need to acquire this business, we need to do this one other thing, and that's how we're gonna, that's the plan we bought off on our budget side to it, this is where we're at. So I now add slides before my roadmap that lists out exactly any artefact I've got from leadership. And I've been asking for this, Hey, what are the KPIs? What are the objectives? What are the goals? What's the vision? Can you write it down? Like fostering all that, getting that, and then I put that in a cascade document that starts with vision and objectives and then it goes to the roadmap. So when I'm pitching my roadmap, I do not start at the roadmap. I start above with what leadership has said we need to do and if there's any holes in that, if that's not clear, I just call that out and I was like, Hey, I see this, I'm working towards it. Be the number one company in our industry, just so you know, that's murky for me, and so until I know if it's revenue or NPS or whatever, just know I can't roadmap any more specifically than I have. Do you have an answer for that? So it puts some accountability back to say like, I'm making a plan to your objectives and if they're not clear, then we can have a great conversation about that because that at least takes pressure off of, you know, the sales leader saying like, why isn't there more revenue in the roadmap? I'm like, that wasn't a key objective that was handed to me. We can make it that and then I'll change the roadmap, no problem. So that has been huge instead of like getting on the stand in front of the jury and it's like this is a two-way street, this is what I need from you, and then I understand what you need from me.
- Funny enough, I was just coaching someone and the key conversation was about having to put a roadmap in place, and dare I say, as we finished the session, I was saying, you know, basically you need all that context upfront, exactly as you talked about there, so I kinda said, I'll tell you what, I'll send you an outline and these are the three to five pages I would put in front of this before you even talk about roadmap. 'Cause I quite like to bring in like the macro market and risk pages in there as well, so it's like let's just make sure we all know and all are agreed on what the environment we're dealing with is, not where we're going and what's happening around us. And this is then trying to take us on a path through that to that successful outcome.
- Yeah. Yeah. If you see a different chess board, if sales needs goals more than the support team has goals and those aren't tied up and laid out and with trade-offs at the leadership level, yeah, you're gonna view a tonne of one-on-one battles, so getting that like here's the playing field where we all on the same page before I tell you the like magic features that we're gonna try to build. So that has been immensely helpful for me in getting away from a defensive, explain everything away all the time, type of posture.
- And so we've talked about kind of the cascade coming down of kind of vision, some sort of strategic elements, I mean obviously there's a thousand different ways of describing strategy and some objectives coming there. What about other artefacts? What else links into and connects to my roadmap?
- We just went through this exercise internally and did it a little differently than I've done it in the past and I feel like it really helped. So there's the artefacts from leadership laying out, you know, the vision statement and the any objectives. Then we actually made an artefact. We actually used Google Sheets to do this. One little key assumption in a roadmap for me when I'm working with PMs, don't put something on the roadmap if you haven't talked to engineering. Or if you haven't talked to engineering, you need to call out that you haven't talked to engineering. So we use Notion, but Google Docs or whatever you want to use, we list out every single feature, and a what is this thing? Like here's the problem that's going on, this is the solution we're envisioning, it's a dashboard with some information at a high level and the outcome we're hoping it hits from. So just even something to let the engineers think through it. And then we ask for front end and backend considerations and a wild swag to start off. And if they say I cannot give you an estimate on this, I can't even say like it's, I don't know, a quarter of work. Okay, then we know that that maybe shouldn't be on until we get more information or if it has to be on, then we're gonna call that out. So we're partnering with engineering, we're getting, you know, we'll do that with 10 features and do a high level overview. Now they're only estimating on like a paragraph. So we don't have designs for the next 10 features, but it helps, that feeds the roadmap big time 'cause we get a sense of reality for what we're asking about. And then we also laid out all those features in a Google Sheet, with how many engineers that team has in the priority order and we did capacity planning based on that too. So we weren't having a team that's got this huge aggressive roadmap with three engineers and we'll just find out in six months that it's not working and have a tonne of meetings and do all this, so we're trying to staff according to engineering's understanding of the needs upfront. So those two things were really helpful in making sure that we aren't over-committing.
- It's always interesting to hear like these little local approaches that kind of have led to great insights and great kind of outcomes. So I always love to hear those. So let's switch gears a little bit and think about what the roadmap looks like. What's it made up of? So if I think about key elements, the things on there, I've heard features a couple of times on the roadmap. What else do you have on your roadmap?
- Tool wise, we use Product Board right now and the main reason, I'm gonna get round route to your answer, main reason is because we track all feedback. Somebody has an idea or a complaint or a question and we tie that into Product Board to the feature category just so we don't lose anything. But then the actual roadmap that we construct visually is in Google Slides. I just, no tool visually lays out all the contexts that I wanna communicate perfectly and a slide is, it's also shareable, not everybody needs access to a tool. And so putting a roadmap in Google Slides is key. So we do, you know, we all end up talking in features and they all end up being two words, you know, like dashboard report or something like that, and you have to educate folks on the problem and what that means, so there's a whole conversation that I'm sure you've hashed out on here a bunch on what we mean by features, now we're taking a problem and shipping a solution to make an outcome, so that's there. But there's three, there's a few other things that I like to put on a roadmap on top of this little timeline or horizon with the features, the risks. So we'll just create a box of text called risks, and be like, hey, item number four on here, engineering can't even estimate it, and or we're blocked by this big project that's behind schedule, or we don't have any customer validation for that thing, whatever it might be, we'll just call out the risks that we're seeing and feeling as product people. Then confidence. So I'll speak to it or we'll add it on there and we'll say confidence, like this one, we have really high and it's, sometimes I'll use percent, we're usually high, medium, low, confidence in the effort. Maybe even in the whole roadmap. So we'll add context around our confidence in what we can do. Here's the plan, for the next three months we've got really high confidence because there's no blockers and we've got customer validation. Past that, honestly, we have a tonne of work to do but here are our next steps to validate those next six months. Low confidence, I'll circle back with you when I have more confidence. The more we write it down, the more you protect against this thing getting shared and your story is lost, your pitch has been removed. So risks, confidence, and I had a leader I worked for, worked with, sorry, who was over sales, and they would see the list, they'd be like, yeah, but what are we not doing? And they would always ask that like, 'cause they wanted more and they wanted to know what we're for sure not doing, and so I started a list of out of scope. Like here's ideas we heard, like these were the top two things from support, they really, really want this, we're not doing them, because it takes a year to re-architect our system and da, da, da, da. So I expect any PM on my team, myself, to have like an answer for why, for every single item. But then I want that translated into the artefacts. So risks, confidence, and out of scope, are the three things, especially risks and out of scope. Like people need to understand the trade-offs. So those have been added over the years to help tell the story.
- I think I've annotated with the risks and the confidence levels before, but I don't think I've had the out of scope. I've had the conversations and you know, as the old wisdom goes, product management is the jack of all trades and master of no, there's gonna be a tonne of stuff that's out of scope. But yeah, I can see the value of capturing that on the roadmap, or at least in the roadmap document.
- Yeah, trying to get the whole leadership team united in what you're asking me to do to make the company better, all of you with your competing goals, and then me telling you the reality we're facing. So we're all, at the end of the day, we all leave with the same pain of reality. Like that's what we need, whether we like it or not, we need to be united in clarity and reality.
- Yeah, which brings me back to kind of one of the other purposes that's come up a few times of alignment. Think you've just exactly articulated that. We've gotta get everyone on the same page and aligned, and it's a great artefact for doing that with. So yeah, I think you kind of preempting my questions really well, Jonathan. I'm kind of, we've talked about tools there, although I guess I'd like to unpick a little bit. You talked about both Product Board, you talked about Notion and you talked about Google Sheets and Google Slides, kind of just how do those four all play together?
- Yeah, and we're in the process of trying to maybe narrow that down a little bit. So the goal will always be, oh, and then there's Jira. So Jira has a roadmap version that engineers use. So it starts to get messy, it starts to live in a lot of places and we wanna unify that a little bit more. We've decided we do want a Google Slide to be like the final thing. It's easy to update, it's easy to add all those extra variables around context, and they get shared, it's easy to share with everybody. The Google Sheets, at first we were like, we need to keep that artefact up to date, but it's turned into, we need this Google Sheet for planning, maybe quarterly as we learn information around like do we have the right headcount? Is engineering allocating resources? And then as things shift constantly, we're not gonna keep that up to date. We're just gonna keep this Google Slide up to date. So we're moving into a like maybe a single slide deck across PMs, and actually I called it like the product strategy cascade, and we have oh, five or six, maybe like six PMs right now, at Openly. And so it'll say leadership, what's company mission, what's our vision? And then this team, what's your vision statement for your team that fits into the grander vision statement? And then a one slide for your roadmap. And then the next team and the next team, so we have one deck for our product organisation that's like, this is where we start, here's how it all cascades down. And then we'll probably use Notion to get context and planning details out of engineering. And then the Google Sheet on resource planning. We're really moving away from road mapping itself in Product Board, although I think that tool does that very well, just given our needs, we're mainly now using that for the collection of insights and feedback tied to features.
- I guess what it sounds like is a very pragmatic approach to the active road mapping is valuable, the road roadmap in a given tool, you know, who cares, right? But we're gonna present it the way that allows us to communicate best.
- That's it. Yep.
- What's best practise in terms of road mapping for you then?
- Oh, best practise, always have an answer. Always have a reason why. Like no gut checks or intuition. If you haven't talked to customers about this, you need to call that out, or you need to talk to customers. Theresa Torres, right? You need to talk to customers if you can. When making a roadmap, getting as much information as possible, from customers, from engineering, and leadership. I mean I'm just gonna keep going back to that, tie it to leadership goals. If you don't, I've taken visual, I've taken slides with vision statements on it, it's this total, whatever the word is you want to call it, it's just buzz words, and I light up with questions, I can't roadmap to this, this doesn't mean anything to me, I don't know about this. How do you quantify this? Can you pick between these two things? Da da da da da. I'll send that to the leadership or the president or whoever and maybe I get an answer, maybe I don't get an answer. I'm like okay, then if I don't get an answer on that, I'm gonna tell you when I roadmap, this roadmap has no anchor, it has no north star on it, because of the feedback I gave you. So are we all, again, I don't have to win, I don't have to twist an arm, I don't have to force a perfect strategy, it's hard being a senior leader on a company, it's hard being a CEO, it's hard picking a perfect strategy, like there's no such thing. But if we at least address reality, that there's no north star that we can roadmap to, can we just all agree and be on the same page? If that's the case, this is our best bet right here. We can totally disagree and commit. So really working with leadership as well. And then the last thing is, you know, Phil, there's so many acronymy tools out there. I won't pick on any, they all have value, they all help you think strategically. They all help you ask questions instead of go, oh, I just know what's best, and that's reasonable. But the best approach that I've found, if you want to, you know, methods, methods are just methods, principles are where it's at. But I've loved cost of delay. And Black Swan Farming, the guy who runs that has a video, and ever since I watched that, any PM I hire, any PM on my team, I'm like watch this video, watch this video. And it lays out the four types of value that every company has. Everything you do, you can trace back to four types of value, increasing revenue, protecting revenue, decreasing costs and avoiding costs. Everything. And I'll sometimes bake that into a roadmap as we're planning and say like you said this, so we're focused on increasing revenue, which means we're not decreasing costs isn't as much, is that right? We've got, oh yeah, we just raised a tonne of money, we're good with budget, get revenue. Okay. Good. So tying it back to those things and then thinking about the impact of value over time. What happens if you build what in what order? What are the trade-offs? What are the sacrifices? What are the value, the actual value trade offs? And are we clear on that? So it's a great tool. There's no perfect modelling or analysis. We are smarter, I believe we are smarter and have more context than any tool we'll ever have, but if we think in terms of cost, the cost of delaying things and what the value is we're trading off, it makes for an intelligent roadmap.
- I seem to remember Melissa Perry maps to that exact model in Escaping the Build Trap that I was scanning through only this morning, just to remind myself of one of the concepts in there. So yeah, great to see, and hear. Now I wonder if you've already hinted at some of these, but what's the biggest mistake or the worst practise that you see on a roadmap?
- There's one that just jumps right out. So I could list the antithesis of like everything I just said, right? But ah, you know what bites us, is the desire to please, being eager to please. I want leadership to like me, I want to do a good job, I want the company to win, product managers, we're competitive, right? We want the company to win, we wanna solve problems, we wanna do what's best, here's my plan. And the president walks in the room or the senior leader walks in the room, and they look at that roadmap or that plan, what's next? Why, what's, hmm. Do you think, could you do, could you do this thing here, if you did da, da, da? We could try, I mean we might be able to do this one like a little faster, and this eagerness comes out and that meeting it ends really happy, it ends really happy. But the one, two months from then, is miserable . And so, I try to like my mantra that I share with PMs is, take your licks up front. Like have the hard conversation up front 'cause it'll be way less hard than later. And if you can't do something that somebody's suggesting, while you're presenting your plan, don't say I can maybe squeeze the plan and be like, honestly that would bump something on the roadmap. Don't hate me, please don't, you know, don't look down on me, but you have to be realistic. You cannot be eager and optimistic when like planning fallacy, people skip planning fallacy. When I get something from an engineer, I just add 50%. They're smart people, they know what they're doing. Sometimes they're right, sometimes they're ahead of schedule, but a lot of times so and so broke their leg and they're out on the heal for two months and there was a tech that we didn't see and another emergency that came up and just like 50%, 50%. So if you err on the side, so another best practise, err on the side of caution and conservatism and even say that out loud, and do not be eager, I've watched PMs get torched. I've been torched by trying to be optimistic, well we could probably do this. And then it doesn't, it's so far from your ability, your ownership, you don't get to make engineers code faster. You don't get to figure out if the architecture supports it or not. Like stand your ground with the risks you see when you present that roadmap. If you are eager, it will bite you big time.
- So true. And yeah, one I've fallen for myself far too many times I'm sure. So we've said kind of good practise and bad practise, but are there any pet hates when you actually look at a roadmap and see one, is there anything on, if you see it on there, you're just going to put your head in your hands or cry or something like that?
- If I am reviewing a PM's roadmap, they might have a list of things, you know, A, B, C, D, and I'm excited about it and here's the order. I'm like, what do you mean by that? What do you mean by that? Those two word feature things. Oh, I don't really know but da da da. Or it's not actually something we can build, it's not a feature or it's just wishful thinking or it's a, you know, a version two of the thing. Like what's version two? What problem are you solving? What's the outcome? I don't know. So it's really like road mapping is really hard work, let's just call it what it is. It is hard work. You are doing like basically a huge like Master's thesis research paper in understanding features and engineering and customers, but if you skip all that and you just put down a couple things people are nagging you about and you don't know what you mean, you don't know if engineering can build it, like that is the biggest, one of the biggest mistakes that I will ask somebody to go back and I've seen this like we don't know, they get to a roadmap item, they'd never talked to engineering about it, engineering was like they start, they're picking at it 'cause the PM asked for it and it ends up they can't do it and four months later they've wasted time, if you roadmap inappropriately and you give the next thing to engineering and it hasn't been defined enough or validated or a little bit of upfront architecture research, like you're really gonna hurt the company. So I need to know that what you're listing on that roadmap, like you have thought, you have answers, you know what it means and you know what engineering thinks it means. So that would be my, over anything else, that's my biggest pet peeve.
- Sure. It almost sounds a little bit like there's a need for a ready to roadmap status on something. Like some people have that definition of ready before things can go into their backlog. I can almost imagine it's, you know, ready to roadmap. It's got just enough detail that we can put it on there. Not too much that it's gonna pin us down too much for discovering things as going through that journey.
- Yeah, you can say, I can't roadmap this yet. You can put it on there and give the context, I got low confidence, and I'm gonna say that problem, that pet peeve I just laid out, that's actually less a product manager's problem, that's a leadership problem. That's a, if you see that, you haven't set expectations as a leader with your team, this is what road mapping is. And this is where even as we're growing, right? We're having people roadmap and like, oh, I never told you how to, I'm like, oh here, this page, talk to engineering about every single thing, capture their thoughts. Does it still make sense to put it on the roadmap? What's your context? So a poor roadmap, this is accountability, a poor roadmap is a reflection of poor leadership. We need to be explaining to our teams what winning looks like, when it comes to road mapping, we need to give them tools, templates, artefacts, processes, we need to be coaching them through the process, we need to be reviewing it with them before they present it to the company. And you do that enough times, and now you learn to trust, you're like, they've got it. Like whatever they have on that slide, I know they know the answers, I know they're thinking about the context, I know they did their homework. So I'm gonna be so bold Phil as to say, a poor roadmap reflects poor leadership.
- That's a big statement. Whose advice on road mapping do you listen to?
- I really can't get away from Black Swan Farming. It's so good. Cost of delay, you go to the website, I don't know if, he used to have a video called Cost of Delay on the website, now he's got some really good articles, but I know the video is still on Vimeo. And so, I just, it helped me see I, you know, you think that you're chasing down an outcome but you don't really know what the value is for something. And he's very sharp, very quantitative, brilliant guy. And it just really opened my eyes because the principle of the thing is you need to make value and you're laying out a plan to get value. What is value? How do you think about value? So that would be, a big place to point folks to.
- If you had to distil your philosophy on road mapping down to one or two sentences, what would it be?
- Road mapping is a tool, to facilitate strategic accountability, bridge that gap between product and leadership, and quell anxiety for your business partners.
- Is there anything I should have asked about road mapping that I haven't?
- You could have asked about like a nightmare. Like do you have any nightmare stories from road mapping?
- Go on then, give me one of those.
- I've seen just the recurring nightmare, of scoping a roadmap item too big without talking to engineering ahead of time and wasting months of high paid engineers' salaries and time and team culture goes downhill, meetings go downhill, reputations are on the line. I can think of one in particular, you know, two months turns into five months, turns into seven months, and it's a giant mess. So this is maybe a little bit past, what you're after with this interview, but scoping those roadmap items down to the bone, to the version one minimum that adds value and nothing else, I would add as a little like icing on the cake, like getting PMs, teaching PMs to scope less, it hurts emotionally, but like you save so much money and pain because I've seen horror stories with just wandering through the woods with a feature until you have some serious consequences.
- Thanks there Jonathan. So I think we'll bring it to a close there. It's been a pleasure having you here today, Jonathan. As always, just like to remind everyone out there, please do like, subscribe, hit that bell icon, listen in, share it wide. And if you'd like to take part, please do, get in touch, either by the comments below or by getting in touch at info@talkingroadmaps.com. We'd love to have you here. Jonathan, been an absolute pleasure.
- Thanks a lot Phil, back at you.
