Should you have a product satnav or compass instead of a roadmap? | Ed Roberts

In Episode 66 of Talking Roadmaps, Justin Woods interviews Ed Roberts, senior product strategist at We Are Systematic. Ed explores why product teams should rethink traditional roadmaps, favouring satnav or compass-like approaches to adapt to uncertainty. Key insights include embracing flexibility, prioritizing effectively, and treating confidence as an output of work rather than an input. Ed also shares thoughts on evidence-based design, managing ideas, and using tools like ProductSweet to bridge gaps in innovation processes.

Ed is a partner and senior product strategist at We Are Systematic where he champions evidence-driven methods to create digital products for organizations of all sizes. He is also the product lead behind ProductSweet, which he describes as the best product management tool you've never heard of.

Before joining We Are Systematic, he worked as an analyst, conversion rate optimiser, researcher, UXer, product manager, and team leader.

Currently, he is most interested in ideas – where they come from and how to make them real. Occasionally, he writes or speaks on these topics, which can be found on the We Are Systematic blog and on Medium.

He is also available to speak at conferences, away days, or podcasts, and, if desired, at weddings and birthdays.

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 Ant Murphy, Product Coach & Founder of Product Pathways. So watch out for Season 1 - Episode 67!

• Transcript

  - What we're doing now, it might enable one or two things, but actually, we'll see when we get there, right? This might look like the best idea at the moment, but things change, competitors move. The market changes. If we're thinking more than two, maybe three steps ahead, we are guessing.

  - Hello, and welcome to the "Talking Roadmaps" channel. My name's Justin Woods, and I'm one of the co-hosts here. And today, I'm joined by Ed Roberts. Ed, welcome to the show. Please introduce yourself.

  - Hi Justin. Thanks for having me on. So, yeah, I'm Ed Roberts, I'm a partner at digital agency, We Are Systematic. And I'm also the leader of the team behind the ProductSweet, our new product tool.

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

  - Absolutely, yeah, that sounds exciting. There's two of my favourite things that you're talking about already. We'll dive into the questions shortly, but welcome to the viewers as well, or listeners, if you are listening in on the podcast. "Talking Roadmaps" is all about roadmapping from the good, the bad, the ugly. So, Ed, let's get stuck in, without further ado, what do you think the purpose of a roadmap is?

  - Right, so ultimately, I think everyone tends to agree that a roadmap is a communication tool, right? The question and the divergence tends to be about what it's communicating. I'm gonna get a metaphor in really early, because it's probably one that I will torture to death through the course of the next few minutes, but a lot of your past, the people who've had in your podcast, have also agreed that the word roadmap isn't great, to be honest, because it's archaic, really. Like we talk about it being a way of getting from A to B. It conjures up images of what my granddad used to do. He'd have an A to Z in the back of his car, right? And every time he'd go out on a trip, he would plan it out, he'd be like, "Right, I'm gonna take this road, then this road, then this road, then I'm gonna stop. Then I'm gonna take this road, then this road, then this road," all the way to the end, right. It's just not a good metaphor for how things work today. I really like the idea of the modern roadmap being more of a satnav. And again, that's probably not a new thought, I'm sure other people have had that thought. But when you're thinking about what the communication tool is, what is it communicating, it's all about orientation, like where are we right now, and what is our next turn? And giving some perspective on why that is. So this is our, you know, it's our destination. This is where we are, this is our next hurdle, maybe our next two turns. But provided we all kind of agree and we're orientated around that, that's as far as like a roadmap needs to go, in my opinion. And checking my biases, obviously, we work in kind of early product innovation. I'm sure other people's mileage may vary. Other people might like to see lots of steps mapped out, A to Z, exactly the opposite of what I've just said. But this is kind of where we think. It's more a satnav than it is a roadmap, really. Also, worth saying that a roadmap is how you get somewhere, it's not the somewhere, right? So ultimately a roadmap is something transitory, it's something that is a product of the effort. It shouldn't be the effort.

  - Oh, that's a great way of thinking about it already. So I totally agree, if we take the old fashioned A to Z of typical roads, typically if a road is in an A to Z, it's been built already and somebody's got there already, many times. So it's probably fair enough to say that if we're gonna get from A to B, we go this route and it's gonna take us this long. Because it's exactly as you said, especially in the innovation space, nobody has ever been there before. There is no tarmac down. Nobody has actually been to that destination even though we know where we want to go. And so bringing it back to orientation, more of a satnav. I love that analogy 'cause I've not heard of that. We all talk about roads and the analogy to roadmaps, but not the satnav side of things. It's almost like almost the satnav as we're building roads, not even the satnav on roads that have been built already with discovery. And the fact that it's transitory as well, the kind of you are alluding to the concept that the roadmap isn't the end destination, it's actually describing where that is, and that end destination maybe is described somewhere else, brilliant way of thinking about it.

  - I found it to be a really useful metaphor. And like I say, I'll probably overdo it a bit as we go, but let's see.

  - I think we should. I think bringing that metaphor in though, and referring back to it to kind of clarify the point, yeah, please feel free to. I think it's a strong metaphor. If that is the purpose of a roadmap, and I definitely agree with that, who is the audience of that roadmap?

  - It's lots of people. There are direct audiences, people who will actually view the roadmap itself, and there are kind of ancillary audiences, people who are impacted by it but don't necessarily view it, right? You might think of them as sort of secondary stakeholders. Customers often fall into this category, unless you're one of the brave companies that makes their roadmap fully public. Your customers don't necessarily have sight of your roadmap, but they're very much impacted by it. But yeah, I said I'd return to it. If we think about the satnav metaphor, right? So who is the audience of a satnav? You have one person who's doing the driving and they could be seen as like the primary audience, primary user. But you also have your passengers, right? They have things that they need to know from what the satnav is telling them, what the roadmap is telling them. You have people at the destination you're heading to, they need to know some information. The jobs to be done are all ever so slightly different. If I'm the the product manager and I'm looking at the roadmap, what I'm looking at is what's happening next? What's my next turn? If I'm the owner of the car, the owner of the company, I want to know that my prized asset is safe, right? That it's going down a path that is not just gonna run it straight into a lake. The , the people at your destination, maybe your customers, they wanna know when things are arriving, right? But they don't necessarily need to know play by play how you're getting there. So there are different audiences and they all have a slightly different jobs to be done. And the roadmap kind of has to cater to all of those, which is a challenge, right? And I think when we see roadmaps that are not necessarily that popular, it's because they're conflicting with one or other job to be done. It might be designed purely with the product manager in mind and, you know, fits their job to be done fully. Stakeholder or secondary stakeholder, they look at it and say, this isn't giving me what I need it to be. And this is where you get those frictions in, right?

  - You almost need to look at that. Yeah, I totally agree, there's different things that are needed. You might have the navigator in your car, or the person that's not driving, I should say. And they're looking at other things like phoning ahead to friends to say, we're going to be late, or we're going to arrive at this different place, or we're taking a detour. All of those different things that you need to get from the roadmap, but then the views and information you needed from it are different because the context are different. That's a great way of putting it. And I hope we do use that metaphor further actually, 'cause I think it's great to kind of bring that visual metaphor in. So, okay, that makes sense. So who do you think owns the roadmap and maybe maintains it? Would they be the same people?

  - It's the same cast of characters, but maybe again, the roles shift slightly. And having thought about this, the obvious person to say the owner is the product manager, right? 'Cause they're responsible for the delivery of it. But do they really own it or is it something that's in kind of shared ownership? If we think about like a path or a route, even a satnav, again, the owner of it may be entirely different to the user of it, but the product manager is the one who's ultimately responsible for making those turns and for allowing things onto the roadmap or sort of saying when things are done and they're off. But there is this concept of shared ownership. You have these stakeholders who are higher up, the owners of the company, the product directors, the CMOs, they all have a stake. And maybe that's a better way to think of it, is who has a stake in the roadmap rather than who owns it? Because ultimately ownership feels like territorial in some respect, right? This is my roadmap. Hands off it. Whereas if we acknowledge that lots of people have a stake in it, it becomes more of a cooperative tool. Again, we're talking about communication orientation again, rather than, you know, here's my 1 to 100 list of things we're gonna do.

  - Yeah, yeah, literally buckle up in the car. And that's and that's so true. Again, a really good point there that plays into that, which is I think a lot of people of lot of product functions that I've worked with have been quite possessive over that roadmap. And it shouldn't be. And I think that causes a lot of problems there. Whereas actually it's we are owning the updates to this and the maintenance of it, but it's a collective view of our understanding across the different stakeholders. That is a different view of the same thing and drives, I think, better conversations and discussions. You mentioned at the beginning that the roadmap isn't necessarily the end state in and of itself. The roadmap is going to help us to get to that end state. And being in the roles that you've had and what Systematic do, it sounds like a lot of the important part of that is actually defining that end state of where you want to get to, or at least the future vision of where you wanna go. I'm curious how the roadmap ties into those things and what those things might be that define that trajectory.

  - Right, and this is where we can bring in things like vision and objectives, right? Sometimes mission. We might have different terms for it and different people sometimes mean different things. But if the roadmap is how you get there, then what is the there, right? Personally, we would think of it as a vision in the long term. Like, I know that the terms vision and mission, they get mixed up. But if you have your vision in the long term, we want to aspirationally do X or Y, we want to break into this market, we want to improve the experience for this cohort of users, we want to be the best at X, Y, Z, right? That's the vision. That's what gets you outta bed in the morning, right? And the way you get there, it might be poetic, it might be you got outta bed in the morning and you would just struck by something, and like, I need to do this. Like, this thing has been painting me for far too long. and solve the world's problem. Or it might be more kind of business-minded, right? You might sit down with business model canvas or value proposition canvas. You might sort of work your way down to a vision based on something that's a little bit more empirical. And both are fine, right? But the vision has gotta get you outta bed in the morning. Then you can look at something like OKRs. I say OKRs with a slight tentativeness in my voice because I know they're a love or hate them type thing, but they are a very good way of kind of communicating how an objective links to a measurable result, right? And however you may wanna do that, whether it's OKRs or something else. But that's kind of the layer down for me from the vision. OKRs are like, if the vision is where we wanna get to broadly, OKRs are how do we know when we got there, right? Well, how do we measure that? And what does that actually look like in the real world? And then once you've got those two things in place, you can start to roadmap because you've got your end destination. And now it's just a question of looking at what are the problems or the questions, or maybe the jobs to be done that kind of sit between us and that vision. And in the fog of war, right, you might only be able to look at pace or two ahead. There's a fantastic old, I think it's an old Chinese saying, but I hope I'm not getting that wrong, "Cross the river by feeling the stones." I believe so strongly in that. You can see the other bank, you can see the rushing water, you know what you're in for, but where you put your foot is based on where you can feel the next best step to be. You can always see that vision. You know your objective, get across the river, right? But you can't say, right, well, I'm gonna stand on that stone and then that stone and then that stone because it just doesn't necessarily work like that.

  - No, it doesn't. That's a great way of thinking about it, and actually is how we should think about roadmaps more, is often roadmaps are thought of as delivery plans and the concrete steps, no pun intended there, but the concrete steps that we need to take to get somewhere. And actually, it's very different to that. It's actually, we need to feel as we go. And that's something that you guys, I believe, help your customers with, which is looking at evidence-based design and consultancy and things like that. So you are very much testing and learning. It's more about understanding that space. And I'm curious whether you think that even things like evidence-based learnings and discovery, are those things that we can roadmap as well, and maybe should we?

  - You can. You would do it in a slightly different way. So should we, I would say yes. I'm a big advocate for not just doing random crap. I've sort of got on my high horse in the past about the use of words like experiment in business. I think when people say the word experiment, regardless of what the intention was, or people were advocating for kind of an experiment-led approach, I think the way people hear it these days is often, do some random crap, see what works. And actually like the testing of good ideas is something that is quite systematic. And you can't just kind of, let's build a chat bot. It's an experiment. It's just not good use of anyone's time or money. And your customers will not thank you for it. So can you roadmap out evidence-based design? A hundred percent. But what it looks more like is something like an opportunity solution tree. You have your north star, your vision at the top. You break it down into your goals, you break that further into your problems. Your problems, you break into your ideas. And then from your ideas, you can test it. So we can think more about how are we testing good ideas? We've broken this down to a point where we know that every piece of evidence we gather, every test that we run is feeding this chain that takes us all the way back to our vision. You definitely wouldn't do it in a sense of, well, we'll run this AB test and then that's AB test, because already you're presuming you know the result of test one, in which case, why did you run this in the first place? If you were that confident about the outcome of test one, just do it and then run test two. You have to cross the river by feeling the stones.

  - Yeah, that's great. That's gonna stick with me. Thank you for sharing that with us, Ed. That totally makes sense. And I'm pleased that you talked about opportunity solution trees because we've been fortunate enough to have Theresa Torres on the channel as well and speaking to her a little bit about that. But I remember when I saw it, it was such a simple concept, but actually was a game changer for me when I thought about it. All too often, stakeholders come to us, or stakeholders not as necessarily senior sponsors, but anybody that has a stake in "The Roadmap," comes to us with a solutionized request. And actually it's about looking at, well, what's the bigger opportunity that that might all align to, and how do we remove some of the biases? Because as humans, we are very good at talking about solutions and solutionizing straight away, but often it's far too early. And so that must be a big challenge in your business as well, Ed, is when you are working with clients and they come to you with the next new shiny that they might want to work on, but they know that they kind of wanna do some upfront work, is kind of decoupling them from that. And they're actually looking at the evidence-based or the design-based approach of those. Does that resonate with you, do you find that?

  - I mean, it couldn't resonate more if I was a bell, to be honest. I mean, the needs to take in ideas and to have people heard, right? Like, you don't wanna be that partner who just sort of shut this down, we are not listening, because good ideas come from anywhere. They come to you in the morning in the shower, they might come from a user interview, they'll come from stakeholders, both high and low in the pyramid. What you need is a way of kind of making sure that people are heard, taking those ideas, logging them somewhere, making sure that they fit into the jigsaw, right? But they're not necessarily the thing that happens now. Where ProductSweet actually came from was solving this pain for us, working with lots of clients in this sort of new product innovation area. Getting ideas is not the problem, managing them is. So ProductSweet was our idea management tool. And we are here talking about roadmaps, but the critical thing is is more about what goes on the roadmap than the roadmap itself, right? The roadmap can be the most beautiful storytelling communication artefact in the whole wide world, but if what's on it is junk, garbage in, garbage out, right? So we've put a lot of time and effort into, before ProductSweet, it was a framework, but now it's in ProductSweet, how you choose what you do. And whether you're thinking at that goal level, the problem level, the idea level, or the test level, you capture everything. You make sure it ladders, that it always goes back to the vision. If it doesn't, fine, park it, it will have its time. Don't ever put the shutters down and say these ideas are good, these ideas are bad. There are just ideas we have confidence in and ideas we don't. And that shifts very, very quickly. And an idea that we all thought wouldn't be happening in the near future suddenly is the idea of the day because we've realised we have a problem that that idea is a really good fit for. And organisational memory can be short, right? If the place you're logging your ideas, if the place you're doing your roadmaps is on spreadsheets and PowerPoints, they're gonna get lost in drawers. They're gonna leave when people leave. But if you have somewhere safe, somewhere structured and open to kind of keep these things. I'm getting very dangerously close to making this a ProductSweet plug, I'm afraid. But this is the friction that we were trying to ease, to be honest.

  - Well, I think we should. I mean, it's something that you're clearly passionate about, and it's solving problems for your clients as well and so we definitely should talk about that. I think there's two things that you mentioned there, which is that there is not necessarily a bad idea, it's just ideas we have confidence in and ideas that we don't. I think that's a great way of looking at it, because there's, I don't wanna, I just use the term loosely, there's no such thing as a bad idea. I kind of do agree with that. I think they come from a place of good intent and from a place of need. But whether there is a confidence in that, that is something that we need to build in the short term is, you know, is up for debate or up for critique. But also you use the term there of organisational memory can be short. And I think that's absolutely right. It's one reason why I'm quite passionate about roadmaps in some senses of the word, which is often roadmaps will outlast the tenure of the employees that own them or that deliver on them. And so by having that organisational memory or corporate record, you can see where we've been and some of where we think we want to be going. And it means that we don't go backwards and forwards on, you know, this technique versus this because a new management's come in and think that that's the right thing for us to do. So it offers that kind of, that record so we can go back and see that. And it sounds like you guys have started to, or have within ProductSweet built that level there. I suspect you are aching almost to build it out more because you can see that from ideas where do we go then in terms of delivery and things like that? So it's started off internally and you're using it, but now people, it's really resonating with people.

  - Yeah, absolutely. Absolutely. I know, I mean, you know your ex Aha!, right? You know there are tools in this space that are kind of playing in the same area, right? But we wanted to produce something that was fast, allowed you to get to the kind of that view really quickly and simply. So something we say a lot is be Trello, not Jira, right? Be quick to value. Not say anything wrong with Jira. It's just like when you're operating in that fast spin up space, configuring Jira can be quite a lot of your time. You want something that's very simple, very easy to get right and, agile, exactly. Lowercase A or uppercase A, whichever people prefer. But certainly that ability to move a bit more quickly and not make the tool the thing, right? The tool is how you get from A to B. So how can you propel people into that value as quickly as possible? And you were absolutely right when you were talking about organisational memory and where we've been and not repeating the mistakes of the past. Although I talk a lot about moving forwards, and, you know, choosing your next turn and finding the stone that takes you one step further, you need to remember where you've been before because otherwise, you get back into that loop of just doing random crap because you're just doing the same things over and over again. And a new CPO comes in, they're like, we are gonna do this, and nobody wants to tell them, the last person thought that.

  - Yeah, it's so true. It's so true. I wanna talk a little bit about the design of a roadmap. You seem to me as a creative person somewhere where design-centered thinking, and obviously that's what Systematic do as well. But talk to me about what you believe are some of the key elements or content of a roadmap? And maybe it's design. What do you like to see? What would your ideal roadmap look like?

  - We've been thinking a lot about this because if you tie everything together that we've talked about so far, right? If we believe that like the roadmap of the future is a satnav, not a roadmap, what does that actually look like in practise, right? It's very easy for me to sort of philosophise. And so we've been thinking a lot about it. And actually one of the reasons that ProductSweet launched without roadmaps is because we want to get that right. We have all the building blocks, we've got the ideas, the problems and everything. And the visualisation of the roadmap is the nut that we're cracking actually right now. And the way we are leaning is, again, if you break it down back to that satnav, right? It tells you where you are right now. It tells you your next turn, maybe your next couple of terms. It gives your destination and it gives you an outlook. What's the traffic like? How at risk is the time, that BETA. So if we try and translate those into the, exactly, exactly. If we try and translate that into the product world, actually my perfect roadmap has our vision, it has our OKRs on it, but then after that, it's much, much simpler. I know that we've, thanks to like the great work of Janna Bastow, where people are moving or at least understand the importance of going to say timeframes, not timelines. Now, next, later. But I personally, and this this is the point where maybe people switch off, but personally, I think now, next, later is even thinking too far ahead. If we're looking at the now and the not now is really what makes the difference in terms of, like, the satnav. It's like these are the things we're doing now. This is who we are, everything else is noise. This, what we're doing now, it might enable one or two things, but actually we'll see when we get there, right? This might look like the best idea at the moment, but things change, competitors move, the market changes. If we're thinking more than two or maybe three steps ahead, we are guessing. And there's this great quote from, it's the 37signals guys who created Basecamp, David Heinemeier Hansson and Jason Fried, they say, "Planning is guessing." And that's one of those quotes that's just stuck with me because it's true, right? We're making an educated guess sometimes about what we're gonna do, but it's a guess. So back to my perfect roadmap, vision, OKRs, what we're doing right now, what we might do next, and kind of the the major problems that we're solving, right? What is the problem we're solving right now? A couple of the ideas that we're investigating to do it, but problems that we're solving like right now. And that simplicity, well, my hypothesis I suppose is that it will speak to some of what we've talked about, about how to say different things to different people. If you go too detailed in any one direction, you are attacking one job to be done much too hard and you're making it harder for other people to have a stake in the thing. If we all agree that it's like, it's a, not even a sign of, it's compass, right? It's a thing that is transitory, stateless, that gives us a version of the now, maybe, like, I'm sure it's possible to start throwing the argument back at me, that Ed, you are no longer describing a roadmap because you've abandoned basically all of the tenets of what a roadmap should be. Maybe I'm just being contrarian. But keeping that vision, keeping those OKRs, where are we going? We're crossing the river. How are we doing it right now? We'll debate what goes into that now bucket, but everything else is noise.

  - I really subscribe to that, Ed. And I think actually, if I'm completely honest, that reflects my feeling about it even better in that a satnav is still using and looking at roads that exist already, whereas a compass is just pointing in a single direction. It doesn't know anything else. It's up to us to define. A satnav might tell you which bridges to cross or things like that. But actually going back to that proverb that you mentioned, it's much more closer term. And, you know, planning at that far out, could be fruitless for us. I love the concept of this now/not now roadmaps because I think it can even be a little bit more honest. And the other thing is, is that if we are going to make decisions in future based on some of the things that we're analysing now, it's far too soon to say that whether that's gonna be on the next or the later bucket. It might be that if we do some experimentation or go down this route right now, we learn something that means that what was gonna happen and next is completely eradicated 'cause we found a new path. Certainly in discovery type roadmaps or discovery type work, that is much more true than the delivery type roadmaps where we might have the confidence that we know what we're building. But in a discovery side, we just don't know, we're still feeling those stones underneath our feet. So that's, yeah, I think that's a great way of looking at it. And the compass certainly, for me, feels much more like how we should look at roadmapping.

  - The three Horizons model is another one that's quite good actually, 'cause it still allows you to separate out, these are different packages of things. These are different themes that we may want to do at different times, but they converge. It's more of a Venn diagram, stuff in the third horizon is still happening now. It's just happening at a different pace. It's not necessarily now and then this and then this. It's this is the flavour of where we are right now, where we need to be. And we're doing early steps of the third horizon now. But it's not our focus, it's not the now problem.

  - Yeah, I like that, and I'd like to see more people embrace that out in the community as well. So folks, if you're listening in, some great thoughts there in terms of how to approach those things. Ed, as a quick question, do you have a favourite tool to create and visualise your roadmaps? If we don't quite have that in ProductSweet yet, is there something that you do like to use?

  - Actually, I like whiteboarding tools. I use a ProductSweet to structure my thinking and then use a whiteboarding tool like FigJam and I just sketch it. Or even like Freeform or, you know, pick up the Apple pencil and you sketch it. And then you can communicate that this is not a set in stone thing, right? In terms of then delivery, like Asana, other project management tools are available to sort of take it forward. But the honest answer to your question is that I spend a lot of time thinking about how we will be visualising it in ProductSweet. So yeah, that is gonna be my tool of choice for a future plug if you like.

  - Excited. Absolutely. You know, we're excited to follow what you guys are working on and doing. There's no favourites particularly on the channel for us, even though my background is Aha, I've often controversially said that my favourite roadmapping tools is more around presentation and whiteboarding software. You manage and plan within the tool, but there is nothing more flexible than pen or paper or something that's just completely a blank canvas, quite literally, that allows you to pull that information out. What I think people go wrong is they try and plan and manage their roadmap in a presentation or whiteboarding software, and they can't manage the complexities of that, again, depending on size. But yeah, I totally, totally agree with you. So I'm wondering what you consider to be a best practise in roadmapping, and maybe an anti-pattern, something that you hate to see people do with roadmapping. Kind of we'll explore the good and the bad. What do you think there? Have you got examples?

  - One of the good, one of the bad. So actually I'm gonna do two different sides of the same coin here. I think a display of confidence is really important. And I think it's in Scrum, you have the Cone of Uncertainty, right? How you differentiate an idea that is a is, quote, unquote, "good" from, quote, unquote, "bad," for me is confidence. And so if you can display your confidence at a stage in the roadmap, we're attacking these problems and this is our kind of our overall confidence of where we are. That is a really good thing to add onto a roadmap because you're allowing that space for you to be wrong, right? Attacking problems is the key thing, right? Not solutions. Like, solutions come and solutions go. Attacking the problems is the right thing, or a job to be done, or answering a question in that sort of broadly in that first diamond, then you can attribute a confidence to the ideas that you currently have. And if that needle gets too low, that's a flag for you. It's like we've gotta change something, right? We've either gotta take this one step back, we've gotta break these problems down a bit more, we need a few more ideas to come in the bottom of the pipe, or we need to investigate those ideas a bit more. So this takes me to my anti-pattern. And the pet hate, the thing that I see on roadmaps that I really don't like is when confidence is an input. So for me, confidence is an output of this work. We do the work and we get our confidence. If confidence is an input, that's basically allowing the PM or whoever to say, how much do I really, really wanna do this idea? Because confidence, it's subjective, right? It's based on bias, it's based on recency. The last person you spoke to may have been very, very confident that they need this feature right now. But does that mean it's the thing that you should do? And some of that confidence is like, is catching. You listen to me like, oh my God, they're absolutely right. We need to stop everything we're doing and do this feature. And like, so you go in and you whack the slider for confidence right up to 11. And you're steering the roadmap badly. Confidence is an output. So okay, this person feels that, like very, very strongly. That is a nugget of evidence. Let's compare it to other nuggets of evidence. Let's triangulate this a bit. Like is it just one person who thinks this really strongly? Is it a thousand people who think it? Oh yeah, that would actually be quite nice. And we build our confidence out there. So confidence, yes, but not as an input. Confidence as an output.

  - Incredible. I've not thought of it quite in that way, in the way that you really nicely articulated it, but I'm here nodding my head off in terms of what that is. It's totally makes sense. Itamar Gilad has created a really nice confidence metre. I'm not sure if you've seen it before, but it attempts to kind of say, okay, well, let's actually make that more empirical. Let's try and make that more objective. And it's something that once I've seen that, I use with my clients going forward to help them with exactly that type of challenge, so. So thank you for mentioning that. Ed, I'm wondering whose advice on roadmapping you listen to or any resources. We've already mentioned Theresa Torres and a few other folks. What really works for you in terms of places where you go to for that type of information?

  - I love your podcast. I'm really, really enjoying hearing the people that you've had on and their perspectives. And before recording, we talked about synthesis and how you don't necessarily have to agree with what everyone says or everything you hear, but it makes that synthesis better. It helps you to spar in your head with your own ideas and to pick and choose little bits. And I know that's cherry picking, right? But it's how ideas coalesce I think, is to get all expert opinions and sort of form your own opinions. So like kudos, like, it's really good. I actually would say that I don't follow very many people on the subject of roadmapping. I like to hear what people who are in product design and product strategy have to say, and then I try and construct an opinion about roadmaps from that. And that's to avoid coalescing around existing ideas, I suppose. Maybe I'm just a contrarian, right? But I think it's important that we sometimes go back to first principles and think about the job to be done and what does the roadmap look like from that. Not necessarily what does the world think a roadmap should be, and let's all be that. So I've already mentioned Jason Fried, David Heinemeier Hansson, the books by the Basecamp guys, "Get Real" and "Shape Up," were formative for me. Like Don Norman's early work. Also a really big fan of Pep Layer, formerly big in CRO. I think he's more of a strategy guy now. But he's one of those walking quote factories. And he said like, "Never copy your competitors. They don't know what they're doing either." He said like, "A strategy is only good strategy if the opposite of it is not dumb." Like he's one of those people who just, yeah, he gets it in a sentence, and I really have a lot of time for the way he thinks.

  - Yeah, that really makes sense to me as well. It's one of the reasons why I'm reluctant to put out roadmap templates because I think if you're doing that, you're missing the point of understanding the job to be done and why, and whether the roadmap is the right tool. It's like putting out the perfect design for a spade when actually somebody needed to be using a fork. It's kind of like, I'm not gonna put that template of the perfect spade out there. You need to work out whether the spade is really what you need. And then if you do, you'll understand what the spade needs to look like for you. And so that's kind of where I go with this as well. I think it fits in very well with what you've shared there. Ed, you've got lots of fascinating insights of things. Is there anything that we should have talked about around the field of roadmapping that we haven't yet?

  - I'd return to the fact that it's very easy for me to sort of sit and philosophise, right, as if I have all the answers and like, I'm just learning like everyone else, right? I have made plenty of mistakes along the way and I suppose to talk a little bit more about what we get wrong sometimes. Like, the biggest mistake I've made in the past is kind of not sticking true to frameworks and principles and trying to be too much of a people pleaser. Like, that is something that's really difficult to avoid. Yeah, like the ability to say no to things is something I still struggle with. And this is a really important thing for roadmapping and for product management, like being able to say no or not now. As soon as your reason or your motivation for doing something is to please another person, in the field of roadmapping obviously, it isn't necessarily a rule for life, you can start to make mistakes. And I think I've made plenty of those along the way, just not necessarily taking that step back, remembering the job to be done. I've designed too many spades when really what was needed was a fork or a pickax.

  - Yeah, no, that's really honest of you. And I feel the same, and I think many of our listeners and viewers will feel similar. It's somewhere where we've been, it's very difficult. It's very emotive. It's very contentious on these roadmaps. But again, like you said, it's opening it up, allowing it to be transparent, allowing it to be jointly owned by people and have that discussion. And hopefully, actually it should be an implementation of the strategy that was already discussed and agreed upfront. There shouldn't be as many surprises on the roadmap as maybe there are today. And so I think we should be doing better jobs there. Ed, we're coming up to time, I've got two quick things I'd love to cover with you. I'm wondering if you could distil your philosophy of roadmapping into just a couple of sentences, what would that be?

  - If I was being glib, right, my two sentences would be, now and not now. I don't wanna be too glib though. And I think just to sort of embellish that a little bit, like, prioritisation is really the key skill here. We talked earlier about the building of getting to the roadmap. How you choose what is in now or what is in not now is the critical thing. If you focus too much on what the roadmap is, then you're missing the hard work beforehand. And prioritising effectively, like using confidence as an output, not as an input, these are the things that will get you a better roadmap regardless of what it looks like, regardless of how well it goes down, it will be a better roadmap.

  - Great advice, thank you. And again, as I've mentioned previously in other episodes, we continue to learn, every episode, we continue to learn. And there's some things that you've said that are new to me or have been explained in different ways that, yeah, I really, I really enjoy. So Ed, thank you. It's been an absolute pleasure. Before we close, I'd love to you to give a chance to tell our audience kind of what it is that you guys do at We Are Systematic and also to let 'em know how they can get in contact with you if they wanna learn more.

  - For sure. I should say, first off, the pleasure is all mine. Thanks so much for having me on. I'm humbled. It's an honour. But yes, We Are Systematic. We are a digital agency based in the UK. We designed digital products of all shapes and sizes. Checks us out at wearesystematic.com, if you are in the mood for some of that. ProductSweet, our product that I've mentioned a few times, that's sweet spelt like candy. So producsweet.com is out in open beta at the moment. I'm specifically looking for product managers, product leaders who wanna be part of that beta, be an early adopter, give us some feedback, be part of kind of creating some of the things that I've talked about. If that sounds in any way interesting or if you just wanna tell me to go to hell, go to productsweet.com, sweet like candy, and, yeah, there's a form there. I'd love to chat with anybody.

  - Yeah, that's awesome. We will be sure to put that below in the show notes. If you're listening on the podcast, we'll put that into our website, talkingroadmaps.com. If you're watching on YouTube, we'll put that into the description as well. But Ed, thank you for being so generous with your time. It's been an absolute pleasure talking to you. And yeah, thank you so much for joining us.

  - Thanks, Justin. Take care.