Is anyone's roadmapping perfect? | Francesca Cortesi

In episode 39 of Talking Roadmaps, Justin Woods interviews Francesca Cortesi, CPO at Hemnet. They discuss Francesca's journey in product management, her experiences with various digital products, and the evolution of the field in Europe. Francesca shares insights on effective team collaboration, the importance of learning, and the challenges of creating impactful products.

Francesca loves building products, working with people who make me grow, and bringing a positive change in everything I put my hands on.

In her career, she was part of building some amazing digital products: from a global community for girls to express their creativity, to e-commerce platforms, a two-sided marketplace in its expansion phase, and a startup in the sustainability space. She is now CPO at Hemnet, the world’s most popular property portal.

She is passionate about creating products that bring good to people's lives and doing it together with a team of people from whom she can learn. Learning is the fuel she can’t live without.

She believes in inclusion, that a team always achieves better results than its individual contributors alone, in healthy discussion, and in people who are not afraid to stand up for what they think and feel.

She also loves to write. You can find her thoughts at www.francescacortesi.com

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

Is anyone's roadmapping perfect? | Francesca Cortesi

Justin Woods and Harry Max

In the next episode we are talking to Leah Tharin, B2B Growth advisor and PLG Expert. So watch out for Season 1 - Episode 40!

• Transcript

  - Hello and welcome to the "Talking Roadmaps Channel." I'm one of the co-hosts here, Justin Woods. And in today's session I'm joined by Francesca Cortesi. Francesca, welcome.

  - Thank you so much for having me, Justin.

  - Absolutely. It's a pleasure. So why don't we jump in and maybe give you an opportunity to introduce yourself and tell our listeners a bit about what you do.

  - Of course. I'm Francesca. Hi everyone, I'm originally from Italy, but I've been working and based in Stockholm for the past 12 years. And in all those 12 years I've been working with product development, and latest here I'm CPO or Chief Product Officer, for the ones like me that don't really love acronyms, at Hemnet, which is the biggest property portal in Sweden, and one of the most loved brand in the country as well.

  - Wow, that's amazing. And you've got a rich background of product management, and project management, and also engagement, and things like that, so a kind of a really relevant background.

  - Yeah, I mean, I normally say that I fell into product. I mean back then, back in the days there was not really something in product management. Maybe in the US I might say, but not in Europe. So it was a lot about digital products, and it was project management first, and then I worked with engagement communities, and then, I mean, as the year were going, I realised that's actually product management that I was doing, so yeah, I've been seeing piece and be this of, not everything, but many different companies.

  - Love that, and do you know what? My journey was the same. I found about product management by working with product managers and then going, "Hang on, that's all of the combination of skills and things they're doing that I really want to do." And then once I found it, I, you know, I've pretty much been in that area with many areas of my career, so that's really great. Why not subscribe? Click the bell icon, and give us a like. I wonder if we jump in and talk a little bit about roadmaps and maybe what, from your perspective then, what the purpose of a roadmap is.

  - Can I start with a controversial revelation here? Maybe like in this talk, but I mean, I was one of the ones that every time one of my stakeholder asked me for a roadmap, I was rolling my eyes and I was thinking, "No, ever, no, I'm not gonna give you that." Because at the beginning of my career is really like linked to the roadmap as a set of feature basically, that someone wanted out of me. And back then I've not seen that working. I mean, you know, just like basically if you want a set of feature from me, you want me to predict the future, and say that nothing will ever change. And then you're gonna hold me accountable for that. And that, you know, at the beginning I was a little bit naive and I did that, and then I got burned a couple of time, and I stopped even saying the word roadmap. It was almost like taboo. Like, oh my God, I mean, if they want this, we're not gonna doing product development as we should up until basically a couple of years ago, one and a half years ago. When I start to rethinking, you know, it's like almost questioning myself. I mean, there are people a lot of more talk in the community about roadmapping and I've learned that you can do roadmapping right if you know what I mean. And I mean, to me, roadmapping today means having a tool where you actually can define and align around the direction you want to move towards. So it's a lot about, you know, defining the goals, and defining like where you're heading, and having an alignment around it. So that's like if done right, it's really a powerful tool. But I've been burned a couple of times, so I've, my relationship with roadmaps has not always been easy.

  - I laugh knowingly, because that's such a wonderful answer, and I feel so the same, you know? You land into a product management role, you're told, you know, I want a roadmap. The stakeholder thinks they know what they mean. You think they know what you mean. You go online and look at what they might mean. You go and create something. And often, you know, the first creation of a roadmap is something that we get burnt by. And that's actually one of the reasons for having this channel "Talking Roadmaps" and my own company, Roadmap Heroes, is to help people understand that's not what we mean. And to rethink this, it's a very misunderstood area. So I love your response to that because it's so true, but we don't want people to learn the hard way.

  - No, hopefully now we learnt the hard way for them. I mean, that's the old point of product communities, right? That people can learn from others' mistakes. And I mean, please don't go there. If someone ask you, like a list of feature in a timeline, don't do that, please.

  - And in this, I'm sure this is something you feel passionate about as well, but by doing that, by having stakeholders requesting that, it's disempowering product teams, and turning them into delivery teams.

  - Yeah, and I mean I think like there are different, like depending a lot of the company when you work for, I mean it happened to me many times when I was working at startups, and I mean at that point was like, that was basically a matter of company survival, right? I mean we needed to hit certain targets, and we needed to hit certain numbers. And I mean, the problem exactly as you say that there was someone somewhere in the room that thought that that exact feature will get us to hit those targets. And then basically what they wanted from me is like, "Okay, when is it out?" When the conversation should be around, "Okay, what target do we need to hit? How do we know that we done best?" Okay, that is a conversation that you can have to then define like in a timeline, "Okay, we're starting here and how much time do we have?" Sometimes also times is big matter in that it was for me back then, I mean we literally did not hit our numbers, and the company doesn't exist anymore. So I mean there's like shift in the conversation subject, but that's not always easy. It was not easy for, it's not what I thought about. I mean the first time I got that PM title, and someone asked that to me, I was like, "Okay, let's try. Team help me, when can we get this out?" I mean, you know, I did not think all those thoughts.

  - Absolutely, there's so much learning that we go through on here. And I want to pick up on something that you just mentioned, which is that there's a lot of different people that we speak to from a roadmapping perspective, a lot of people that feed into that. So from your experience, who's been the audience of a roadmap?

  - That's a really, really interesting question, because I mean, if I go back how I think roadmapping today, to me it is basically laying out what we think are our best initiatives, opportunities, bets, I mean there are a lot of terms around it that we will work on to deliver on our goal, or strategy, depending on what your company's working with. So that alignment needs to happen across the board. I mean, I work with roadmapping with our board of directors for example. One is like on a more strategic level, I work with roadmapping with the management team, I work with roadmapping with my PMs. They work with roadmapping with the teams. Also, like there's a lot of different, we have 10 product development teams at Hemnet, so there's like syncing around those as well where the roadmap is useful and there's always, you know, that calibration of cross dependencies and level of details you have in a roadmap, and you know, all these kind of things. But those conversation and the roadmap purpose, I would say that goes everybody in the company.

  - And it is a communication tool. It's something where we want to bring people along for that journey, and like you said, I think, you know, the most empowered roadmaps are ones that share with everybody. There might be different levels of information maybe, but if we've got a direction, everyone needs to follow in that same direction to get there.

  - Exactly, and I mean of course that's, I think right now is the trickiest part. And I mean also I wanna say we have not figured it out in all pieces of the puzzle, definitely not. And I mean that's the trickiest part for me at least, that you have like basically to say the same thing at different levels, because there are different level of details and understanding needed to actually make the roadmap work. And that results in a lot of different artefacts, and a lot of different names that create confusion. You know, it is like finding that balance is something that we have not succeeded with yet.

  - Yeah, that's right. And it sounds like that the roadmap is maybe a, from a hub and spoke model, it's the roadmap is something, but it draws from many different areas. I think you've touched on some of those. What do you think the relationship is from a roadmap to things like vision, strategy, objectives? How do you think those tie in together?

  - Yeah, and I mean that also I think it's super dependent on the company who you work for. I mean, I've been working on a company where we did not have such a long-term strategy, or that was not the purpose, right? But we still had goals, while right now we'd have all the pieces, we have the vision, we have the strategy, we have the product strategy, we have the roadmaps, we have the OKRs, I mean almost you name it, we have it. And I mean the most important thing I think that all these pieces of the puzzle needs to be tied together. So I mean to me it's, for example, we're working right now, we have a product strategy. I mean we have, let's start, we have a vision and we have a company strategy. And that's the reason why we have a product strategy. Like we have like, you know, for example, we're a public company so we have to open goals for our company, which is, one is about growth, and one is about profitability. And I mean it is because we have those goals that we have the product strategy we had. I mean if we had something else, you know, only profitability to 80%. I mean that will have another type of product strategy. But we have both, so I mean those two is like answer the question why we have the product strategy we have. And then the product strategy, it's the baseline when we choose our objective for the year. And I mean the strategy, I think it was Janna Bastow, I was at a conference with her, she is like the inventor of the Now-Next-Later Roadmap. And she said, like this sentence that really stuck with me. "Your roadmap is the prototype of your strategy." Which I thought was really a brilliant way to framing it. So basically what you do, you take your strategy and then you define, okay, what are the first step? And you start executing and you start validate or invalidate them. And that's how the all learning goes together. And we do it, you know, bringing, breaking down. We have the strategy becomes objective in the OQR framework for the year. There is objective that goes into, we work with continuous discovery, so opportunity solution tree. And then with that we get some learnings and we either tweak back the roadmap or we continue with it, because we have even more evidence that we were right. So that's how we do it here at Hemnet. But before, you know, I did not have strategy. I had some kind of like, you know, "We need to survive" a kind of goal. But I mean the what if there's one element that I think should be there in every roadmap, no matter the company, and no matter how many tools you have to support you, it's a goal. I mean you need to know, you know, what you're trying to achieve and how you measure that goal. And then with that, that's the very bare minimum I would say that you need to choose, what to work on. Otherwise you're gonna have like as I had, I mean in total honesty, a list of different feature, which you will get them out of the door, but you had no, you will get that specific metric. Okay, the click or no click, but did you move the needle? You'll never know.

  - Oh, I love hearing that. I wish I'd heard you about 10 years ago when I kind of needed some of that guidance. I brought in a roadmapping tool partly to help me at Vodafone to bring my team together and understand where we were going, but also to demonstrate that there's so many things I can pick apart from what you shared there. But you talked about company strategy decomposing into product strategy and being so vital, and sometimes a little bit further down. And what I wanted to demonstrate was there was pressure on me to provide strategy and direction to my team, but I also wanted to demonstrate that actually there was a lack of strategy and direction for us to tie into. The other bits that you mentioned, you know, opportunity solution trees. And now next later we've been fortunate enough to have Teresa Torres and Janna Bastow both on the channel talking about those, such valuable concepts. But hopefully to our listeners, and maybe to some of our listeners that are new in the space, what Francesca's just said there is showing that whole line of sight from here all the way down and also prototype for strategy. These are hypotheses that we need to test, not fixed deliverables that we need to deliver no matter what, and we don't understand. I mean there's just Francesca so much gold in what you've just shared there.

  - Yeah, just like one thing really, I mean, that's the biggest mistake I've made. I mean, and I think some people make or are, you know, expected to deliver is a deliverable list. And that is like, if that's what you are asked to do, don't call it roadmap because that's not a roadmap. The most important thing is that the roadmap evolves. And it should evolve with learning. It should also evolve, I mean one important thing, I mean 2023, I mean everything that is happening around us that we cannot control. I mean, I would really love to know if anybody back even in December, or like when we sat defining like November, December, when we normally like sitting and decide next year roadmap, who knew about the economic downturn, who knew about ChatGPT, who knew around AI? And I mean all these things might impact more or less your business, might impact more or less like the business goals. And I mean those of course should be reflected in the roadmap, so find your way of getting in this learning and this evolution of the roadmap. And especially don't sell it as a set plan, because then you're gonna fail.

  - Absolutely, you're setting yourself up. It's not what a roadmap is for. If you're trying to do that, it's a delivery plan. It's a delivery schedule, totally agree. Let's talk about just quickly, who maintains a roadmap and who owns the roadmap, or maybe who owns it and who maintains it? Are they the same people do you think?

  - I think that maintain, it's a really interesting word. I would say that in my, I mean this is a little bit visionary, and there's a lot of details in the real world day-to-day life, so I mean take it from what I am, but I mean I think the vision for me is that the roadmap of course needs someone defining okay, what is it? And driving the conversation. And to me that is product, and I mean exactly when product depends a lot on your organisational structure, it can be VP head of, for us it's like PMs, and then I have the act of like having the overarching perspective. But then it's really important that, I mean who actually maintains, I would say that the learning maintain the roadmap. I mean it is like you, what we did is we tried to put in some moments when we reevaluate, and we learn, and we get those insights. And those insights can come from different ways. It can comes from all the experiments that we've done. That's one, it can come from the market, and maybe we have like for it's the management or the board that say okay, we have to change direction. It can come from your sales department, because they say that, you know, some customers are struggle more than others, and then we thought that we could monetize those customer. Yeah, maybe that's not a good idea because you know, I mean something else changed in the, yeah, in the macro factors. And it could come, you know, from, yeah, from all the interviews that the teams do with the opportunity solutions, right? I mean that is like in the maintenance part I would say that everyone has a responsibility to pitch in and the responsibility of you owning the roadmap, whoever you might be in that organisation is that you have to make sure that those learnings, those inputs are part of the roadmap process. So that is not, you know, someone sitting with their nice Excel sheet or you know, I don't know, whatever weapon you chose for your roadmapping and then the life happens somewhere else.

  - So we talked about some of the kind of the elements there. You're teasing about some of the things on the roadmap. What do you think are some of the key elements that you like to see on the roadmap?

  - I would say if I really have to make it as easy as possible, because I mean you can really go nitty gritty in the roadmaps, and go into literally like details of it. But I mean for that to be understandable by everybody in all, like you know those different layers we talked about on this different inputs you need to be clear about, I think you need a goal, which is basically like what you want to achieve, and that you might have that connected or not with a strategy, but I mean not, you still need a goal. I would say you need key result, or a key metric, or a success metric, whatever numbers that tells you that you're proceeding in the right direction with that goal, so it's not only a formulation of, "Oh, we want to do this. Okay, how are we gonna actually measure that we are proceeding in the right way?" And then I would also say that the roadmapping also needs to include formulation of the how we plan to achieve those goal. And it can be depending on how far you got with your learning, with your research, with your testing, it can be on different levels. Sometimes it can be a specific product with a specific go-to market that you want to do. And I mean that's, I mean especially important for B2B, I mean we know how much flexibility we want, the many customers follow sales cycles that we kind of need to somehow jack into, you know? So I mean, that you need that, and I mean you need that level of definition, when you get there and when you work with those products. And sometimes it can be, like an idea about a discovery. I mean it could be a completely something else that we believe is our best opportunity to reach that goal, but we don't know quite yet. So the level can be different but a formulation of the how, I think it's important to tie back together what you want to discuss is is everyone aligned that these are the best things that we can do to drive those goals. If you don't have that formulation that the conversation becomes really difficult.

  - Yeah, yeah, that's perfect answer. You know, this is what we understand now, at this point in time, and it may change. One bit that you picked up on, and I'm sensing this through just through our conversation, is the learnings and the testing and the hypothesis. I don't see enough of that with product teams. Is that something that you like to show on the roadmap going, "Hey, we're thinking about exploring this area some more and we're gonna spend some time here to explore that."

  - I think we could be better at that. I mean we have a lot of experimentation ingrained in our ways of working. I mean it was like that, I mean before my times. I've been working at Hemnet four and a half years and even before that there was an ingrained culture of testing, of like AB testing, and hypothesis testing, which I think come a lot with one might say with the responsibility one feels on one shoulder when we work with one of us Sweden's biggest product. I mean you know, we wanted it right. So that was something we had. We added on top of that opportunity solution tree and we are trying much more depending on the, how we formulate our roadmap to define this is something we know more about. This is something we don't know yet, but we believe in. But this, I mean you are pointing at something, because again, I don't wanna give the impression that we have it all figured out because we don't. And this is I think really important to talk about. I mean it is not that everyone does everything perfect. There's a lot of roller coastering going on, and this is something that sometimes it's a bit challenging for us, like having that conversation what is something you're exploring or discovering, or you're not sure about, and what's something you're sure about, because that, what's the difficulty of that? Maybe if you are like someone who's interested in that roadmap but you're not like working day to day with it, you might get the impression that all the items in the roadmap are the same when they're not. And then it becomes a little bit, you know, "Okay, what happened with that thing you were working on?" "Oh, it was just a test." "Oh but we sold it in," you know. it is like this is like this kind of misunderstanding and this kind of navigate different kind of levels that yeah, sometimes we do it right, sometimes we don't do it right. I don't have the silver bullet because we've done it wrong couple of times. Giving the impression that what we were doing was actually decided when were what we were doing was one way that actually turned out not to be the best one and then we just thrashed it.

  - Yeah, absolutely. I still get the feeling that companies aren't changing their roadmaps enough. And I think what they need to be doing is saying, look, you know, changing them frequently to get to almost show, "Look, this is where our thoughts are right now. Things are changing," 'cause if you change a roadmap quite frequently, it also shows that your thinking is changing. It shows that we are not sure on some of these things. So I think companies make the mistake of saying, you know, they create the roadmap, don't change it for six months, God forbid it, you know, in a year's time. And because their stakeholders don't see that change, they assume that it's concrete. And I think changing that roadmap frequently is almost helpful in that people then start to go, "Okay, this document can change, the roadmap and the thinking can change. I'm going to treat it as if it's something that can change." Because it can and it should.

  - Yeah, and I mean I would love to hear your thoughts. I mean that's one thing that I have in my head lately. I have not make up my mind yet. But one challenge that I see, I totally agree with you Justin. I mean, it should change, otherwise it means that you have not learned anything in the time, in the timeframe that has passed. And I mean we have this quarterly review, and those, you know, but I also thinking about how we at least treat the timeline of a roadmap. We still like, you know, start the year and we treat, you know, okay, what are gonna gonna next year and I think more and more it's connected that that is connected with how the company financials work. You know, that, I mean you need to hit, like as you have 12 months, you need to hit some certain targets in this 12 month as a public company especially, you need to have like certain numbers, certain quarter, when in reality what I'm feeling more and more is that we maybe, maybe I'm not sure yet, but maybe we should consider like a rolling four quarter for our roadmap. Like, you know, you have something and you learn every quarter and you adopt, and you go further, and you kind of keep that loop instead of thinking, "Okay, now we're sitting in defining a plan for the next 12 months and then we revisit." But it's still, when it's the 31st of December it's cut, and then we need to do something else.

  - I think sometimes we're almost caught into, I think sometimes we don't challenge enough. And so, you know, we don't challenge our thinking enough, and that's where product management, and what I've learned from product management is great, is being curious and to try and find out why. I completely understand what you're saying. I think sometimes because roadmaps are looking at, it needs the whole company to get behind it. Sometimes we can be bound by the milestones or the cadences of other departments. So I think just because we do financial planning, and that might be, you know, at the beginning of the quarter, or sorry, they look at a financial year that we somehow bind ourself to that in product management. And there is no need necessarily. We need to know what budgets we've got and the spending, but that's just an annual top up. And I love your thought about this rolling roadmap, because we don't in quarter one have visibility 12 months out, and we don't by quarter three only think about what's coming up in the next three months. That's not how we work when we're in product teams. So we do work on the rolling window, but I think we work with organisations or teams within our companies that do very much do that fixed. And we should almost disconnect ourselves a little bit.

  - I mean I would love if anyone listening to this has like thoughts about it, if you're done in a rolling, let us know, I would love.

  - Exactly, and I think Janna's roadmap, the Now-Next-Later is helpful in doing that, because it tends to try and encourage us to disconnect from, we have timeframes, but even then they're not necessarily quarters. They can literally be now-next-later. And I think that is helpful in that rolling type roadmap there. But yeah, audience, let us know in the comments what you think, help us out here. Have you seen something that's worked well for you? We'd love to hear. Francesca, I wanna go into, actually we've alluded to it already, which is one of your preferred ways to visualise and style for a roadmap. You come across as a creative person to me. So I think something that looks beautiful and compelling is important. You've also talked about now-next-later, is that how you like to sort of create and present your roadmaps?

  - We tied roadmap with OKRs. That's like the, the main, so I mean the very beginning of the year when I normally like to go back and say, "Okay, this is the why, why are we doing this?" So we tie it with the product strategy and we tie it with OKRs, so which are on a company level. And then we kind of go from there. But if I have to be completely honest, I have not found a super sustainable way of like, of working with roadmaps. We work with like, you know, those are presentation that we do, so there's are slides, but then I mean as things changed it's like, yeah, you have a lot of different version and you don't know which one is the most updated than the teams that work and do the learning. Some work with Miro and some work with Trello, or the combination of both depending on how they do. And then that is not automatically connected with the roadmap. We have a common backlog that is in a sheet document, because the most important there is like the priority, but that is not super, you know, there's a lot of detail. So for somebody that just want to overview, you're not gonna get that. So as you are noticing when I'm talking, we have a lot of different things, but I've not figured out quite yet, which is the best. I try, I mean for what we do now, try always to think about the audience, and what is important for that audience at that specific time. And many times when I talk about the roadmap is more about the overarching view. And then I try to mostly connect the dots, and therefore I use slides for example.

  - Yeah, and that's so true. This is the reason why there isn't one size fits all roadmap template out there, because it is a communication tool, it needs to communicate to your stakeholders within your company, and every stakeholder within every company is different. And so you have to tailor it to that audience. And I don't think this one size fits all really works there. I think sometimes tools can be very helpful, but it's difficult when they're, you know, again, I had teams giving me roadmaps and different things that I had to create a summary view, and I'm sure you do as well, which can have its own challenges, but in terms of the way that that roadmap is styled, it has to do its job of communicating to that audience what they need to know. And in, in those instances it can be very different.

  - And I mean just another piece of advice, don't start with the tool. I mean, I've been doing that so many times of like, "Oh, if we just had this tool that will visualise in this way." And then we spend a lot of time, I'm not gonna reveal the, I mean, with this complex tool on the market to set it up, and it still did not make the job right. So I mean the tool won't fix.

  - Totally agree, and you know, there's so much that you've said there that resonates with me. So I think the process of roadmapping is the most important one, going through that thought process. Tools are there really just to expedite process. And from what I've found, I don't know if you were familiar, but I worked at Aha! for three years, so I kind of was really passionate about roadmaps, introduced Aha!, I was there for three years and now I'm running my own consultancy, Roadmap Heroes, which is more, you know, we're moving into more of an agnostic space because what I found during that time was that the tool is great, but if you don't know what your roadmapping processes are, the tool's not gonna help. And so, you know, it's really important there, again, it's not the silver bullet, it can help in some cases, but if you don't understand the purpose of roadmapping and the process of roadmapping, a tool's not gonna help you completely. So, such good advice there. And I would absolutely echo that to our viewership and our readership, or listenership even is it's that understand the purpose of roadmapping and what you are trying to achieve with it. What's the job to be done? And then look at if there's tools that can help, don't start with the tools.

  - Many times you can start kind of easy, like, you know, many times you have already the tool, the simplest form of those tools that you can test with. And then if you really feel you need the next level, then there are tools that are made for this in the market.

  - I think that's such a good best practise with roadmapping. If you're new to roadmapping and you're listening, definitely start with that example of what Francesca's mentioned. Start simple, be curious, product managize your roadmapping process can do you a lot of benefit. If those are some of the best practise, what do you think are some of the mistakes that people make? And I think we probably talked about that earlier because we've made those too.

  - Yeah, I mean I think like the biggest mistake that I see and I've done, it's like a feature roadmap, like, or like a feature list in the shape of a so-called roadmap and especially a feature list of feature that, you know, god knows how they are connected is like more wishful wishlist, wishful thinking from somebody not connected with any kind of goal, that's like a pretty common mistake. Also that is something like all the listener, viewers, please have an honest view of what you have in your backlog and try to, I mean, what are you prioritising? Are you prioritising feature? Are you prioritising behavioural changing? Are you prioritising something that drives you towards a goal? I mean that's like the very first sanity check you can do. And then you can move those in a timeline in the roadmap. I also think that the super big mistake that which touched upon is that communicating the roadmap as something static, and done, and fixed, and it's gonna be delivered exactly as it is in that Excel, or sheet, or tool visualisation of your choice, because that basically is based on a one extremely big assumption that I've never seen becoming true. That is things do not change, or you do not learn, or you're always right from the beginning. And if you already know everything and you feel 300% correct and you believe that nothing you will learn, or nothing will change outside of your door, by any means, you have like a biggest competitive advantage ever, because you can bet safely and you can just deliver. But I've never seen it happening, so please don't, I mean big mistake is like thinking that the roadmap is like fixed and won't change, because then you're gonna have a lot of trouble explaining why something changed, because you learn. So you kind of have to justify your learning, which is not something you want to do. You want to use your learning to tweak your roadmap, not, you know, to the other way around.

  - Absolutely, you know, it seems crazy to me and it's still laughable. You can speak to the sales team and say, "How much revenue you're gonna bring in in 18 to 24 months time?" We don't know, how much are the marketing team going to be consuming from the budget to go and market to our customers, we don't know. Why can't you tell us what the product roadmap's gonna look like fixed for 18 months you're building? So it's like why is there a level of uncertainty that we afford to these other functions? And yet when we think about product teams where we are building something new, by the way, we've never done this before. We hold them to knowing exactly how long things are gonna take, it's madness. But it's almost this bias that you find with people that somehow, because we're building something new, we're gonna know exactly how long it takes. It's madness.

  - Yeah, I think it's like, in my experience it's a little bit connected to the two factors. One I'm in sales, sales marketing team that might know, don't know exactly, but they do have a goal and a target. I mean those are really explicit, and it's not always just the goal and the target for product are so explicit, so that's like circling back on the importance of having goals. And the other part I think that, you know, one always have to be a little bit self-critical. And I mean there are some teams, and I've done it myself as well, I mean we, you say, "Oh, we need to be agile." and then we don't want to, you know, commit to anything, or like, "Oh, we need to do research." And then we close the doors in six months. I mean that ain't gonna fly either. So needs to find like that balance of having that goal. And also, I would, another piece of advice, it's like try to find those smaller deliverables in your roadmap that can actually show progress, because as one you show progress, actually another, you know, I think you are seeing with other lenses, exactly as you were saying, like different department. I mean you have an all other negotiation power even like, you know, for your discovery time if you are at the same time delivery, because at the end of the day, that's what we want. You know, to hit those targets and deliver this value for the customers and the business.

  - Yeah, it's a confidence thing. It's showing that we are delivering some stuff. It's getting trust in it, and I think, you know, as we start to the world comes around to outcome based roadmapping that it's actually saying, "Look, we can't describe all this stuff." It's almost the roadmap is helping provide some trust into our team's process to say that we're working on what we say we will, this is what we think we need to be working on. Getting some quick wins in there to build that confidence. But also when we say that we need some more time, or we're not sure, giving us that flexibility to go away and run some more tests, or some more hypotheses. Love that response, so maybe a quick question on this one, is there a pet hate that you just don't like to see on the roadmap?

  - A feature that doesn't tie at all with our strategy? I mean if I have, or even an, it doesn't have to be a feature, like whatever something, because we need to do this because of this client, whatever, but it's completely misaligned with what we're trying to achieve. That I don't wanna see in the roadmap. Still on your, if you flip the coin, if you have that visualise, you can at least have that conversation. So it's much better than like someone working on it behind the scene, if you know what I mean.

  - Do you think that, and I totally agree with you, do you think that sometimes it might be that we do know we need to work on a feature, but we need to add something to our strategy to accommodate that? So I think sometimes we wanna get away from pet projects where we put a feature in 'cause we need to deliver it, and we don't tie it into strategy. But is it possible that if we do have a feature that we know that we need to work on, it alludes that there should be an element of strategy that we create to accommodate it?

  - Yeah, I think so. I mean to me it is like, as I like to think about it, we have this strategy, I mean for us it's like, we have formulated as a customer behaviour. And I mean that should be the baseline of how you choose what to prioritise. So like is this driving this behaviour, or this is not driving this behaviour? If the answer is no, then I will argue, "Okay, why are we doing it?" And if we have that in the roadmap, that might be a conscious choice, but we need at least to have a conversation of why we are deciding to take that conscious choice. And in my experience many times has been not a conscious choice. So that's why I think those kind of like, derailing from the strategy, if like, one has to be really general, those are the ones that I don't wanna see in the roadmap.

  - Francesca, you've got some great thoughts around roadmapping and obviously some amazing experience around product management. Who's advice do you typically listen to, and maybe in the field of roadmapping specifically?

  - Yeah, for roadmapping, I have two favourite ones. And when one is Janna Bastow. I think she's really great and I mean she has my favourite tagline that I always use. And the other one is John Cutler. I think it's also is more like, I think he's done a couple of visualisation about also the, how to connect roadmapping to execution. So it goes a little bit also into the sprint planning or whatever you might be working on to see how to incorporate learnings in that to feed back to the roadmap. And also I think he does a really good visualisation of how to talk about the uncertainty levels on the different pieces. So those are the two.

  - Love that, and I think that's really important as well. Talking about uncertainty or sometimes confidence in our hypotheses, or what we're working on is really important to communicate. Again, that the roadmap is not a fixed delivery plan and neither should it be. I wonder if you had to distil your philosophy of roadmapping into just a couple of sentences, how would you describe it?

  - I mean, when you think about your roadmap, think as that, think about direction, think about collaboration, and think about evolution. So you tie, if you are able to tie the three together, then you have like this prototyping of your strategy that keeps on evolving based on, yeah, how well you collaborate in your company, and how well you're receptive of everything that is happening around you. And that should be setting you up for success.

  - But also with the fact that it's going to evolve, it's a part of a process. Those things can move around together. That's such an articulate response. Francesca, I love that one. And so I wonder if there's anything about roadmapping that I should have asked you, but haven't, what are your thoughts? Anything that I should have asked, or you want to mention about roadmaps?

  - I think we touched the most. Please take, I mean learn from my mistakes. Don't do those features. Also, I would really, really love to hear if someone is working with this rolling quarter, and how you make it work with financial, or other company structures if we wanna call it like that. So that's more a shout out to the community.

  - Totally, and I think that also picks up on the fact that of why road roadmapping is different, because it depends on your product maturity, your company maturity, the type of product. It depends on so many things as to to what your rhythm is gonna be on the roadmap, the detail that you show. And that's why I think in a classic product management term, it depends, and I love that response.

  - We're really political answer.

  - Francesca, it's been wonderful speaking to you. Just wanted to give you an opportunity just to share with our audience again what it's that you do, and how they can get in contact with you.

  - Yeah, lovely talking with you Justin as well. In this foggy morning here in Stockholm, and I, one thing that I'm really passionate about and I try to share as much as I can is how we do our think about product in practise, because there's a lot of theory and we can all learn and read theory, but there are not so many people sharing how they actually do and the trade offs and such. So I write about it on my blog, which has my name francescacortesi.com. So I wrote a little bit about roadmapping. I will write more as we learn, so that's one way. And the next time if you wanna meet me in person, I'll also gonna be speaking at a Product at Heart conference in Hamburg that's at the end of June, I believe. So those are the two. And of course like you can always find me on LinkedIn.

  - Francesca, we'll put those details down in the description so our audience can connect with you. Hopefully you see some comments around what they've thought of as well. But just wanted to end there. Thank you so much for spending some time with us, being generous with your time and your knowledge. So many things that you've said have resonated with me. I wish I'd known some of those when I was first starting out. There's some bits that I've learned from you now, and some little bits that I'm gonna take away as well. To our audience, if anything that Francesca and I have said has resonated with you, please do consider liking the channel or liking the video. Please drop us a comment below and let us know, and consider subscribing to keep up to date with other sessions we might have with other people. If you do wanna get in touch and be where Francesca is now, let us know. Again, we'd love to have you in the hot seat. But for now, Francesca, I hope the sky's clear for you. Have a wonderful week ahead, and thank you for being with us. You too. Bye bye.