Should your roadmap include a trash column? | David Pereira

In episode 50 of "Talking Roadmaps," David Pereira shares his insights on agile product management, emphasizing the importance of including a "trash column" in your roadmap with Phil Hornby. He discusses how this practice can help teams stay focused, avoid clutter, and improve overall efficiency. David also reflects on his journey from software engineering to product leadership and the value of learning from failures. Tune in to gain practical tips and thought-provoking ideas for better roadmap management.

David is a product leader with 15+ years of experience. He's sharpened his skills by leading diverse teams, from startups to giant corporations. Since 2020, he has openly shared his mistakes, failures, and insights on agile product management, reaching over 10 million readers worldwide. His thought-provoking courses had 15K+ satisfied students across 100+ countries. Let his unique expertise inspire your journey.

David has also just launched his new book "Untrapping Product Teams" so check-it out ​here​.

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 Adam Davis, he is a Co-founder and CEO at Colab and ex-Productboard. So watch out for Season 1 - Episode 51!

• Transcript

  - Welcome to "Talking Roadmaps," the channel where we talk about everything roadmapping, the good, the bad, and the ugly. Today I'm joined by David. David, can you introduce yourself?

  - So I'm David, let's say a thought provoker, product leader living in Germany now, but I've been doing this game I would say from Brazil to Germany for 16 years, from soft engineer just to C level, different things. So that's something that I do. I also love sharing my learnings and mainly my mistakes. I am not afraid of saying what I did wrong, the good, the bad, and the ugly, and, yeah, it helps me reflect and interact with more people. That's a little bit about me.

  - If you're enjoying the channel, subscribe, hit the bell, and give us a like. So let's maybe dive straight in, David. In your opinion, what's the purpose of a roadmap?

  - For me, a roadmap is about providing constraints and guidance, so knowing what you should pursue in a limited timeframe, but it's a direction, not the what.

  - Love it, and now interesting. I spotted on LinkedIn the other day, you put a message out saying, "A prescriptive roadmap is a bug not a feature." Maybe you'd unpack that thought a little more for us.

  - I've worked for I think 11 companies full-time now and consulted around on 50, and I have seen many things like, what should be in the roadmap? And then people said, "We need this feature. We need that feature," and we start talking about feature, but then we don't even know what we're trying to solve. And the problem that is like we quickly increase commitment on delivering features and instead of collaborating to find out what would help the business grow and make the customers more satisfied, we get trapped on the feature factory. It's kind of having the mindset of creating a project and then you create a plan and you follow the plan. So this should be part of the past. So that's why I say it's a bug and it's a hot fix. So we need to have a roadmap that allows us to do something very important, to learn what works and drop what doesn't.

  - So agree, so agree. Totally. I always thought talk about it being about alignment and communication. It's about that direction, but knowing that we're gonna adjust along the way. And I guess there's a bunch of people involved there. So who's following the roadmap and who's the audience of it?

  - That's quite interesting. It depends who you ask, right? Companies would do that differently, and generally who is following? Like the product teams would be following that for sure, but in the best case, everyone should be aligned because if only the product teams are following the roadmap, what about the marketing, what about operations? So if everyone is pursuing something different, there's a big chance we are gonna conflict with each other and we are gonna compete, because marketing will for sure need something from product and vice versa. So we should be collaborating an overall perspective, and this is what I miss sometimes.

  - Yeah, so, so true. I mean, trying to bring that, those different org teams, whether it's product marketing, whether it's pure marketing communications, whether it's the sales organisation, getting ready for that go-to-market motion of we've got something new. Do we just suddenly arrive with it and throw it over the fence? "Here you go, sell it," or do they need to get ready? Yeah, it's a constant challenge, but I guess someone's gotta own that roadmap, right? Who owns it? Who maintains it?

  - So my perspective would be the product managers should maintain it, but doesn't mean that they should do it alone, and, of course, depends on the size of the organisation. Might be a VP of product, a head of product, but it's on the product side. And why do I say that? Because when that's not the case, it means that the product teams will become more like a service provider, so they start serving the business instead of helping the business grow. So product teams are generally the ones closer to customers, at least should be the case. Then you learn what is necessary and you align with business. So the ownership of the roadmap, in my eye, should be on the product, but crafting that is unlikely to be alone. So there is a strong collaboration with leadership as well as the other departments.

  - So, so true, so true. Yeah, I think, I often in my, I give a talk called Your Roadmap Sucks, and one of my key kind of reasons why many roadmaps are a problem is because it's tricky as one person's artefact when it should be a team's artefact. You're all agreeing to this direction of travel and going on it together. And you hinted there at kind of some leadership involvement. I'm guessing that might involve some vision, some strategy, some objectives. How do they kinda link into our roadmap?

  - That's the key aspect because a lot of times we start talking about the roadmap, where is the roadmap? So we need to understand the big picture of creating great products. So first things first, you need to know where you want to land. That is our product vision. And then you need to know how you're playing the game. That is your strategy. And then, what are you gonna achieve next? That is the roadmap. So the roadmap represents the what you're gonna focus, but you need to have the strategy because one of the questions I love asking when we are talking about roadmap is, how does this item here support our strategy? How does this help us get closer to our vision? And when I have no answers, I'm gonna drop it, or if something is not so relevant for now, I'm gonna put that for later or something like this. But it's very easy to go frenetic on the roadmap without having the other parts of the equation.

  - That kind of driving in a direction and just building features, as you talked about earlier, there's too much demand from that, right? We kind of get asked to go and build something, and we assume it's taking us there in the right direction, but there are product people making decisions all day long. If we can't inspect that thought process of why is this the thing that's on the roadmap and why now, how can we have trust in their thought process? Any more thoughts on that?

  - I'm reading a book from Jim Highsmith. It is "The Agile Wild West." And it's quite interesting because he's sharing these stories, and some stories are from the '70s and '80, but he says in general there are two ways of working. One is plan and execute. So you assume that the plan is right and you execute the plan. So this is what happens with the feature roadmaps. And the other is sense and adapt. So you may start with a feature. I wouldn't say that this is wrong because you have an idea that might work, but the question is, how do you start? If you start building it right from day one, it means it will take a while until you learn. So what I like is accelerate learning. So saying, "Alright, what are we assuming that this feature's gonna give us? How do we test that faster? So let's learn, and if the feature doesn't work, let's drop. Maybe we find something else that works." So this is a better way. That's how I try working this out.

  - Really interesting there, David. So we kind of talked about what's above us and kind of that sensing and adapting or as I think Jeff Gothelf and Josh Seiden called it, sense and respond. My favourite product management book and a guest a couple of weeks ago. What about other artefacts? What else connects to our roadmap?

  - So once we create the roadmap, it's time to start exploring. So I would say you have the things above. So you have the strategy, the vision, and then you go to the roadmap. So the roadmap should be compound of goals. So outcome oriented you want to achieve, and what do you do next? For me the natural step is exploring. So let's run some discovery here trying to learn, and then from there we are gonna create. It depends how teams work, but in general, I would say you go from macro to micro. So you start with a roadmap, maybe it's quarterly base. You may know like what is the direction for six months, but you're focusing on the quarterly vision, so you say, what are we gonna achieve in the next two weeks, maybe the next week? So you start going on micro plans to get it there. So if you're working with scrum, that would be sprint. If you're working with kanban, you wouldn't have the cycle, but you still, you want to see the progress as fast as possible. So that's what happens after.

  - Makes sense, yeah, and I guess that ultimately transfers these into our backlog and the various stories at whatever level of granularity are in there. We've got this artefact. We call it a roadmap. What's actually on it? What are the elements that are in this thing?

  - So it depends who you ask. For me, something that should happen when we're crafting a roadmap, and the most important is not what is in the roadmap. It's what is out. So we need to agree on what we're not gonna do right now because, otherwise, if think that we can multitask and do everything at once, we're just gonna stretch the team too thin, and the teams will compete. So what I like putting the roadmap is goals. Like, what is the direction we're going? Let's say you brought the product to market, and now you prove market fit. The next step, natural, is growth. So you say, "Let's envision growing in the product." And what do you want to achieve? Maybe it's a growth in the quarter of 5% of your user base, for example. That is the goal. How you do that? Then you figure that out. You may say that actually you are not ready to grow because you're receiving too many complaints, so you want to deal with that. You want to increase customer satisfaction or retention rate. So you focus on this kind of metrics of what you want to achieve, and then you start digging down and say, "Ah, okay, to increase retention, maybe we could do this or that," and so on. But these are ideas, and the ideas are the things you could drop. You can keep the, you keep the goals and the ideas you explore with and you can replace them as you learn on the way.

  - Interesting, yeah, okay. But I mean, those goals of like, "I want to grow by X percent," that feels very oriented towards an internal audience. Would I put something different on there if I'm communicating externally maybe?

  - Sure you can have different goals, of course, right? So, of course, I mentioned here an abstract one, but you can say, for example, you understood an opportunity in the market that customers would pay for something. Then you can say, "We enable customers to achieve job X," and you name the job. So customers can do this with our product. So in our case now, for example, I'm working a lot with the maritime industry, which is quite complex, and one of the things that we aim to do is to look at the jobs that happen there, and then we say, "We help yard planners become better yard planners by doing job A, B, and C. We help vessel planners excel in their job." So this is something that is a direction of a goal. How do we know we achieve that? Then comes to measuring, but it's knowing where you're gonna focus on the short term and then saying the things that you're gonna move to later or maybe the things that you say, "You know what? This, I'm not gonna focus. Let's just trash it."

  - Well, you your point earlier of what we're not gonna do. Sometimes, in particular internally, but even sometimes externally, I quite like to put that in the artefact, like, "We've considered these things. We are not doing them now, here's why," so that people understand, so they can understand why we're focusing over here as opposed to on these things that might be the CEO's pet project, for example.

  - Yeah, and I had the situation several times where we would put everything for later down the road. So we would say, "It's something interesting, but let's just put that for later." But the later part became so cluttered that we couldn't even talk about it 'cause it was so full of items. I realised we were just not addressing the conflict 'cause some things nobody wanted to do. Clear example was working for an online wine shop, which in Brazil, we distributed wine all over Brazil, and we were trying to increase revenue. There were some conversations there on, what if we make some advertisements? We allow wine suppliers to advertise there. But that was contradictory to our value proposition 'cause we wanted to help people find the wine that fit themselves, their taste, and so on, and if we start pushing that, then it's different, but no one was actually challenging this. And then I said, "Ah, we need to do something about it," because every time we come to a roadmap discussion, we are evaluating if we're gonna put advertisement or not. And the general takes 20 minutes of discussion to say no. And we were eight teams. There were eight teams talking about it. And I said, "That's not fair." Said, "Let's put the trash column here, and let's make some informed decisions." And then I remember the COO saying, "We should never allow this because actually it's contradictory, so let's trash this decision because it's conflicting with our unique selling proposition." Said, "Alright, so someone is talking now," and then we managed to put trash. And I like saying back then that let's increase the size of our trash bin, not the roadmap.

  - I love it. I love that idea of, should you have a trash can on your roadmap? It's like, okay, in a similar principle, what I quite like, or similar vain, what I quite like is the idea of product principles, that Meriton talks about, and those being those kind of pre-made decisions, those decisions you come back to time and time and time again, and instead of having a short decision about it regularly, let's pause. Let's really have the debate, let's make that clear choice, and then we enshrine it as a product principle so that when we find ourselves at that same crossroads again, we already know the answer 'cause we've made that clear choice that this isn't something that's right for us because it doesn't align with our principles.

  - Exactly, and we need to make these hard decisions because I generally say that not making a decision is worse than a bad decision because a lack of decision is analysis paralysis. We discuss in circles. We don't progress. And making a bad decision, you learn about it. So you move on, and if in the future you realise, actually, it was a mistake, okay, then you decide against it and then you try it out, but discussing every quarterly about the same thing, it doesn't make sense.

  - There's a number of companies these days that kind of do these calculators for how much you've spent in a meeting. I could imagine rolling that up and saying, "How much have we spent talking about this same issue over the last 12 months?" So I love this idea of of putting the trash and the kind of the later and so on on there. Do you have a preferred way of visualising your roadmap? Is there anything, any particular way you do that? And I guess, similarly, any particular tool you like to use when doing that?

  - That's interesting. It, of course, depends on the company size. So I try making the roadmaps as flexible as possible but transparent as well. When I worked in the office, roadmaps would be in the teams room. So we would have that in the whiteboard, our roadmap, and we would continuously adapt that. It worked fine because everyone who would walk where we were, they would see that. But nowadays, it's not like that. Teams are remote, so it's another thing. So I like using, if it's a small company, I like using like a whiteboard, like a mural, like a tool like this, for example, because then you can put there and so on. Another tool I like using if it scales a little bit and then you want to have different roadmaps. Maybe for your customers, you don't want to share everything that you're doing. You want to have a roadmap for them that is reducing some things you're gonna address. Maybe one of the aspects is reducing the technical debt you have that is causing, it's get in the way of scaling. So for this I would go with our focus, for example, so you can have different layers there. So our focus is a tool I like. I like also product plan. So but in general I say it's about keeping it as simple as possible yet transparent. Everyone should be able to see it.

  - Totally agree, yeah, and the one risk of a virtual whiteboard is I think you lose something of that design wall style that you used to have when it was on the wall. It's like you can't just walk past it and absorb the information. You have to actively go and look at it. But I'm a big fan of that approach as well.

  - Yeah, it's a kind of a pity. I haven't found the solution I like the most working remotely because of this, the same thing you said. In the office, you just walk, pass by, and you would see, and then you decide to look at. So when you have a board, a whiteboard like Miro, you need to decide to go there, and not everyone goes there. One thing that I suggest is keeping that alive. So when you communicate the results of your sprint, send a screenshot of your roadmap as well. When you are presenting your sprint review or product review, say, "Hey, let's just have a look on the roadmap and talk how we progress here." Keep it alive because if you don't keep it, then for sure people will forget it. And then it's the moment they start saying, "Hey, I have this feature here, can you deliver that? "Ah, I thought you were not following the roadmap anymore. You didn't talk about it."

  - Yeah, it's a super powerful tool, like any sort of, like those like design walls where you have personas and sort of user story maps and so on, on the wall as well. They're so powerful to kinda stand by when you're making those decisions 'cause kind of the, not, it's almost like you don't even need to read it. It just reminds you by seeing that visual on the wall of the thoughts that you've already had. But yeah, having to go there actively can be a challenge. I sometimes think I should have another display in my home office that just has that sort of information on it permanently so I'm kind of, so it's like I've got a whiteboard in the room.

  - Something good, yes. I used to keep some Post-its on the wall, but somehow I stopped doing that because they were just falling apart, so I need to to improve this, because I like taking the paper and so on. And it's like you mentioned, what comes after the roadmap? There will be a backlog, and the backlog I would do the same. I wanted something simple 'cause the idea of one of the most common ways of populate the backlog user story was you keep simple. It's a card, conversation, confirmation, but it transforms into something else. Then you see backlogs with a lot of details and so on and people unwilling to remove that. And the beauty of having just a Post-it, it's like you look at that and say, "Hey, this doesn't serve me." You just throw it away and you don't care a lot because it's just Post-it. But if you have digital, I don't know. We think it's a lot of work, and we don't want to waste work, but then we waste our time by doing work we should not be doing actually.

  - I think there's a lot of truth in that. Like backlogs and the stories in them have just become so large. It almost feels like revenge of the business analyst, the kind of that deep technical analysis work of doing full use cases and so on seems to have made its way back into the backlog, whereas it should be just a placeholder for the work and a placeholder for our common team understanding. So let's take it a different direction now, David. Let's go a little higher level. What is best practise when it comes to roadmapping, in your perspective?

  - So the core of everything is collaboration. So it's getting together. So to talk about best practise is important to talk about bad practises. So bad practise is a top down. So for example, I have seen roadmaps totally created by top management. They would sit down, they would agree on what needs to happen for the whole next year, and inform the team they have to do it. And then, of course, the team would be, let's say, not so friendly and wouldn't commit to that. They would do whatever they could, but they were not part of it. So this is something tricky. For me, a good practise is when management sets like, "Hey, this is what we have achieved. That's where we want to go." Maybe they want to expand to new audience, so, "We want to explore new markets." Or maybe we say, "We are suffering a lot. Our customers are leaving us. They don't see value in our product. We need to change it." Or maybe, "We are facing momentum. We want to benefit from this momentum." So set the context. Management sets the context and what is important as well as what is not important. And then it comes something that is often ignored, which is a trade off, because there are some things like, what are we unwilling to sacrifice? We need to know that. And what are we willing to sacrifice? In some of the startups I worked, we could sacrifice profitability because we were trying to prove our product would deliver value at all, so we had investments for that. In other situation we couldn't, but we had other ways to play. So you need to know that. And then jointly the team will start saying, "Okay, where we can go?" and you can craft a roadmap very simple. I like using the no, next, later, a little bit adapted. As I said, I add the trash column. So I think it's a simple format because it's pragmatic and you can quickly adapt that. Intentionally, I generally make the board small enough so we don't over pack that. So that's my general idea, but it's collaboration at the end of the day. So someone setting the direction and together crafting a roadmap and working towards it.

  - I love the idea of that trash column. I sometimes have a never column or if I'm presenting externally, I might have a previous or last column, so what have we just shipped? To help people remember that they can have a load of value today. They don't have to wait for that even now to be delivered.

  - That's interesting, quite interesting, because people tend to forget very quickly.

  - Exactly, and in B2B, which is where I've spent most of my career, there's too much of an excuse of, "Well, let's wait till the next thing is delivered before we place the order," when there's a tonne of value available right now. So you already went to my next question, which was, but the bad practise or the anti-patterns. But do you have a pet hate, something you really just, if you see it on the roadmap, it gets you upset?

  - If I see features there, and if I see features without the relation to a goal. There are two things I do. So if I'm consulting a company, the first thing I ask is to see the roadmap 'cause that will help me understand how they think and the stage they are, 'cause then I need to decide if I'm ready to consult them or not and if they are open for some things. And when I'm, not now anymore, but when I was interviewing for product manager some years ago, I would say, "How do you craft a roadmap?" I would ask this question. I would say, "Can you give me an example what is in the roadmap right now?" And if I realise there is a set of features unrelated to each other , that is the moment I start panicking.

  - Sometimes it's just a list of requests from the HIPAA or the requests from the customer that will close the deal instead of a cohesive story for the market of how we're gonna deliver value and drive those outcomes. So, David, we've had a bunch of your thoughts and advice on roadmapping. Whose advice on roadmapping do you listen to?

  - A lot, actually. I'm thinking I like a lot what Maarten Dalmijn says. Also Anthony Murphy. Martin recently wrote his book "Driving Value of Sprint Goals," which was way beyond that, but he shared a lot, something like about the roadmap circus. I like pretty much what he said there. Anthony Murphy, also from Australia, he has a lot of ideas of different ways of visualising the the roadmap 'cause there's no such thing as one size fits all. Organisations are different. I try making it simple because in the end of the day, the way you present is not, the most important is what you agreed is the alignment you created. The other's just representation. But I like what both of them share, Maarten Dalmijn and Anthony Murphy.

  - David, I know you've got, you've just signed a book deal recently, so maybe you could tell us a little bit about that and what you're planning to write about or have already written about.

  - Yeah, that's a quite interesting idea. What happened is I have been dancing around this idea of writing a book. So we chatted before, Mind the Product and ProductTank. So I got convinced about writing a book. It was actually at the ProductTank in Munich in April. So some people approached me there and so on. They said, "Hey, where's the book?" I said, "What book? I'm not writing any book." And then I got quite excited, so I started writing after that. I started writing, and I treated my book as a digital product. So I explored that with many people. I changed the ideas and so on. And the book is actually called "Untrapping Product Teams." And why am I writing about it? Because what I realised throughout my career is like that many teams are trapped. Sometimes they know and sometimes they are unaware of, and what I do in the book is helping them understand. So it's three parts. First is like facing reality, which is about understanding the traps, then you can decide if you are in or not. And the second is overcoming the traps, so what do you need to do to overcome them? What could you do today for a better tomorrow? And the last part is, all right, I'm out. How do I remain free from traps? So it's remaining untrapped. So it's three parts. Book is already written. I have a manuscript reviewed by several beta readers. I thought initially about doing self-publishing, but as I got a nice book deal, I thought it would be best for the future of the book to increase quality and ensure that it is ultimately, let's say, reliable, so that's why I'm gonna go with the publisher. And ideally it's out somewhere, somewhere next year, latest in fall, I would say.

  - I reflect very much on that journey of thinking, "Oh, I'm not gonna write a book. Maybe I should," and starting, I started about a month ago on mine as well, which I still need to find more time. I decide I'm gonna write one chapter and an outline, and if I feel I can get enough from, enough through that, then it'll gimme the confidence. I can go and write more. Very much planning a writing in public kind of approach, which Rob Fitzpatrick is also a big fan of. He has a an interesting book called "Write Useful Books," achieving outlines and approach for doing that, which I'm a big fan of.

  - That's super cool because actually I followed this approach. So the beta readers, all of... I'm using his to help this book . So I have some people giving feedback. And when I compare the first version of the manuscript to the current one, it's another book. So I changed many things. I dropped chapters, I created other chapters, I removed the clutter and so on, so now it's getting to a stage that is more rounded. Then I feel like, "Hmm, it's getting to the moment of polishing." First I was searching for the book being desirable, engaging, says, "Ah, okay, now it's developing," but it's a lot of learning. It is a nice journey. So you learn about your writing style, what speaks to people and what doesn't, and then you can make it sharper.

  - I've been a beta reader for a number of people over the last year, going through the same process. It's interesting to hear you've done the same approach. Always like to save the hardball questions for the end, David, so we're kind of getting there. If you had to distil your philosophy on roadmapping down to one or two sentences, what would it be?

  - So let me think about this one. In one or two sentence, I would say, what is the one thing we need to do right now that we will ensure we still go in the direction that we want to achieve? This is the core that we want to do. So it is about making the tough decisions on the core and focusing on that. So one of the key aspects of the roadmap is remaining true to your value proposition, and it's very easy to forget about why we exist in the very first place. So we start talking about all the features of everything and then we try serving everyone. The good product is clear on their ideal customer profile, and you make it best for them and then you make decisions on this direction. So I would say, what is the one thing that we could do right now to make our product better and take from there. You might have space for a little bit more, but just focus on uncovering this one thing, and that is what matters. Keep true, remain true to yourself.

  - And then the question I always like to end on, is there anything else about roadmapping I should have asked you that I haven't?

  - There's a confusion that happens very often with people. They say, "How we are using OKRs, do I need a roadmap? Don't I need a roadmap? Is the OKR the roadmap? So how do I do with this?" So it's a general confusion, but I would maybe ask you, what is your take on that ?

  - So my view is that they work wonderfully well together. The OKRs, maybe my objective, depending on how we play this, whether we have a long-lift objective that maybe lasts for a year with KRs that are reviewed every quarter, those KRs start to help define what does good look like over the quarters or in the now, next, and later timelines. The objective or objectives start to maybe create some of those themes of where I should be looking at which initiatives align, and, therefore, can be justified going back to my objectives or my OKRs and show that I'm following an aligned direction of travel. That's my view on it. What do you think?

  - Yeah, I think it depends also on the size of the company. Sometimes I see organisations introducing too many frameworks upfront. For example, OKRs plus roadmap in a startup quite small, I think it can be more distracting than helping 'cause if you use... Just one or the other could be enough. So if you have just the OKR, that could work. If you are small enough, then you can align and continue moving on, 'cause in the end of the day is about setting the direction and ensure the teams are learning, 'cause it's all about, it's a journey, right? So what is working in this journey? Are we still on track on the right direction, so on?

  - I guess I'm a big fan of outcome-based roadmaps, and as my outcomes tend to be defined as OKRs, they naturally just kind of come together. So David, it's been an absolute pleasure having you here on the show today. Just always like to give people an opportunity to make their pitch. How can they get in touch with you? Where can they find you? How can you help?

  - You can find me on LinkedIn, David Pereira. You can also subscribe to my newsletter on Substack. It is dpereira.substack.com. It's for free. You can benefit from the content. And if you wanna know more about the book, in my newsletter, you'll see there the link. You can just join the waiting list, then you'll hear from me as soon as it's available.

  - David, it's been an absolute pleasure talking to you today. Thank you very much.

  - You're welcome. Pleasure, mine.