Roadmap principles or practice, what matters? | Andre Albuquerque

In episode 18 of Talking Roadmaps, Andre Albuquerque shares his insights on balancing roadmap principles with practical application with Phil Hornby. Andre discusses key strategies for leading product teams, the importance of adaptability in product management, and his experience in growing startups from inception to acquisition. He also highlights his work at Kitch and the recent acquisition by Glovo, providing valuable lessons for aspiring product managers.

Andre is an operator experienced at leading product management, product design, engineering, growth, product marketing, and product operations teams. He's built products across different startup stages (0-to-1, bootstrap to $30M VC funding, founding to M&A), and hired & managed from 1 to 50 people within cross-functional teams in companies from 4 to 300 people. He's shipped mostly around 2-sided marketplaces (both B2B and B2C), SaaS, product-led growth and integrations-based products. Finally founded his own company, bootstrapped and achieved profitability.

Andre is currently leading product, design and research at Kitch where he joined in the founding team, and helped lead through the acquisition by Glovo/Delivery Hero. He also founded One Month PM, a product manager acceleration program, teaches Product at the University (MSc and Exec Ed), advise the portfolio companies at Shilling Capital, and writes his own 0-to-1 product thoughts.

“Abstract the principles from the practices and adapt to your reality”

— Andre Albuquerque

Have a watch and if you enjoy the video don’t forget to subscribe to the channel, like it and maybe sign up to our mailing list!

Here is an audio-only version if that’s your preferred medium - and you can access it through your favourite podcasting platform if you prefer (Apple, Spotify, Amazon).

Next up we have Petra Wille product leadership coach, author of STRONG and curator of the Product at Heart conference. So watch out for Episode 19!

• Transcript

  - Hi everyone. Welcome to, "Talking Roadmaps." The channel where we talk about everything roadmaps from the good, the bad, and the ugly. Today I'm really pleased to be joined by Andre. Andre, please fire away and introduce yourself.

  - Hi. Thanks Phil. Appreciate the invite. So my name's Andre, currently VP of Product at Kitch, Food Tech startup trying to reinvent how delivering food is done directly with restaurants. We now belong to Glovo, one of the largest unicorns here in Europe. We were just acquired a couple months ago. I'm currently leading product, design, research and delivery. Super lucky to have a really talented team with me. Apart from Kitch, I do quite a few other things. So I run my own programme PM accelerator called One Month PM. I also teach at university, lucky to design a course around product management for master students, which is pretty early in the education. Not a lot of colleges have this. And then finally I advise a bunch of startups at the venture capital firm here based out of Portugal investing in seed and Series A. So that's in a nutshell that's basically it.

  - Perfect. So as always we're on a YouTube channel. I do have to ask everyone out there to like, subscribe, hit that bell icon if you want to hear more. As we're recording this, things will go out in a few months. As we're recording, we're about to cross the hundred subscriber threshold, which I know is not huge, but actually it's a great milestone for us. Yeah, I guess I remember reading one of your posts on LinkedIn and it talked about three track roadmaps and that kind of peaked my interest as I'd love to have a conversation with you about roadmaps 'cause that's really our subject. So let's take it back to the real basics of roadmapping. What's its purpose? What's it for?

  - Yeah, sure. So I think it's very simple. Though a lot of people get this wrong. I think roadmaps are just a communication tool, right? It's all about aligning expectations. It's a way to explain to everyone who is either impacted or interested on what is the plan and what the product team, ideally the product team. Though I argue a lot of teams can have and should have roadmaps. But on the product side, what is the product team committing to deliver and solve and learn in the next X amount of time? It can be a quarter, it can be six months, a year, it can be a month for early stage, for example. And what the other teams should expect, what they can also not expect because what isn't coming is also a really important feature of roadmaps. And that allows people to prepare and to be ready for whenever that thing that is committed in the roadmap goes live, goes into production or even earlier, even if it's just going to a limited amount of users or customers. So that the rollout, the actual go-to market is effectively done. I say this for two reasons. One, in the end of the day, I believe products a vehicle of value, right? That's the way you deliver value to customers. Therefore everyone's surrounding product are drivers of this vehicle. So the roadmap helps them understand where the car is going, at what speed and when is the car arriving so that the drivers can prepare themselves so that they can drive value to customers. The other thing I believe it's really important in this definition is that roadmaps being a tool of communication, that means they're not the end goal. They're not the thing that product managers or product builders are building. What they're building is the product. The roadmap is just under another step. It's, as I said, a communication tool. It's a mean to an end. So I think that's it. That's how I in a nutshell, kind of resume roadmaps in my mind.

  - I love that kind of thought of roadmaps going beyond product people. I think that's very, it's a great concept and it's definitely something me and my co-host are definitely also on the same page as you there with, but I guess in the product context, it tends to be the product team. But just to be sure when you say the product team, who do you mean?

  - Yeah, so the product team, I define it as everyone who is directly involved building, shaping and delivering the product. In my case, in my companies, that includes product management, product design, product research, delivery management or QA, quality engineering, quality assurance, engineering, software engineering data platform. So every single part that is or person that is contributing to building the product, that for me is part of the product team. Of course then you have these sub-teams. And all these teams are actively contributing and executing on that roadmap. So yeah, that's kind of how I define it.

  - But is there anyone in particular in that team who does the maintenance?

  - Yeah, I think there's not one person. It's easy to say, yeah, the product managers in the end of the day are responsible to delivering the roadmap or writing it up. I think it depends. I think each organisation has its culture and I think some cultures might work for some organisations, others might work for others. What I believe is, I like to empower every single person member of a product team to be an owner and to contribute their own way to the roadmap. And then it's all about an agreement, a collaboration on who actually gets to type in what the roadmap will be. Whether that's the PM, whether that's an agreement between the product manager and engineering manager, lead designer. So I think it depends a lot. Some of the companies even do it kind of on a bottom up meaning that people design the roadmap but then it's actually the product leaders or product leader. If you have a head of product CPO or VP product that ends up actually designing and writing up the roadmap. 'Cause in the end of the day they are the accountable party on delivering the roadmap to leadership, to board, to investors, whoever. But I think it depends a lot on the culture. I think for me that part is less important. What's more important is that every single person feels and is an owner of contributing and designing and buying in into the roadmap that the team is committing to.

  - Now you've talked about a few audiences there though. So who's looking this river? Who is the actual audience?

  - Yeah, so I think as I said, I think it's everyone who is either impacted or interested. What I mean impacted means imagine you're a sales team and you're trying to sell a product. So your roadmap is gonna directly impact your ability to sell and also what you sell, right? So that's an impacted party. Marketing team would be an impacted party. Operations team would be an impacted party. So roadmaps are for these teams who will either have their jobs maybe harder, for example, usually tell the story. A lot of people think about roadmaps as just improving everyone's life. So that's not true. Oftentimes a roadmap which adds new functionality will negatively, I'm gonna quote, "Negatively impact," the customer support team or an operations team who now has to deal with new functionality, with new complexity, with new customer requests, with new segments, whoever. But then I say like, it's about the people impacted by the roadmap. And then I say the interested parties. The interested parties are, for example your board or your investors or people who are looking to participate or follow the company. They're not maybe directly impacted, maybe they're indirectly impacted whether because the company becomes more valuable and they get more value out of that, but they're interested in understanding the roadmap and making judgement or understanding if the company is going the right direction. So I think roadmaps are for these people if you get to consume something out of it. And then I don't know if it's impacted or interested, but there's a lot of companies who building the open, right? So they have their roadmaps public ahead of time as well. So the open roadmaps, like you have your open roadmap and people can see it, they can contribute as a community. I think this like in the Web3 world is very common, but then there are companies who kind of present the future roadmap ahead of time in conferences and that's a great way to get feedback, to get excitement to measure the pulse of the market around what you're building. And also get earlier feedback built into the product that's still being built and delivered in the next time. Like, so I think, yeah, I qualify quantified people impacted or interested by roadmaps like this.

  - I was a little worried we weren't gonna get to customers there, but then we got there right at the end and 'cause I mean it's a controversial subject. Not everyone shows their roadmap to their customer. It's always been something I did and so I've always found it an interesting conversation when people don't, 'cause they are impacted and they are interested.

  - Yeah, well they're impacted. I argue if they're interested. What I mean with this is the customers have a lot more problems in their minds than your roadmap, right? Like they kind of don't care. They care about their problem and they care about making a simple, convenient, easy solution that's value for money to solve that problem, right? They don't care if this is the plan and this is when you're delivering and this is what the scope looks like and this is what the feature will do, I don't care. I care about, I have a problem, I find a problem, sorry, I find the solution. I see if it fits the amount of money I'm willing to pay, the amount of effort I'm willing to put, and the amount of learning curve I'm willing to endure. And then I make a decision, right? So I think impacted yes, but more in the sense of like, okay, now I have this available and I can use it and I become a customer. I keep being a customer interested. I don't know, I think I'm a bit sceptical about the roadmap in the open. I think it's on one end it's really cool 'cause you get like open feedback but on the other end you're gonna get feedback from power users and oftentimes that power user isn't that representative of a larger majority or a at scale customer. The at scale customer is very different from a power users. So if you only get feedback from power users, are you really building to like cross a cast in there? I don't know. So again, I agree on the impact is I argue against the in interest.

  - For me, so I've typically been in B2B and there I think maybe the more interest comes in 'cause it's about aligning journeys together. Okay, so we've got this thing, it's driving us forward, it's taking this direction. How does it line up with vision, strategy, objectives, other things around it? How to interrelate?

  - Yeah, so I think that's a great question especially because majority of people jump straight into roadmap 'cause it's easier to plan. You're used to doing plans since a kid, right? You're planning your weekend and you know exactly what you're going to do. And you don't think what comes before that plan. Because as a person you're not thinking, "Oh, the vision for this weekend is X and the strategy to achieve the outcomes of this weekend is Y, and that's why this plan makes sense." Which you don't think like that, right? But in product and roadmap you kind of have to, right? So a few backup of napkin definitions are, so vision is where is the future you want to get to, right? It's like the story you wanna write. It's a place, it's success. It's how you wanna see the world being shaped. To get there, and by the way, objectives is how you quantify whether you're getting there progress, right? If a certain metric, a certain number, a certain measurement is moving in the right direction, ideally if you pick the right objectives that quantify that vision, then ideally you're getting closer to that vision. And the vision should be farfetched should be done in the future, right? So when you have these two inputs, the vision and the objectives, you kind of have to design a strategy. And the way I define strategy is, you have a bunch of opportunities, right? Those opportunities are derived from the problems you see between where you stand today and the vision, right? There's a bunch of problems that are keeping you from getting there, right? The way you turn those problems into opportunities are how do I solve these problems, right? But you have limited resources, you can't tackle all problems in X amount of time. Like in infinite amount of times you can solve all problems. But in X amount of time, which is basically defined by your runway, how much money you have and time you have to fix those. You only have a set of problems, therefore a set of opportunities. Strategy is the number of opportunities within the resources you have that gets you closer to achieving those objectives and therefore progressing towards your vision, right? You've gotta pick the right opportunities. That strategy, that choice of opportunities, your rationale behind that choice of opportunities means strategy. And then roadmap comes as what is the best plan to seize the opportunities I picked with my strategy? That's roadmap. That's why it's really important to do vision, objectives, strategy before you do roadmap because you gotta understand where you're going. I usually say that, look, imagine you want to go from A to B and you have a GPS. I mean it's not about going faster if you're in the wrong course or in the wrong, in the wrong highway. You're gonna go faster. Yeah. But you're gonna go in the wrong direction. Just picking a roadmap it's just picking a route. Doesn't matter if you're going the right route, you just accelerate and not gonna get there. I think vision, objectives and strategy makes sure you are going in the right direction and you know you're going in the right direction.

  - I can feel like the whole kind of going on a journey roadmap and my destination kind of metaphor building up there. What about other artefacts? Other things that link into the roadmap, you know, because I guess we've talked about the front end, the high end side of things. What other artefacts link into a roadmap?

  - Yeah, so I have this concept of triple track roadmapping you mentioned earlier in the conversation. So the triple track is like, it's a bit of a pun on the dual track, like the agile framework. The triple track, the way I see it is I think at any given moment in a roadmap, there are three tracks happening, right? And I believe as well track they need to be owned by everyone in the product team. And these three tracks are discovery. So the discovery track is where you're learning, right? You're discovering, you're asking questions, you're researching whether the opportunity is the best opportunity to achieve a result. Whether certain solutions can fit that opportunity and can solve the problem. So trying to learn, right? That's one track. The second track is the build track, right? And it's very inspired on the base camp book on these tracks and the build track is where you're developing the solutions. Ideally research has leaked into build because you got to some answers on your key questions that tell you this is the solution or this is the set of functionalities and solutions and scopes that allows us to capture the opportunity. And this is the build. Its where you're executing. And then you have the measurement track. And the measurement track is where you're measuring what you've built in the past that are now yielding results that are telling you whether your decisions were the right decisions towards that strategy. Are you capturing the opportunity? Are you solving the problem? Are you moving the metric? Are you getting closer to the vision and that you're measuring. And that measurement is feeding the discovery track. So it kind of loops back in and telling you, okay, this is what we learned and this is how we either course correct or double down. And that course correction or double down leaks again into the build track. So you have these three tracks running in parallel and ideally either by the end or beginning of a quarter, they should kind of revolve on itself and feed into the next quarter or the next time box. Maybe you don't work in quarters, but the next time box to tell you, okay, this is where we're gonna build. So usually these three track sets, things that the entire product team should be doing, not just single roles. I believe in a lot of empowerment full stack across everyone and I think every member has a part of discovery in their work, a build part of their work and a measurement part of their work, which ideally loops in between itself to yield a stronger, greater roadmap to achieve the objectives.

  - One of my little sort of things is I think there's even an explore track before discovery to actually find those problems that you're gonna pick to then discover the details on.

  - Yeah, I think that's a good point. The reason why I don't have a sort of an explorer, I might put it within the discovery is more while look that exploration, if it starts on the strategy meaning, okay, let me look at the problem space, right? Looking at the problem space because I understand my customer. I understand where they sit, what problems I'm trying to kind of solve for, or at least the purpose of my company, the mission, why I exist. Ideally have an entire view of the problem space, right? And as I'm going through the problem space, I'm discovering what the problem looks like. How the problem could be solved, how other people are trying to solve that problem, how my customer is choosing solutions to solve their problem. Today I generally say like all problems have been solved, most problems have been solved ineffectively and inefficiently. That's why you have innovation, right? So I think exploration is a table stake process of understanding the problem space and then bridging into the solution space. But I think it's a fair point. I think you can't just be in that loop of like, "Oh, I'm just gonna incrementally add more into the product." I need to explore and kind of stretch the boundaries.

  - Okay, so let's switch gears a little bit. We've talked about what links into it. What about the design of the roadmap? What are the key elements or content that we're gonna put on this thing?

  - Yeah, so I think that's a great question. I don't think there's a playbook or a one way to do it. I think that's the cool part of asking that question is like you get to see the point of view of different people, right? I think part number one is, I think it depends a lot on the audience of the roadmap, right? Different audiences will look for different things in that roadmap. Remember, if a roadmap is a communication tool, then you can see a roadmap as a product. I usually say the roadmap is the product leaders product and the audience is the customer of that product. And at the end of the day, you also wanna achieve product market fit of your roadmap. Product market fit here means your audience understanding the roadmap and being able to be effective at acting based on that roadmap. That means product, market, fitness of a roadmap. And for this you need to understand the audience behind. So, and also there's multiple audiences and multiple ways of roadmap and impacts and audience. Let me give you a couple of examples. If you're presenting a roadmap to a board or to investors or even to a leadership team, even if it's an executive leadership team, that's one type of audience that looks for something. If you're presenting a roadmap to middle management or even individual contributors, I think that's a different type of audience. If you're presenting to customers, to people who will eventually be impacted. And that's another type of audience. So the artefacts that go into designing and presenting a roadmap is different based on who's on the other side. So now going very specific on these three audiences. I think if you're presenting to words and or leadership or investors, you wanna tie the roadmap directly to specific metrics to results that you wanna achieve. You wanna tie it to the business strategy as a whole, like a high level 10,000 feet high overview. And you probably wanna link key pillars. Key pillars meaning specific high level, impactful needle moving initiatives that kind of represent the majority of your roadmap, but not the turpentine like the on the grass level. Like you don't want that for that level. So you design the roadmap based on this. If you wanna go for management or management like middle management or ICs, probably you wanna focus more on the deconstruction of those pillars into the initiatives and what specifics you're gonna put there. Because these people will be looking for this. Will be looking to know how I'm gonna act? When can I expect this? I have certain problems. And for customers, you probably wanna present the roadmap as a storytelling, as a narrative, as a way your company's evolving getting closer to what they are going through, how they empathise. Like creating that like narrow that gap between where I am today and how more successful I'll be tomorrow because of this product. These are three ways of designing and presenting and building a roadmap. They are three different ways and I have this concept of like creating product market fit with your roadmap depending on the audience.

  - Do you have any preferred words of actually visualising that then maybe different for the different audiences?

  - I'm a huge fan of Notion of the tool because I think it's super flexible. Allows everyone to collaborate in a really great way. So internally we build, I might write about this in the future, we built a framework, a template on Notion to build up roadmaps and to have the roadmaps available in real time across the company. Every single person can access the roadmap at any given time and understand the state. This kind of, so I try to... As I said, like I look at the roadmap as my product as a product leader and I need to achieve fitness, right? So I looked into the problems of roadmaps in the past and a few problems I identified were one, people want to understand at where does the roadmap stand in real time, like right now. We presented a roadmap in the beginning of a quarter, we're mid quarter, like what's done? What's not done? How we're progressing? So people wanted to understand that. Number two, people wanted to, depending on your audience, you might want to stay high level or you want to go deeper. So sometimes if you have a very static roadmap, like it either shows like the main initiatives, but then how do I know more about this if I'm like being impacted? Or if it's like too detailed, an executive goes there and it's like, "Wow, this is way too much. I can't even understand where we're going." So we needed to create that flexibility. And number three, it needed to be easier to update because in the end of the day, your product team is also working on the product roadmap, right? And they have a lot of stuff to do if they're also having to tailor, snip, design roadmaps and update in real time. Like they're doing twice the effort and I want them to be focused on customers, on research, on problems, on delivering the roadmap rather than just having to write new presentations all the time. Like it's just a waste of time. So we built a really cool template on Notion which links all the epics and the initiatives. If you go into the details you can see the actual discrimination of scope or problems you're being solved, how you measure success. But you can go up and see like different tables divided by the different teams, their narratives, north stars and scopes of those teams. How they tie up like kind of the branch three into the company strategy, the OKRs. And as they update the states of the initiatives in real time, everyone can go there and see what's being done, what's in progress, what's being scoped and research. And all is within Notion accessible for the entire company at different levels. So I think it makes it super easy for everyone to use. So that's my preferred way, but that's helpful for number one and number two. So maybe board, well board I would actually step back and present it in a different way. Like presentation 'cause they don't want actually have to go to Notion and click down and understand. I think that's too heavy for them. And the same for customers, like for customers like you wanna do a presentation, a narrative, a storytelling, right? So I'd say like I invest a lot more on the actual execution of the team. So I think it works really well for leadership management in ICs. And then for boards and customers I would like tailor and design a presentation narrative that focuses on the attention span of these audiences.

  - And I was about to ask you what tools you like, but I think I've got the answer there already. Okay, thinking about the roadmaps then, what do you consider to be best practise in terms of content on that roadmap and what do you consider to be bad practise or anti-patterns?

  - A bad practise is having a roadmap solely focused on solutions like we're shipping feature A, B, and C. Because depending when you do the roadmap. Let's assume you wanna do a roadmap in the beginning of a quarter, right? And let's assume your rather early stage, right? The likelihood that if you're committing to a quarterly roadmap, which for early stage is actually quite a long time span. The likelihood that you do not know what will be the solution for a problem that maybe you know now or at least an opportunity that you understand matters is actually quite low. You're probably going to take a couple of weeks or even through the month or through the quarter to understand what the solution will be. So you have two options, if you're only committing to showing solutions the roadmap, you're not gonna show a solution you don't know in the roadmap. So people won't know you're gonna be tackling that problem or opportunity. Your option is you include opportunities or problems within the roadmap, alongside solutions where you have more visibility to people so people know what you're gonna be tackling throughout the quarter. So I think a bad practise is only going for solutions. A good practise is understanding a roadmap is fluid and can have both solutions problems or even opportunities that you wanna tackle through a time box. I think another bad practise is not caring about the audience that's going to read and consume the roadmap and going super technical on terms that the product team does understand. And puts it in a roadmap in a way that it's okay for the product team. That's actually a bad practise because the roadmap isn't for the product team per se. The roadmap needs to be understand by those who the roadmap is gonna impact or interested by. So you need to design and write it in a way they understand. You have other mediums and artefacts and ceremonies for the product team to transform that roadmap into execution. Whether those are epics in your Jira board or stories or whatever you use doesn't matter. But you need to understand that the roadmap is more for the audience where you want them to act on your delivery rather than yourself. I think of course you're gonna use it then throughout the quarter to just measure progress and your own executive, your product leaders need to understand that and have to have those that spectrum. But I think like not caring and being super technical there, it makes you lose your audience and then your roadmap doesn't have product market fitness. So I'd say I would highlight those as like my two bad and good practises around roadmap.

  - Fundamentally, if I go back to your first comment, the purposes for communication, well yeah, communication is for the audience as far as I'm concerned 'cause it's to get the message to them. I think I was just reading one of Nancy Duarte's presentation books only yesterday to write review about it and audience is section one 'cause you've got to start there to know who you're communicating to. Is there a particular pet hate, something you just absolutely hate to see on a roadmap?

  - I don't think I have something because I think it depends a lot on the teams and the people behind that. I think like one of the things, there's a bunch of principles that I like to follow, right? One principle actually it was funny because beginning of our conversation, even before recording, I arrived earlier than the time I said I was gonna arrive. And that under promise over deliver is something that when I don't feel is being followed in a roadmap, it really gets under my nerves. So when I look at a roadmap and I immediately see people over committing and it's kind of obvious that is overcommitment. Whether because we know the team won't have the capacity or because statistically if you look back at the last few quarters or even year or so, the delivery of that specific team was below what they're trying to commit for the roadmap or they're leaving too broad for something to actually be achieved. They're already like they're over promising. So it's basically impossible for them to over deliver. More likely they're gonna under deliver. And if that becomes obvious at a roadmapping moment, it's only gonna get more obvious as the roadmap progresses, right? Because in the end of the day there's a last fallacy where today is the day you're the most wrong about your roadmap, right? The day you ship is the day you're the most right. Now the question is how right are you in the day you ship versus the day you believe when you planned it, right? So I think that is one thing that annoys me. Is it because is it if in the roadmap is very obvious, you're not gonna under promise and over deliver.

  - Some of your advice on roadmapping. Whose advice do you listen to about road mapping?

  - Oh that's hard 'cause like I think roadmap is such a hard playbook, right? Because it depends a lot on so many things. And if I believe empowering people for them to own the roadmap and the way of roadmapping matters. Then listening to a lot of advice on how other people do roadmaps is I always take it with a pinch of salt. I always try to abstract the principles behind that. Even as I'm saying I hope people abstract and take it with a pinch of salt 'cause they need to adapt to their reality. What I try to do is I look at the practises of building successful products and I love Shreyas Doshi and I follow him quite closely on the way like product management is about building successful products and making products successful, right? So I think if you follow people writing about how to build successful products and make products successful and you then incorporate those practises in a way of building a roadmap, then you can actually learn from anyone writing and discussing thoughtfully about product management and then bringing it to your roadmap practise. Because if a roadmap is a communication of what's gonna be done and what's gonna be done is an execution of what you discovered, then understanding how to discover and build better products will yield a better communication so it will yield a better roadmap. So I don't have people specifically talking about roadmaps that I follow. I follow a lot of people that think thoughtfully on how to build better products.

  - Any other particular resources you go to, to just to get those insights?

  - Yeah, there's a lot, I think I wrote something about this, but there's a lot of people in books and podcasts. So top of my mind 'cause I don't have them written here, but like, yeah, Sheyas Doshi Twitter is great. Lenny Rachitsky's newsletter, podcasts Twitter are very solid, they're great. I think like books from Melissa Perry. Books from Marty Cagan. I try to not look at them as prescriptive but like approaches to thinking about a very abstract team, which is product. I think they influence me a lot. I think John Cutler's posts on Medium and now on Substack are great. His weekly posts are super thoughtful. There's a lot of people writing, I don't have their names, but on LinkedIn writing really thoughtful posts on all the aspects of product. And then a lot of other books and articles beyond product around psychology, around behaviour than the realities books are great. And then like even founders who are at heart product builders and the way they crystallise their thoughts on how to build a company. And then if you try to abstract that into, okay, imagine that your product is like a company and you're the CEO, I don't like the term CEO of the product, I think that doesn't fit. But if you think your product is a company and you need to act as a CEO, which lacks the authority but still has to have, actually, let me put it differently. You act like the founder, a founder of a product, not a CEO, but a founder who imagine doesn't have full authority but needs to drive the vision, the excitement to build. I think you can learn a lot about founders who write openly Tobias Lutke from Shopify, someone I follow deeply. And then the last one I would say like Harry Stebbings 20VC, they have a monthly 20 product. They invite amazing leaders into the podcast. I think you can learn from a lot of people. And books, I think books are probably the best assets to learn and think through.

  - When go back to that founder and CEO one just for a sec, 'cause, yeah that CEO of the product one is one that's always rubbed me slightly the wrong way. I think of it the other way around. I think of it as CEOs are big product managers. Their product is the business and good CEOs work with influence, not the authority, which is the opposite and the mismatch.

  - Yeah, no, you're technically, well you're technically right. Like great CEOs don't have to enforce authority because they automatically, they should influence, they should guide, they should direct. But then if it comes to a point where you have to, a product leader will not have the power to and the CEO eventually has. So I think that difference, it does make a difference. But in the end of the day, I agree like influencing, leading through influence is the best way to go far. Leading through authority might get you there quick but won't get you far. And I hope everyone's trying to play the long game or the long term game. So I hope far is the default mindset.

  - So I just wanna pick up a couple of hanging points from what I've heard so far. You've talked about a quarter quite a lot, so just tell me about timelines or time scales or durations that you cover in a roadmap in your perspective?

  - I think that depends on the stage of company. So I generally advise early stage companies to either not follow a timeline at all and just build right and waste zero time planning. Just go, just talk with customers. You have zero legacy, zero complexity, your team is all in there. Building is quick. If you have experience, they're probably gonna take the shortcuts, the right approaches to implementing something, you're gonna be fast. So I think every minute you waste planning is time wasted that you could have been talking to customers, discovering what they need and then translating that alongside the team into executing. So early, early stage, I wouldn't focus so much on roadmaps and timelines. As you progress to some complexity and where making trade-offs or going through trade-offs becomes a thing. Then I generally advise early stage companies to go on monthly roadmaps because it's a timeline that is, it's large enough for people to be comfortable about the next couple of weeks, but it's not long enough for you to be kind of predicting the future, right? So monthly roadmaps and I say like until you achieve some maturity, you have maybe multiple teams trying to build into the same product and maybe stakeholders who are needing some more further away timelines for them to plan some rollouts and go-to market, some hiring, only then you need to go into quarterly roadmaps, like three months. So for me, at Kitch for example, only maybe two years in with already like 30, 40 employees, we went from a monthly roadmap to a quarterly roadmap until then like monthly was working. It puts a bit of pressure on the product management team or whoever's owning the roadmap, the product team and a whole, it does put a pressure because like every three, four weeks you're kind of stopping and planning a whole month. But I think like, yeah, quarterly. And then, I mean you can stay forever with quarterly. Of course then depending on whether you're raising money or talking with a board or leadership, you might wanna give a 6, 12, maybe even further away like vision, like a two three year vision. But like you can execute roadmaps on the quarterly forever probably.

  - And now earlier on you mentioned some principles you like to live by that that was under promise, over deliver. I'd love to hear that list.

  - Yeah, so there's like eight principles that I try to follow. First one is under promise and over deliver. It's basically around delivering happiness, right? And I think happiness is that positive delta between reality and expectation. So if reality is better than expectation, you're gonna be happy. So if you're able to under promise but then over deliver without sacrificing ambition, I think here you're gonna execute really well. A second principle, I said if it's a maybe it's a no. There's another way of saying this, like if there's doubt, there's no doubt.

  - Hell yeah or no.

  - Yeah, exactly, hell yeah or no is a great way of putting it. Is like it's all about strong yeses, right? So that's another principle. A third one is just enough is the right size. And it's all about like parental principle, right? Like the 20% that yields the 80% of value, 20% of effort yields see 80% of value. So like if we focus on building just enough, and if we do it enough times we will deliver more than enough. So number four is about context. I say like context is everything. I think if people have context, they will do the best work of their lives. And when you don't have context, you're anchored, right? So context or lack of clarity is the ultimate anchor. So context is everything. Number five is violently executed now. And I think it goes back to general pattern. And what I see is like violent execution is what differentiate teams that get there faster and learn better or learn faster and execute better, right? Actually have a quote with my team, which is like, "Perfect plans they rise by learning from today. And today is better than tomorrow. Tomorrow is better than next week and next week is too late." So this is about execution, right? So number the next one, I already lost myself in numbers, but like next one is like magic is in the details I think is number six. Magic is in the details and we believe that the best experiences are the ones that care for the right details. Not all details, but the right details and then they deliver them as if it was magic. So we try to push that into our product scoping into the design of our experiences, into the way operations and customer support converge with a product for customers. So that's magic in the details. Number seven is alignment is core is like, we say it is the basis of no fuckups. Alignment is literally compounding force across the company. A first professional lesson I got was like, don't assume stuff, it makes an ass out of you and me like a wordplay. So alignment really keeps people from screwing up. And then the last one, it it comes from amp it up from Frank Slootman is also a bit about execution, which is "Drivers not passengers." And it's all about like people who make a difference, who change the game, who move the needle. They drive, they're not passengers in the vehicle. And if I do believe in this product is a vehicle of value, then I want the people building it to be drivers of the vehicle, not passengers within the vehicle. So it's all about ownership. So I'd say like these are my eight principles that I try to shape my team's execution. Also, when I try to hire, I try to look for people who fit within these principles. Let's see, I'm open-minded to make these change or add or remove, but it's yielded good results so far.

  - I absolutely love them, Andre. Absolutely love them. So coming to us the tail end of the session. I would like to ask the hardball question last and that is, if you had to distil your philosophy on roadmapping down to one or two sentences, what would it be?

  - So I'm gonna take a cue from Paul Graham, which is, "Plan something people want." Right? So Paul Graham has this famous quote around, "Build something people want." Which is kind of a motive why combinator, right? Build something people want. And I think product market fit is your ability to exactly build what people want, right? So if I had to distil a roadmap, it's like if a roadmap is a communication of a plan, I'm gonna go with plan something people want. And that ideally gets stuff that people don't want out of the roadmap. Deprioritize what people don't want as much as what people want. So it touches on prioritisation and narrows down. So that's violently executed now narrows down to what people really want now so that you can give it to them as fast as possible. So make the roadmaps as short as possible. So I'd say yeah, plan what people want.

  - What should I asked you that I haven't asked you about roadmapping?

  - Do we even need to have a roadmap? Like it's a philosophical question. Do roadmaps even need to exist? Yeah, I argue that could be the vision of a product leader whose product is a roadmap, right? I take that cue from Google, right? So Google the objective with Google is to be invisible. Is to get you out of their product as fast as possible. Like Google search, if you get to use Google search, get to your answer and leave that is success, right? So the ultimate goal of Google would be for everyone to have the knowledge of anything instantly all the time so that Google wouldn't need to exist for the business would suck. But for a product vision of Google would be beautiful because yeah, imagine you put a ship of Google in your mind and any exact, you know everything you don't need to search. That's the beautiful vision of-

  - Serendipitously. They just presented the answer to you the second before you needed it.

  - Exactly, and if you don't need to make an extra effort of typing or going to an interface, it's even better. Like that's magical, right? So in roadmap, the way I see it is like if you think about founders and small teams like two people, three people founding a team together, building something. They don't build a roadmap because they all know what it is required. They all know what they're doing. They don't need to build presentations for the two of them to understand what they're building. They either talk and they know it and that's like a vision. So imagine 1,000 people, 10,000 people company not needing a roadmap because everyone simply knew what was gonna be built. Like again, very utopic, right? That's a vision. But imagine what that reality looks like? Now this is my answer to, do we even need a roadmap? Yeah. If you get to this reality where we're kind of hive minded and we know exactly like two, three founders in a garage or in a table or know what they're gonna be building, then no we don't need a roadmap. What makes us need a roadmap is the fact that humans have a hard time communicating beyond X amount of people. I don't if it's like 50, 100, 150. There's a lot of theory there and roadmaps help that communication flow, right? But that's kind of my vision is like what can we do today that gets us closer to not needing a roadmap? I think my answer on the Notion roadmap and like empowerment and people collaborating in real time is kind of an answer to that. It's like we get this in like cruise control, which is kind of like not as needing to do more, which makes roadmaps a bit more invisible. I don't know it's thoughts in my mind that I still need to crystallise.

  - If we can achieve alignment of scale, then we don't need something that helps us achieve alignment at scale.

  - Yeah, that's exactly, it's a self-fulfilling prophecy.

  - Andre, it's been wonderful talking to you today. Last little opportunity. Here's your chance to pitch you, yourself, Kitch and what is it One Month PM?

  - One Month PM and that's onemonthpm.com. Super easy. We run programmes around product, we run programmes, all livestream, all online. One month, four weeks. We have a basic premise, which is it needs to be affordable. So it's like every programme is 99 euros plus VAT for the full programme full month. So it's pretty affordable. It fits your busy schedule. So it runs after time though it's European, it runs on GMT plus one after hours or lunchtime. And it needs to be from people who've done it, right? Every single person teaching it has done it, is doing it in real time within their companies. So what do you get out of that are real learnings that you can apply whether in your current role or to bridge the gap of knowledge so that you can get to that role. And we run product foundation programmes, growth programmes, no code programmes, data programmes. We're now launching a lot of new stuff from Web3 to product leadership, to AI to product marketing. So we have a lot of things in the works, but I think like if you're looking to learn more about product management and you're within the European time zone and you wanna do something that doesn't break the bank, gets you knowledge, have fun, then look at onemonthpm.com, enrol for a programme. They sell out in like 24 hours. So you need to be kind of pre-applied and on the lookout, but I think if you get to join, yeah, we need to have nearly a thousand people who participated in the last year and a half. We have 1,500 more in the waiting list. So it's going really well. But I really wanna welcome everyone who wants to learn more about product to check it out.

  - So we'll make session links to link below for that. Andre, been an absolute pleasure having you here today. Great conversation, great insights. Just like to remind everyone out there, please do like, subscribe, hit that bell icon follow us. And if you'd like to be where Andre is, join us in a conversation, we'd love to have you reach out through info@talkingroadmaps.com. And we'll have a chat with you. Got lots of great new guests coming as well. Stay in touch with the channel. Andre, thanks again.

  - Thanks Phil, appreciate the invite. This was great.