Can you roadmap a transformation? | Annett Eckert

In episode 57 of Talking Roadmaps, Phil Hornby interviews Annett Eckert, an expert with over 20 years in product management. Annett discusses her experience in leading innovation and transformation across industries, focusing on strategic product development and effective team setup. The conversation covers practical insights on how to roadmap successful transformations, highlighting challenges and strategies in product-driven organizations.

With over 20 years of product and consulting experience, Annett's journey includes leading innovation and change across various industries, driving strategic product development, and setting up effective product teams.

Grounded in her unique experience in Product, Transformation, and Executive Coaching, Annett empowers Product Leaders in establishing successful, product-driven, and customer-focused organizations.

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).

Can you roadmap a transformation? | Annett Eckert

Phil Hornby and Annett Eckert

In the next episode we are talking to Ryan Singer, he’s a Product Expert and Author. So watch out for Season 1 - Episode 58!

• 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 Annett. Annett, introduce yourself for everybody.

  - Hi Phil, thank you for having me. Yeah, my name is Annett, I work in product for 20 years, so it's a long time. And a few years ago, I've decided to work more as a product consultant advisor. So, meaning, if there is, if a company wants to do something, creating a product, or wants to bring the product to the market, there is a big problem, they usually hire me. So, I'm usually get hired for putting out fires left and right. During this time, I was really thinking about like, what is actually the biggest impact I had during this time. So, it was eight years, whereas working as a fractional product leader and advisor. And looking back, it was always about like, having better product processes in place. So, I help companies with having better strategy, or roadmapping, or setting up their product teams in a better way. So, I've decided, I really want to go more in this direction and being more like working on the transformation and change and how do we get there. People usually have an understanding where they want to get, but it's really hard for them to do that. So, this is what I did for the last four years. During this process, I also figured out that actually what you can't change a whole company, you know, it's just working one-on-one, change, transformation, making things better than they were before. It's actually something you do like with one person, one-on-one, and then just spread the word and making things better. And so, I decided to become a leadership coach. So, I'm a certified leadership coach, but really working with product leaders, helping them become product leaders, or helping product leaders to do their job in a better way, and really supporting them. Because to be honest, a lot of product leaders are very lonely out there. They just don't have to support their needs. They need someone on their hand, really helping them also to get leadership skills in place, so they can use it for their teams and also to create better user-centric products.

  - If you're enjoying the channel, subscribe, hit the bell, and give us a like. Totally agree. I mean, so I also work as a product coach, mostly with product leaders because, well, one, they're usually the ones who have the budgets, but two, they're the ones where there's the most leverage. If you can help them, they can help the rest of the organisation. Quite interesting. I was looking back at your LinkedIn profile, and I saw one of your not-too-long-ago freelance roles with a company that gives me a lot of nostalgia, CNA. They haven't existed in the UK for about 20 years, if I remember rightly. But every time I go to Europe, I still see the brand around, and it kind of brings back my childhood. So, that was a transformation lead. Maybe you can tell me a little bit more about what you do in terms of helping transformation with organisations like that.

  - So, what happens a lot is that companies, they approach me, and they say, we want to do things better. And they approach you with a backlog of ideas of things they want to change. So, what I help them is creating the whole process of innovation and also the understanding that change and transformation is not something top-down or bottom-up. It's something here where you have to meet. And I'm also setting this always up as experiments. So, a lot of companies don't really work in a continuous learning experimentation way. So, what I really help them to do is understanding that you have to create a product team, which is experimenting with new ways of working. And then you check in on that. And then you see, was it good or was it bad? What do we need to set KPIs before? And then you check in on the KPIs. And then you can spread it to the other teams. But also helping them with a strategy. So how do we want to be in like five or 10 years? And so that's also something which a lot of companies have a lot of problems with, which is surprising because everyone is like always dreaming big. But for some reason, really thinking how when we want to be better, how this is gonna look like. Because it's also about how do we want to be with each other? And this is something what people don't really understand. How is a culture? Can a culture change? Because when you're inside of the culture, changing it is really difficult because you don't really see all the problems and how the problems are also connected with each other. And for this, it's like coming in as a fractional transformation lead. It's always a good idea, but you need to support from the people on the ground and also the C-level.

  - And it's interesting you talked about that experimental approach to things. Towards the end of my product management leadership sort of experience when I was doing the job as opposed to coaching people on it, that's very much the model I settled on for how I operated. Even meetings would be an experiment. We'd run it for three to six months. And if at the end of it, nobody asked us to rebook it, it's like, well, that wasn't very valuable. That experiment told us let's not do that again. Things like that. And it just became my kind of standard operating way of working out how do we work as a team? How do we evolve? How do we improve our ways of working? So interesting to hear you use a similar approach.

  - Yeah. I think it's also just creating this culture because when you say it in the wrong way to companies, when you talk to C-level executives and you say, yeah, we need to experiment more. We do have to do more research. They always tell you we don't have the budget for this, but because they don't understand that product development is experimentation. So, you have to sell research experimentation as part of product development. This is something that I've learned. So, when you go and say we need to do this differently, you have to sell it as this is product development. If you don't do this, then everyone can create products. But that's not difficult. But creating the right ones for the right people, that's where the experimentation part comes in. And you have to sell it in the right way to C-level, so that they understand it's not extra work. It's the base of everything.

  - In fact, it's probably going to save them money, not cost them money. In my experience, if they do it right, if they embrace that experimental, that learning way of working, it's gonna mean that they stop spending money on the wrong thing quickly and therefore have time and resource to do the right thing.

  - I know, I know. I still look for like a really good study on that. So, I haven't found the really good one. There are some which are pointing to that, but I'm still looking for like the, you know, so that you can give it to the stakeholders and say like here you can save 50% of your costs in the end.

  - And it'd be really nice or really useful for us if you had say McKinsey or Forrester or someone like that near Monika's. They seem to listen to them, even though I'm not necessarily convinced they know any better than us. So wonderful. And I'm sure there's gonna be a transformation kind of slant to a lot of the discussion today. Let's start with a really core question that we always start with on the channel. What's the purpose of a roadmap?

  - That's a really good question. And I really think that it's really important that you ask that because people see a roadmap and when you ask 10 people in a room, they always give you different answers. Everyone understands it's kind of a plan or they see it as a plan. It's not a plan. It's basically the execution of part of your strategy. And that is there, you know, you have your mission, your vision, you have your product strategy, and then you have there, this is all very strategic. And the product roadmap is the first one where you think about how do we execute on our strategic goals and our business goals.

  - So, Annett, maybe you could kind of give us some ideas on how we might use roadmapping and the purpose of roadmapping that links into transformation.

  - Yeah. So roadmapping for transformation is kind of the same like for products. So that means you should have a goal, like a really big goal and a five, 10 years goal. And then you have to break it down into experiments, which is gonna be on your roadmap. The thing is, I worked in several companies where we had products, and we had the execution of the product. In the same time, we did a lot of transformation, and you have to keep this, you have to bring this together. So, what a lot of companies do, they have like their transformation initiative and then they have innovation, whatever initiatives, and then they have their product roadmaps. The thing is that transformation really takes time. You have to concentrate still on execution, but you have to take some time away from the team so they can experiment also with transformation. And transformation is always like such a big word, but let's just say like we don't really like how our team is structured. This is not really the best way. Like when you have a product, you know, you have the ways how you, the product teams are sliced into that. And this is not working because in the end, everyone is just having their own features. No one can really work outcome driven. How can we slice our product team so that we can go away from feature factory into working outcome driven and having also responsibility for certain strategic goals. And so, you have to bring this together. If not, the team is getting really upset because they're still working a hundred percent on product. And then on top of this, they're doing all the transformation part, which is taking a lot of time and experiments and energy from the team.

  - Yeah, I mean, you use the word, we've used the word transformation quite a bit here. And I hate that phrase. I hate that term. You said it's such a big one. When I did my MBA, we just talked about a change programme, and now a change programme has fallen out of favour. It's now a transformation because everything's a digital, or an agile transformation. I feel like we might be even throwing away all the learning on how change works and how it should be done to do these new-fangled transformations. Whereas there's actually quite a strong kind of playbook on how to do it. Also, a lot of myths and misconceptions.

  - I think the problem is also that a lot of people don't really connect with transformation. They think it's something big and it's not really affecting them, but it is. The thing is that the people like they're really the groundwork people, they get affected by transformation the most. And so, they get affected the most. So, they have to be part of the whole thing if you don't do that. And if you don't put this also in your product roadmap as a strategic goal, then this is gonna be like a chaos.

  - Interesting. So, you started to talk about the people, the people at the executional level there. So, I'm guessing they're an audience for both the transformation and the product roadmap. Who else is the audience of a roadmap?

  - So, stakeholders. So, stakeholders like means everyone in the company needs to understand your product roadmap. And because a lot of product teams, they have their own roadmap and they're working on that. And no one is really aware of that. So, the first of all, it's the team. So, you shouldn't create. I know that seems like very normal that you don't create your product roadmap on your own as a product manager or leader. But a lot of product managers just see this as their main job, that this is their responsibility. And you also see when you see ads, you know, job ads like number one head of product creating the roadmap. So, they see that's their job and they are the only one responsible for that, which doesn't make any sense because in the end, the development is not done by the product person, but by the team. So, you have to integrate the team, but also stakeholders. And this is something where it's getting a little bit more tricky, right? Let's say you have usually a very, happens often very siloed company. And then you come in as a product consultant and tell like, hey, but you can't do products, your product roadmap on your own. You have to integrate your stakeholders. But it happens there really often is that the stakeholders don't have a clue about data. They don't understand the user needs at all. They just come with their ideas and they're throwing it over the fence. So, the question is like, how do we integrate this as a process where everyone can partake, but without having like millions of ideas. And this is still something where everyone is struggling with, where I've seen a lot of different approaches, how to do that. You can do this in like, I think the first step is always training that you have to give your stakeholders training on how to, but what user needs, like how do you get to user needs? What is like quantitative and qualitative user feedback and how do we use it so that they can be really part of the whole product roadmap? And it needs to be like that because if not, they also have to work with this product roadmap to understand it, but also work with that because if not, the whole silo thing and throwing over fence part is still gonna happen. And it's never gonna be your roadmap as a product team if you not have the stakeholders on your side.

  - Yeah, and I think you just hit on one of my sort of key sort of perspectives that the roadmap isn't one person's artefact. It's the team's artefact. It's that because the team, the product team is the smallest unit of value delivery in a product organisation. The product manager doesn't do anything on their own. The designer doesn't do anything on their own. The developer doesn't. Yes, they might be able to create something on their own, but it won't be as aligned. It won't give that same level of leverage and synergy. So, kind of being owned by that team is always kind of the way I think about it. But yeah, you're right. So many times, it's like the product manager or the product leader thinks it's their thing, and they're the only one who owns it, and the only one who can decide what goes on it until the hippo walks in the room and says, I want this feature.

  - I know, I know. This is the worst part. And then you have like also like very strict timelines. You know, you advocate for a flexible roadmap based on experiments, and user feedback. And then the hippo comes in and then demands to get something done until a certain it doesn't have even have to be a hippo. It can be anyone from any department who really wants something done. And then it's kind of like a fight, right? You're always like, no. But so, yeah, that's always like something very difficult for people like the flexibility of roadmap and keeping that and having also the autonomy. But then still you have to work with stakeholders. You cannot just ignore them.

  - Yeah, I've come to this kind of perspective that sometimes it's all right to put a feature on the roadmap. Sometimes I'm just going to accept that there are certain conditions like it's aligned with our strategy. I know that our customers want to value it. I have done some discovery on there, and I've done the feasibility work and things like that. So sometimes it's all right. Maybe there's an external driver like a standard or a regulation. Okay, I'm gonna live with it. But wherever possible, I'm trying to stay away from them. But I think the black and white no features or features is too black and white. There is that kind of grey area in the middle that we're trying to balance. And that's probably, in my opinion, what makes it hardest because people see it going on sometimes and not on other times. It's like, and they don't understand the rules of engagement.

  - Yeah, I mean, I really like to work with themes. This is usually very helpful because like when you work with strategic themes and this request, let's call it request from stakeholders, don't fall under one of the themes, then there's already a problem. So, I think that's already helpful because if you're starting that out and also still have an outcome on the strategic themes, then you can put it also under a theme. You have to be handling, I totally agree, very carefully, like who is getting in and who's not getting in. And yeah, that's the fun part of being a product manager.

  - In fact, you said who gets in and who's, I'd almost advocate it's not who, it's what. It's the value of that item, not who it comes from.

  - But the stakeholders just see it as who's getting in and who's not getting in there, you know.

  - Yeah, so the CEO, you have to reject the CEO every once in a while. And then you let the really genius salesperson through every once in a while, just so they can't figure out that there's any hierarchy to it. Interesting. But yeah, say the curation. In fact, that's a word I like to use on roadmaps is curation. It's like, we're deciding what's going in and what's going out. Like in a museum, there's a lot of things I could put out on show, but a lot of them are in the back and I'm making a choice as to what I present and what I include in this particular roadmap.

  - Yeah, this is also something where I see the most problems people have. It's really difficult to create a roadmap, which still has transparency, and you still see what's going on, but you still have the most important elements in there. And I think that's always the question I get first, like what kind of format should we use? Should we put everything in there? Should we use themes? Should we really put every experiment in there? Then it's getting too crowded. Then you present it to someone, and they don't like it. And you're like, I think that's not the right audience. I have to create another one. And it can happen that you have a lot of work creating different kinds of roadmaps for different people, because I've never seen like where I've said like, well, that's the perfect roadmap. It was either not enough context or too much. So, it was too crowded. And I have to admit this. I also never created one, the perfect one and never seen one. I don't know if there is the perfect roadmap out there. If yes, then I really would like to see it because I also never met someone who said like, I know, and this is the perfect roadmap. I think it's depending on context or, yeah, if you know someone who made the perfect roadmap, I really want to know.

  - So, I think you answered your own question. From my opinion, from my perspective, there is the perfect roadmap, but for that context, not universally. So, there's multiple views for different audiences of the same roadmap. So, I, in fact, I always like to consider it. There's one roadmap and different views for different audiences. So, I'm choosing which parts of it to show to each group to hit on their communication needs, because ultimately, they're variable. A CEO doesn't want to see the same information as the developers. And if we try and show the same information, it's not going to be an effective tool.

  - I know, but this is really, because then you are editing the whole time. You actually need someone to come in helping you to set this all up so that because as a product manager, you can't do this on your own because actually you need someone who's helping you from the outside, setting this up in a perfect way. And then you can, because this is so much work having the, I don't know, it's also depending on the size of the company, but having for every kind of level for different stakeholders, the right view, and then still being flexible. This is a lot of work. And for this, I think a lot of product roadmaps are not perfect because we just don't have the time to do that.

  - Yeah. I mean, the reality is we try to combine the roadmap with the release plan because we're trying to be efficient. And what I'm advocating is, well, the release plan and the roadmap are separate. And the roadmap then has, I'm currently on about five views. My hope is that one of these days, one of the many tools out there will produce the roadmaps in sufficiently good a view that I don't need to do it manually. But so far, I've found that they might provide a starting point, but then I have to manually create the artefacts, which as you say, is quite a bit of work.

  - I mean, I still hope for AI that you give the requirements to AI and then creating the perfect roadmap for you with different audiences. I mean, I don't know, perhaps it's already out there. If not, please someone come up with the idea using AI for that. But yeah, I agree. In the end, I'm just doing mine in Miro because I used, I had so many different, you know, I used Confluence, I used product plan, product board, I used Aha or something like that. And they're all good in their own way. But if you have a more like outcome based, or experimentation stuff like this, I couldn't find a good way. And also, where you have a way to make things smaller and you, you know, to have different views of the same thing. Never really seen anything which works really well in the end. I'm just using Miro and that's the easiest for me. Perhaps that's not very professional, but I think Miro is the best way for me to do that because then I can implement all the requirements I have.

  - So, you're doing something that I'm seeing an increasing number of people doing using those freeform kind of whiteboarding tools for their roadmaps, as opposed to the tools or PowerPoint, they kind of found that kind of middle ground. So, it's quite a common pattern I'm seeing at the moment. But let's kind of dive in there then. So, you're talking about in Miro, we're building a roadmap in there. What are the elements that are in the roadmaps when you build them?

  - So, I always start with the outcome. And this is usually the part where I'm also helping companies going from features to outcomes. And you have to start with the strategy, right? So, what is there? I think I've talked about an example. Let's just use an example. We want to be number one for our product in the market. And we did already some experimentation on more strategic level. So, now we want to find out how do we execute on that? One of the experiments would be or the goals we are finding out is reducing churn rate. So, that would be a goal. And we have several goals. And then I have research phase in there. So that's also really important. So, it's between of like, also that people understand that we're doing research on that. I always have a slot for research, for experimentation. And then I come up with the idea. So, these are the things. And I have when you have the company OKRs, you have really an understanding how much you need to move the needle so that you see something. So KPIs need to be in there. And you should also, sorry, I should have started with this first, have a vision statement. So, what do we do and why do we do this?

  - Sure. Yeah. And so, it's interesting. So, I often use, there's the now, next and later column. I often retitle them so that the later becomes the understanding the problem. The next becomes understanding the solution. And the now becomes delivering the solution. Sometimes I do that as swim lanes, though. Sometimes I use the swim lanes as themes or colours as themes, because you talked about the themes as well. Now, you use the word outcome. And this is one that I find somewhat loaded sometimes, because there are different people that use the word outcome in different ways. Now, the example you gave of being number one in the market, that's quite an impact level, kind of business level outcome. We've also got what people describe as product level outcomes. You gave an example earlier of churn, kind of changing customer behaviour. One of the things I often like to put on my roadmap are user level outcomes or jobs to be done, the things that I'm enabling them to do, hopefully tying into those next two layers of outcomes as well, because I find that those user level outcomes don't change very much. Even as I do the experiments, I'm just finding the right way to solve them. I wonder if you've done anything similar.

  - Yes, I've tried this as well. I mean, I've tried everything out there. I think this this is the last thing how I did it, and it worked out really well, but it's always based on context. The thing is that a lot of companies, when they do jobs to be done, and I usually come in and I see the jobs to be done they have, but they're not high level enough. They need to be high level jobs to be done, and then the ones coming under that. So, I sometimes struggle with what they have. So, what I do then is I'm still using the outcome, and then I check how I can put the jobs to be done under these outcomes. Churn rate, why do people churn? That's something what I've tried, and it worked well, but then it's a little bit overloaded. So, when you put the outcome and the jobs to be done, I think that's another roadmap, perhaps an experimentation roadmap or something like that.

  - Yeah, in fact what I often have is like the user job or the outcome kind of in that later column, and then it eventually turns into a feature as it gets the now column to the delivery, because we've worked out how we may deliver it. We've done the experimentation, we've done the discovery, and so you see different classes of items over time.

  - I think it's also a maturity level of the company. So, I use this, what I was saying before, the outcome, and then because like a business outcome is for them easier to grasp than jobs to be done. So, my first step is how can we go away from feature factory and going to outcome or jobs to be done, and business outcomes for them is something they can check. That's something, okay, we understand this, there's a number, and this is happening afterwards. So, they feel more safe with that than with the jobs to be done. And then the other is the one which is not that safe, right? Experimentation, research, and like then coming up with the idea. But this is, I totally would love to try the jobs to be done, complete the jobs to be done, but the companies I worked in, the maturity level was not there.

  - So, I mean, I still love to keep that business level outcome, and the customer level outcome, and the job to be done because you see that kind of causal link between them. I guess the challenge I've seen with using business level outcomes is they're usually quite lagging metrics. And so, people think, oh, we're failing because we're not seeing the needle move fast enough. Have you had any similar experiences and how have you approached it?

  - Yes, yes. That's a very good point because I had this before that the goals were way too big, and we had to break it down. So when you have OKRs and you have like there, when you've been in a company that works with OKRs and you have this yearly, you have to break them down at least in quarterly OKRs so that you have a quarterly goal rather than a yearly goal, which is helping already. And then the problem that you don't really move the needle is that on strategic level, it's also not clear that this is all an experimentation. Like a lot of people see a product strategy as set in stone, but it's not. There has to be a feedback loop from the product roadmap. So if you have this feedback loop, then you also see how these numbers and KPI is matching up because a lot of people, they just come up with some numbers and then they say that's the product strategy, just our churn rate by 20 percent, reduce it, but it doesn't have any, it doesn't relate to any reality. It's not gonna work like that. So, I think that's the part where it's really important to understand that the strategy is an experimentation and that we are going in execution and validation in the product roadmap, and then also development part. But it has to go in both ways. If you're not doing the backwards into the strategy, then you never see anything moving.

  - I mean, I think you get along very well with Daniel Elizalde, who was one of our early guests, who talks about having an experiment roadmap. That was one of the discussions in an earlier episode. And it very much resonates to me. I guess there's a point at which you switch from that experimentation, that discovery work into the delivery work and at which point the content of the roadmap might switch because you've learned. That's generally how I think about it anyway.

  - Yeah. And the switching part is usually the part where people really have problems. It's not like the strategy or the roadmap or then the release plan is in between phases. So, when I work for clients, and help them with their product operation process, then I always define very clearly the switch between different phases. I don't know if any company does this in a really good way, but the switch is always the most difficult part, if you understand what I'm talking about.

  - I think part of the challenge that I encounter is as soon as you start talking about switching and phases, people start saying, boo, hiss, we're doing waterfall again.

  - Probably, yes. I don't know if there's a better word, but it's like the transition between two phases where they're getting lost. So, this is usually the job I'm doing a lot is helping them with the transition parts between strategy and roadmap, and then bringing back the roadmap as a loop and as an iteration. So that's usually the most part of my job because everyone can go, and download some frameworks like Double Diamond, whatever, but it doesn't define the transition part between the different phases.

  - Well, I'm famous for saying waterfall is not evil in the right context. And the reality is that work goes through phases. It goes through different types of thinking, different filters to get to being done. It's not like it's just one monolithic approach to working and type of activity.

  - I think when the culture is right, then I always feel like the most problem is because the culture is not right, and all the processes are based on the culture. And if you work on the culture and the understanding what user centricity really means, and why we're doing this, and that everyone is involved in this. And it's not just the product team, it's everyone. If HR doesn't understand user centricity, then you're also not gonna get hired the right people to do the products in the end. So, I think that's, for me, really important. And rather than talking about Scrum, HR, whatever, user centricity is the part where I'm thinking this is something very holistic and has to be ingrained in a company culture, not just in a product culture.

  - I always consider we could use a roadmap to plot the course for that organisational culture, that product, that HR team. Heck, I even consider in a very meta way, a roadmap for our roadmapping.

  - I think people are getting a little bit overwhelmed with roadmapping. I mean, we're product people, we love roadmaps, obviously, but not everyone loves a roadmap. And they see more plan. And I think that's also something like when someone sees there is a plan, you deliver it then, and then they're chasing you and say, what's happening with that? Why didn't you deliver that? I think that's also something where we have to, people need to understand it's a map, it's not a plan. There's really a difference. As you were saying, it's not a release plan, it's a map of a destination. And then we see how we get there.

  - So, let's switch gears a little bit, Annett. Let's go for some of the slightly more philosophical points of what do you consider to be best practise in roadmapping?

  - So, I think some of the points, which I think best practise is really working with different teams in your company on that, and also starting with training. So, you can't do a good roadmap with stakeholders, or also with your team if they don't understand how product works, how data works, how user needs work. So, I think I would always start with the training, even though it seems farfetched, but I think training more people than just your team on roadmapping and how to get there is super important. I think that's my first best practise. Secondly, really doing the roadmap together with your team, also the stakeholders who are the key stakeholders. So, you really need to have everyone in there. And then something, it's really transparency. Like how do we create a roadmap where everyone understands where we want to go with that? So, I think that these are the three things. It's really training for everyone because you can't create something great if no one knows how to do that. Then the second one is really doing it with everyone who needs to be involved. So, you have to have UX, and you have engineering, and you have to have a data person in this process as well. So, like a product data advisor or something like that. And then yeah. And then it's really, for me, a roadmap is also helping you to break down silos. So that's also something like really like, how do we get there? Let's do workshops together. Let's see how we can create this product roadmap together.

  - Let's go the other direction. What's the biggest mistake you see on roadmaps?

  - The biggest mistake is really when you see it as a task list, when you're like, it's more like release planning and are you putting elements of release planning in there? Because then people come back to you and tell you like, wow, you have to do this. And then there is no strategic direction. If you don't understand how from vision, like company vision, from our product vision and strategy, we're coming to the product roadmap, then there is something wrong. So, this is really what I see most that it's really often, it's a plan, it's a task plan and the level is not right. So, it has to be still on a strategic, but execution level.

  - Whose advice on roadmapping do you listen to?

  - I have, I wrote it down. So, I hope I pronounce it. I had, I follow on LinkedIn, Itamar Gilad. I don't know if you know him because-

  - Itamar is a previous guest.

  - I think I've seen him on a list because I really like his very practical approach, right? We're talking about it. And then, I mean, I don't know how many product roadmaps I did. And always there were, what I was saying before, no context or too much context, people were very overwhelmed. And I really liked that he gave a very forward approach on like, how can you have outcome-driven and features still in the same roadmap without getting killed? Also, like being okay with that.

  - So now the hardball question. If you had to distil your philosophy on roadmapping down to one or two sentences, what would it be?

  - For me, a roadmap is a strategic experimentation tool. So that means for me, experimentation is important. How do I get this into action? And it's really giving you a plan or not a plan, but a map. How do we get from a strategy where we have hypothesis into something where we have the validation of that?

  - What's your biggest roadmapping failure?

  - I think it's like something with everyone. Every product manager can relate to trying to make it right for everyone. Everyone who comes, you always try to like, yeah, let's try. And you're not saying no, you're always trying to put everyone first. You don't think about your team who has to execute. So, this is the thing where I'm looking back and I'm like, oh my God, I think I did. Yeah, it was really the biggest. And it didn't just happen once. It happened more than once. I really have to admit to this. Where I'm like looking back and I was like, but you know, in the beginning, we're not that confident. We need to work on our confidence to say no. And also, to understand, like you'd still have to work with these people together. So, a strict no is also not working. How can you work with people together, say no, but in a way that they understand.

  - Annett, it's been awesome having you here today. I always like to end with your opportunity to pitch yourself, how people can get in touch with you and how you can help. Fire away.

  - Yeah, thank you for that. So, my company, it's called Product Emerge. You can find it under productemerge.com and I'm offering a coaching for product leaders. I have a master class coming up. The waitlist is open. And if you're interested to become a, if you're a senior product manager and you're interested to become a product leader, a lot of people I've talked to really want to become a product leader, don't know how to do that. So, I have a free master class, but also some coaching programmes for them, helping them to become a product leader.

  - Awesome. Well, we'll make sure the links are down below as well. Annett, it's been wonderful having you here today. Thanks very much.

  - Thank you. And it was so fun talking to you today about roadmaps.