Is your roadmap a daydream? | Radhika Dutt

In episode 11 of Talking Roadmaps, Phil Hornby interviews Radhika Dutt about transforming roadmaps from mere aspirations into actionable strategies. They delve into the principles from her book, "Radical Product Thinking," and discuss the importance of systematic innovation for creating impactful products. Radhika shares insights on avoiding common pitfalls in product development and offers practical advice for aligning product vision with execution.

Radhika is the author of Radical Product Thinking: The New Mindset for Innovating Smarter which is being translated into several languages including Chinese and Japanese. She is an entrepreneur and product leader who has participated in four acquisitions, two of which were companies that she founded. She advises organizations from high-tech startups to government agencies on building radical products that create a fundamental change. She is currently Advisor on Product Thinking to the Monetary Authority of Singapore, Singapore’s central bank and financial regulator. Radhika has built products in a wide range of industries including broadcast, media and entertainment, telecom, advertising technology, government, consumer apps, robotics, and even wine. She serves on the board of the Association of Product Professionals and the independent publisher, Berrett Koehler. She graduated from MIT with an SB and M.Eng in Electrical Engineering, and speaks nine languages.

“A roadmap is how you translate your vision into action. It’s where the rubber meets the road.”

— Radhika Dutt

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 Andrea Saez she’s a Product Marketing Manager so brings in a different perspective on roadmaps, but also ex-ProdPad and ex-Airfocus so knows the space in depth! So watch out for Episode 12!

• Transcript

  - Welcome, everyone, to the latest episode of Talking Roadmaps, the channel where we explore everything from the good, the bad, and the ugly about roadmapping. Today, I'm joined by Radhika Dutt. Radhika, would you introduce yourself?

  - Thank you for having me on, Phil, great to be here. So I am the author of "Radical Product Thinking: The New Mindset for Innovating Smarter". Thank you . And my book is about how we can build world-changing products really systematically. Why do we need such a book? It's because, you know, the way we've learned to build products, especially over the last decade, is that, you know, you just have to keep iterating until you find this nirvana of product market fit. And unfortunately, it turns out that this is just not how you build good products. By taking this approach, you keep running into a set of product diseases that I write about in the book. And it's these same set of product diseases like pivotitis, obsessive sales disorder, and hero syndrome, that I myself had run into in my career. And that is what led me to writing this book, because we can build products very systematically to avoid these diseases. So in terms of my background, I've built products across a wide range of industries from robotics, telecom, broadcast media and entertainment, advertising, even wine. And I've worked in companies, ranging from startups to multinationals like Cisco. And so it's all of this that I bring together and hopefully that's the short summary about me and the book.

  - Perfect. And I'm trying to remember, 'cause it's a good year, or if not, 18 months since I read the book. Was feeding the beast one of those other diseases in there? The one where it's, kind of- thing where it's about just keeping the development team busy.

  - No, I don't think so. That's an interesting one. I think that's more of strategic swelling, which is how I describe it. It's where we're just continuously focusing on features and adding features to our product, without really thinking about, you know, why we're doing that, and it ends up leading to very bloated product. But it sounds like feeding the beast is very similar.

  - Yeah, probably feeding the beast is almost the symptom of the disease.

  - Exactly. I think feeding the beast is kind of the manifestation of the fact that, you know, when we don't have a clear vision and strategy, all you end up focusing on is the tactics and execution. And that's really feeding the beast, right?

  - So great, great to have you here Radhika. And obviously, the mandatory requirement of any podcast is please do like, subscribe, share the channel. Radhika, let's start with those that most fundamental and basic question: a roadmap, what's it for?

  - I think the way most companies look at their roadmap, they think about it as tool to align the engineering team and convey to whole organisation: here's what we're going to work on. And I think the reason this approach is a little flawed is because that ends up meaning that your roadmap is just about engineering, and at most, engineering plus design, and what you're doing along those two lines. But let's think about what it actually takes to build a product, right. It involves sales, marketing, it involves the customer service and operational team, and on top of all of that, engineering and design, right? So if we were to think about a roadmap, to me the most important idea is that a roadmap has to be cross-functional so that you're creating this alignment across your entire organisation.

  - And now, and if I remember rightly from RPT, you very much talk about vision based, sort of, steering. So I guess how do those things align?

  - Exactly. You know, a roadmap feels like a random bunch of features that are, you know, thrown a timeline when it's not derived from a clear vision and strategy. So, you know, we talked about this feeding the beast idea, or strategic swelling, to overcome all of those concepts. What we really have to do is have this clarity of what is the problem we're solving, why does it need to be solved? Because, really, maybe it doesn't . And then what is the world that you envision when that is solved? So that's what I mean by a really clear vision. A vision isn't about, you know, saying that you're gonna be the leader in "blah blah", or, you know, being number one or number two, or having this big aspirational goal that's broad and never changing. You know, all of those ideas used to be our conventional wisdom for what is a good vision. And instead in the radical product thinking approach, we really take this radical view that, no, actually your vision has to really detailed. It's only when it's detailed that you can then translate into a clear strategy, and then from that strategy, which is, you know, an actionable plan for how you achieve that vision, then you can craft a roadmap from that strategy. This is how you really translate your vision into your everyday activities. And, you know, I gave this example of a few product diseases. What I found in my career is that whenever we actually have a break in the chain, going all the way from vision to your daily activities, that's where product disease is creeping. And so what you wanna do is avoid that break in the chain and very carefully derive your strategy from your vision, your roadmap from your strategy, your metrics from your strategy and so on.

  - The one, kind of, I guess, concern here is a vision being really detailed. Now does that not get prescriptive? Does that not disempower a team?

  - You know, so this concern about a prescriptive vision, I think is truly misplaced because what happens is, when you have this broad, sort of the vision, and I'll give you an example, right? This is the vision of the public company. It says empowering, no, helping humanity make progress by empowering people to express themselves, right? This is the kind of vision that we typically think of. If you read most vision statements, they're broad and fluffy like this, and you're right, this way it's not prescriptive. There are a lot of different directions you could take this, but here's what happens. I typically do this exercise, you know, with people where I say, okay, give me an example, and get creative here, of either companies or products that could have this as the vision state. And I'll throw out an example, my kids have a piano teacher, she's helping them express themselves. And so this could absolutely be her vision. And so, you know, another such example could be social media, it could be a company that makes stickers, the problem with such a vision is that it doesn't give you a filter. You know, if you pretty much hold up anything against the vision, the answer is, sure, anything goes. And so a prescriptive vision is much more useful where you're saying what problem you're solving and the world as you envision it, so that if you hold up a feature against it, sometimes the answer has to be a no. A lot of companies think that a vision has to be short so that people can remember it. And that is the fundamental issue sometimes with vision statements. Because, you know, we have this idea in society that there's one visionary who has the vision, and everyone has to remember their vision and follow that. In reality, you don't want people to follow your vision, it really has to become their own vision. You want them to internalise it. We need to shift that focus from memorising vision statements to deeply internalising them and feeling them inside, so that we're driven by that vision. And so a good test that I find is, you know, instead of having people memorise these vision statements, to ask people the question, you know, what is the, what is, do you think the vision is for our product? And you ask every on the team this and see if your vision, if what they, say sounds similar without- and asking them to express this in their own words.

  - So it's not a sound bite, but it provides those guardrails, I guess, to, say, keeping us on the same track almost.

  - Exactly, keeping us in alignment as we keep executing.

  - Which I think perfectly brings us back to roadmap since they're about alignment, often, and the direction we're going on, in terms of track. We talked a bit about the purpose and kind of we segued into vision, which I, you know, I think is in a related artefact. But if we're on a roadmap, who's the audience?

  - Yeah, the audience is the entire company. So this is why I was saying, you know, it has to be a cross-functional roadmap. And so one of the reasons, you know, why I think that's so important is that as a product person, you really need to spread your influence across the entire organisation, you know? We often think about the product person leading engineering and design for example, and you know, the rest of the organisation, let's look at even pricing. Typically what happens in an organisation is, you know, the product person builds the product, and then let marketing and sales think about pricing. That has happened so often in larger organisations. Or for example, you know, build the product, and then you include customer service to figure out how they're going to support this product. You know, what this ends up resulting in, is that a lot of these elements become after thoughts bolted onto your product. And so instead, when you have this cross-functional roadmap, it really helps you plan out for your product, like, the entire and comprehensive strategy, and then spread your influence across the organisation so that, you know, marketing- it has your same, you know, positioning in mind when they're putting out messaging. That your sales team and you have collaborated in terms of pricing, that in building the product you've included customer service, so, you know, you know how they're going support it and they know how your features allow them to support it, support your product better. So all of these things have to come together in a roadmap that's derived from comprehensive strategy.

  - I have to say those examples of sales and marketing suddenly inheriting pricing later on and so on. I consider it be dysfunctions of product management, but good product management, that doesn't happen, but equally, then they have a good roadmap that maybe is cross-functional.

  - Exactly, but, you know, I've been in so many companies where that happens, right? It's, it happens often enough that it makes me realise that, you know, this is kinda the need for a cross-functional roadmap.

  - Well, too often the product organisation end up being very technically or delivery focused, instead of taking that holistic cross-functional view.

  - Exactly!

  - And so I think you've kind of already hinted at who owns and maintains it, but let's just be explicit.

  - To me, it's definitely the product person who owns the roadmap, but there's a huge buy-in piece of this, right? If the organisation feels like, "You've just, sort of, dictated this roadmap to me," you're gonna get very little support from others looking at the world like you do. So what has to happen instead, you know, I think about your whole strategy as a co-creation process. So, you know, let's say you have a clear vision, the way I approach strategy is in- let's use the radical product thinking framework. A good strategy really answers four questions. First is what's the pain that makes someone come to your product. That's the- and by the way, the mnemonic is RDCL, or radical.

  - And it took me a while to suddenly realise that's essentially a twist on your name as well.

  - It's not actually, although my nickname in high school used to be radical, I have completely embraced that. But going back to the radical strategy, the R is for real pain points. So what's the pain that makes someone come to your product? The D is for design, which is what's the solution that helps you solve that pain? The C is for capabilities, meaning, you know, what's the underlying engine that really lets you deliver on the power of the design? And then finally the L is for logistics, which is where you think about how you bring the solution to customers, that's where you think about your pricing support, your delivery mechanism, etc. So when you think about your strategy, you know, all of these elements, they have to get some buy-in across your organisation. So very often, you know, as a product person, if you haven't done the co-creation part in your strategy, when you then create a roadmap that is completely driven by you, it's very hard to get that, sort of, buy-in. And so that co-creation has to start in the vision strategy phase.

  - I know we've kind of talked about relationship to that vision and strategy. Other artefacts, or other, kind of, business "things" that are maybe linking to a roadmap as well, in your world?

  - You know, the thing that always kills roadmaps, right? Is the stuff that flies in that you have to react to. And in so many companies I find that, you know, people lose faith in the roadmap because they feel like things fly in so often. Why do I even have a roadmap in the first place? That's the, you know, super tactical kind of a product team that feels like they have to completely be reactive to constantly "delight" customers, which is an interesting conversation in itself, about delighting customers. Let's get to that one in a few minutes , but the point is, what do you do when things are flying in and it's threatening your roadmap? So one of the tools that I give product people is, you know, you have to constantly get people to realise the importance of what you are working on, and how should you prioritise things? So even when you have a vision and strategy, you have to be able to think about, how do you balance that vision and strategy against the reality of your immediate business needs, the short term needs, right? And so a good way of doing that is to make trade offs explicit. 'Cause in reality that's what we're always doing, always balancing long term against short term. So how do you make that explicit? On a whiteboard you can draw up an X and a Y axis, where the Y axis is vision fit and the X axis is survival. So we talked about what is a good vision, like, having this clear and detailed vision. So that's your Y axis. And when you describe your X axis, survival, that's about, you know, what is, what is the most immediate threat to your product? So for example, if you're a startup, your most immediate threat might be that you run out of money and fundraising. If you're a big company where you have a war test, you know, your biggest threat might be stakeholder support. That maybe, you know, if your bosses don't like what you're doing, you might be out of a job. So be explicit about what is your survival? And so once you have this X and Y axis, you can start to plot features and all these fly-ins, all these four quadrants that emerge, right? So things that are good your vision and good for survival, they're the ideal features that I- Ideal features sound ideal, but if you always focus on just that, you risk being myopic, right? Because that still means a constant short term focus. So you might do more things than the ideal quadrant, but sometimes you have to be investing in the vision. So for example, you know, let's say you are doing something that is, like, refactoring code for the next three months, that's investing in the vision, because it's good for your vision, but it's not helpful for survival in the short term. And the opposite of investing in the vision is when you're taking on vision debt. That's when it's good for survival. So for example, you know, your salesperson tells you that, "If you just add this one custom feature, we can win this mega deal," right? Well that's gonna help survival, but it's not good for your vision. And so I call that vision debt. And so, you know, this is not to say you never take on vision debt, you have to do it very rarely. Otherwise, you risk what I call obsessive sales disorder. The disease that can really, kind of, completely derail you from-

  - I mean it sounds, I guess it's similar to taking on technical debt or taking on design debt, as is a growing term as well. You know, you take it on with caution, but what would the trade off?

  - Exactly, and in many ways, to me, vision debt is even harder to pay than technical debt or design debt. I look at technical debt and design debt as a subset of vision debt, right? Sometimes vision debt is the entire feature that you're building. Vision is harder to pay off because you cannot fire your customers. Once someone's using something, it's really hard to get rid of that custom feature.

  - On the first inspection, it feels related to, kind of, the effort impact, kind of, sort of, ways of doing it. But it's subtly different.

  - Exactly, I'm glad you mentioned that because you know, I found the impact versus effort to be a bit limiting. The impact is close to vision, but impact can still, like, if your vision is not clear, you know, impact can just be- well, impact in what way, right? Like is it the right kind of impact that you actually want to have? Is it aligned with your vision? And effort, right? What I've found with doing impact versus effort is that we often tend to focus on small things and keep making small optimizations. It's very hard to do. And by the way, the other issue with effort is that may not always be what determines survival for you. Something might be little effort, but let's say your biggest risk is the technical risk and your product is unstable and you need to fix that. You might add a feature that requires little effort, but that might not be good for you.

  - Yeah, and I can see the value 'cause I've always found that the impact effort, you go for the low hanging fruit, but you never make a big change. You never put a ding in the world.

  - Exactly! And that is why we keep getting iteration led products as opposed to vision driven products, right? And so when you take this vision versus survival approach, the way you use this for your roadmap is when there are fly-ins that come, you use this to say, "Well, is this functionality that's ideal? Should we be doing this?" Or you know, "Is this investing in the vision? Are we taking on vision debt?" You don't realise how often you are taking on vision debt unless you start to keep track of it. And this vision versus survival helps give, you know, everyone this visual framework so that you communicate to people how often you're taking on vision debt, and it helps leadership understand that if you keep at this, your vision is gonna soon become just meaningless.

  - I can absolutely think of a hundred scenarios where this has been the problem. So okay, we kind of thought about what's- what the roadmap is and who it's for. We've gotta show this thing. What are the key elements that actually make up a roadmap?

  - So to me, there are a few elements for a roadmap, right? So first of all, there's the timeline aspect. The second is the initiative itself. And the third thing is who owns it. So to me, those are the three key things. And the way I show a roadmap is typically in terms of a timeline. I use now, next, and later, in terms of who owns it, you know, I really like to have names in there. Sometimes you might have to have groups, but it's ideal if you really have names saying who owns an initiative. And then in terms of, you know, the- the what needs to be done on the roadmap, rather than describing just features, my preference is to actually describe it as initiatives or themes.

  - And so you talked about names, so, you know, like what ideally one name- is that a little bit like Amazon's, kind of, single threaded leader concept? There's one single person that, kind of, who's taken ownership of that, maybe many people working behind the scenes.

  - Exactly! There may be many people behind the scenes, but one person who really says, you know, "I own this item and take ownership of how it needs to be done." So, let's take an example. You have this crossf-unctional roadmap and someone has to create a training plan for how you're gonna train users on this product. Well, someone has to take ownership of creating that plan. So who will own that? And that's who's name we will put on there.

  - Yeah, names on something, I don't think it's something I've ever seen or used. So that's quite interest- and this is the whole point of the channel, is to find those little golden nuggets.

  - There's one other thing, right? I mentioned that in terms of the what needs to be done, I typically describe it as initiatives or themes as opposed to specific features. In taking this approach, it's so important to derive all of those initiatives from your strategy. So, you know, I described this framework of RDCL. So the way that usually pans out is you might have, let's say, a MURAL board or a Miro board, where you have all these post-its for different elements of your R, D, C, and L. And so the way you translate that into the roadmap, is you look at those and you say, "Ok, how does each element of my roadmap translate into what I need to be doing? And then how will I plan that out across, you know, now, next, and later?" So you can- I pretty much, in my workshops, use exactly those post-its that we've created on those mural boards and then we transplant them into a now, next, later, and then say who owns it. And I find that to be such an efficient and collaborative approach in creating a roadmap.

  - So one of the things I've, sort of, leaning towards these is putting the problems on the roadmap. So the R from the article, up from the radical, I should say, kind of framework, you know, leaning off with the problem because it tends to be fairly stable. And therefore, when the solution changes, Great, I haven't gotta change my roadmap!

  - I love what you just said because that's exactly right. You know this, the point of deriving a roadmap from strategy that starts with this R, means that everything is grounded in, what is the real pain point that you're solving for? What this also means, by the way, is that your strategy makes it really easy to troubleshoot when something goes wrong. 'Cause inevitably, you might put some things down the market, and you might discover that, "Hey, this is truly not working." When something is not working, it's so useful to be able to go back and say, you know, "What didn't work?" Was it our mistake in terms of understanding the R? Was it the solution? Was it our underlying engine? Or did we price it incorrectly? And so being able to, you know, trace your mistake is so useful. I kind of describe, you know, this comprehensive strategy and putting it down on paper, as doing algebra, as a group effort, right? If we remember our math teacher from high school, she would always say, "Well you know, you have to show your work and you have to-" And the reason for showing your work is that if you make a mistake at the end, you can go back and figure out what went wrong, and you can communicate that mistake to your teacher. But the same thing applies in a whole team. You know, often what leads to the disease, pivotitis, is we decide that we need to pivot, something's not working, but it's not clear what wasn't working and why you think this next iteration is gonna work any better. So instead when you have this, sort of, clarity of your strategy, you have this hypothesis for, "This is what thought was gonna work, this is what did not work, and so this is what we'll next time and why we're doing pivot." And by being so deliberate abouts pivots, you can avoid pivotitis.

  - So you about MURAL and and Miro, are they your favourite tools for visualising a roadmap or is there something else you like to use?

  - Yeah, personally I use MURAL, but exactly, those are my favourite tools for actually using- for creating a roadmap. You know, back in the day before Zoom, it used to be a whiteboard, but I think that's, I've actually found doing this digitally to be so much more useful.

  - And so that's creating, what about say presenting it to your audience, same tool or something different?

  - Once you've created it on MURAL, you can actually continue to just, you know, present it on MURAL, too. I think the key here is that you're presenting themes, as opposed to features. I think a lot of, in a lot of organisations, presenting the roadmap becomes a hard problem because we're trying to show all the details of what features are we releasing. And the features that are releasing, it's really hard to- we haven't really communicated, kind of, what's the R and the D that we're solving for and that's why there's this focus on the exact feature. And so in changing our approach a little bit, it makes communication with the roadmap so much easier.

  - I know one of my, sort of, bugbears is, well, if we're communicating the features we're releasing and a date for them, then it's probably not a roadmap, it's probably a release plan.

  - Right!

  - So it's another artefact that sits next to it, it's a useful tool, but it's not the same tool.

  - Exactly.

  - So switching gears a little bit, what do you consider to be best practise in terms of roadmapping?

  - So, I guess, to summarise all that we talked about, that would be making sure that it's cross-functional, that it's not just about engineering and design. The second thing would be the co-creation aspect. You know, you cannot influence across the organisation unless you've involved them. And the third thing to me is- I loved how you described it, having a clear difference between a release plan versus a roadmap.

  - So let's take the other side of this, what about the biggest mistake or antipattern that you see on a roadmap. I think the biggest that I would say is making this detailed roadmap that is feature based, and then that keeps changing because you discover that this feature has to be different, or you're dealing with little fly-[Instructor], and your roadmap feels so filled with minutia that it's more confusing than, you know, helping in terms of communication.

  - Sure, and this may be the same thing, but a pet hate that you don't like, something you really don't like to see on a roadmap.

  - A pet hate for me is when a roadmap is driven by goals and numbers. So sometimes I find that, you know, a company has OKRs where they say, "Okay, we have to hit 50,000 signups by this date." And so the roadmap is driven by something, by such numbers and targets. Why is that a bad idea? Because when we set targets like that, you know, 50,000 signups, that's really just setting numbers and you're now gonna be tied to delivering on those numbers. But it doesn't give you the flexibility to realise that, for example, if you look at your strategy, perhaps what turned out to be more important was not the number of sign ups, but perhaps something that was further up in your in your conversion funnel. Or perhaps something that was, you know, something really important to fix in the user experience. But instead, you know, once you've set metrics like this and target, you're forcing your team to just focus on such metrics and deliver a roadmap that so quickly becomes just outdated.

  - Love it. Now if I remember rightly, it was Bruce McCarthy who introduced me to you. But I always like to ask, whose advice do you listen to on roadmapping?

  - That's a really good question. I think, here's what happens to most product people, we kind of, over the years, through our own experiences, we end up building whatever our best practises are, and we kind of learn based on just making hard mistakes. So in the past, I don't think there have been that many resources on how you build good roadmaps. And so I've had to make mistakes and learn on my own, but I've- yes, exactly Bruce McCarthy introduced us and I do find this really good resource.

  - So Radhika, you talked about delighting customers, you've gotta unpack that for me.

  - So one of the things that makes teams truly reactive and makes roadmaps meaningless, is we often think that a good product is just all about delighting customers. It turns out to be such a flawed idea, because the way I look at customer delight, right, it's like getting into a car and asking for directions. So before you can ask for directions though, you have to know where you're going and how you're gonna get there. Asking for directions only tells you, are you on the right path or not? And so what happens, I'll give you an example of where delighting customers went terribly wrong. So, you know, many years ago there was a startup founder who came to me and his startup idea was brilliant, loved it. It was about, you know, helping people spread kindness in the world through the suspended coffee movement. Now, if you're familiar with the suspended coffee movement, it started in Naples about a hundred years ago, where you pay for two coffees, one of which you consume, and the second is paid forward. So he wanted to create an app where you could pay forward. And so when I met him, right, the numbers themselves looked fabulous. He had organic growth with people just learning about this from word of mouth, he had fantastic NPS scores and, you know, people were driving long distances based on this app, engaging with it every day. I mean, everything sounded fantastic. Except one thing. It turned out that everyone was going this app to get free coffee. No one was actually spreading kindness, right? So if you think about delighting customers, he was even spending his own money to delight customers and all customers wanted was free coffee, right? And so when we started working together, we completely switched modes and we said, "Okay, well, so what's the vision?" Meaning what's the change you wanna create? And so the vision was about spreading kindness through coffee. And it was a much more detailed vision, by the way. You can look at the radical vision statement and that's on the website, radicalproduct.com, that gives you fill a in the blank statement for a vision. So it's much more detailed than what I just described and I'm happy to get into that if you want, if we have time. But then we had a strategy. So the strategy was, "Well, you know, people are engaging with this to get a free coffee, but they're kind of afraid to make a payment and buy someone a coffee." So our solution had to be that we had to get people to learn how to give a free coffee without having to pay for it first. So the underlying engine that we built was brand sponsorships. So getting companies to sponsor free coffees and sponsor the feature where you get two free coffees, one of which you consume, the second you must gift. And so in terms of logistics, by the way, that meant that our business model was all about getting a percentage of the sponsorship fee. So what did that translate into in terms of metrics? Well, so people learned to gift this free coffee because, you know, they were getting this free coffee and you had to gift the second to someone else. And so we found that originally like 0% of people were giving free coffees, right? But by the time we introduced this feature, 27% of people who were, who learned to give these free coffees, were now spending their own money to pay forward. So this is what I mean by starting with this clarity of vision and then translating it into action and your features. It's not just being, you know, driven by customer delight.

  - Radhika we've talked a lot about various things around road mapping, vision, and so on. If you had to distil down your philosophy on roadmapping to one or two sentences, and feel free to take a couple of seconds to think about this, what would it be?

  - So to me, roadmap is how you translate your vision into action. It's where the rubber meets the road. And so your roadmap has to be a tool where you communicate, you know, how exactly your vision and strategy translate into the work that people are doing around you, and to align people on what we deliver.

  - Is there anything else about road mapping that I should have asked you?

  - So more than road mapping even, I think it's more of a philosophy, that I think is so important to the product world. I think fundamentally, we need to really shift our philosophy in product. We need to look at product as our mechanism, for creating change in the world, that your product is not the end goal in itself, it's your constantly changing mechanism to create that change. And so what is important is starting with a clear picture of, what is that change you want to bring about? And maybe, you know, this is a topic for another day if you're doing a podcast along this topic. But you know, it's about, you know, once you start thinking about product in this way, you start to think about, you know, what does it mean to create change? And it's not just any sort of change, it's change that creates positive contribution to society, that doesn't create digital pollution. And so, you know, in future we can talk about, you know, what is ethical product development and how do you build equitable products?

  - So Radhika, I always like to finish off with an opportunity just for you to pitch yourself, your services, how people can reach you, and how you can help them.

  - You can get my book Radical Product Thinking, The New Mindset for Innovating Smarter, it's in bookstores. You can also reach out to me about workshops. So if you would like to have a workshop in your company where you work through vision, all the way through strategy and metrics and how you measure success in roadmapping, you can reach out to me, you can find me on LinkedIn if there are questions that you have or wanna talk about workshops.

  - Cool, cool, perfect. Thank you for your time, your participation, your thoughts today. It's been great talking to you. Just a reminder to everyone out there, please like follow, share, subscribe, all those good things, and get in touch if you would like to take part. Radhika, thank you for being here tonight.

  - Thank you for having me, this was such a pleasure.