Should you show your roadmap to customers? Especially in PLG? | Leah Tharin

In episode 40 of Talking Roadmaps, Leah Tharin and Phil Hornby discuss the importance of sharing your roadmap with customers, especially within a Product-Led Growth (PLG) framework. Leah shares insights on transparency, customer trust, and the strategic value of customer feedback in shaping product direction. She also touches upon her experiences at Smallpdf and other tech companies, emphasizing practical approaches to PLG.

Leah Tharin, Head of Product at Jua.ai is a leading expert & advisor on product-led growth & sales, a modern way of thinking about Growth in B2B. She led the core product at Smallpdf a B2C platform with over 50mio monthly active users up from 3mio in 2 years, making the document management platform one of the biggest in the world. She writes about her experience on www.leahtharin.com and educates on product-led growth & sales also on her podcast the "ProducTea with Leah".

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

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

In the next episode we are talking to April Dunford, Author and Positioning Expert. So watch out for Season 1 - Episode 41!

• Transcript

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

  - Hi, thank you very much for having me. My name is Leah Tharin. I'm from Switzerland. I've been in tech for 24 years. Every time I say that, I feel a year older and I've been at Microsoft, at DeinDeal which was a group one in Switzerland. I've been the expense-product lead of Smallpdf with, which is a document management platform, probably most now, 50 million monthly active users. I used to be the head of product at jua.ai, a big machine learning project around delivering machine learning based weather forecasts. So a completely revolutionary concept on that side. And now I advise companies around product-led growth and how to think about distribution in modern markets. And yeah, I'm very happy to be here and I love roadmaps or I hate them, but we'll see.

  - We'll see. I mean it is definitely a love hate relationship with roadmaps, I think for many people.

  - Yeah, I would say, I would say that's true. It's a very polarising topic, but I think it comes less from the framework but more from, you know, like how to do it wrong. There's a lot of creative ways on how you can get roadmaps wrong, I guess.

  - If you're enjoying the channel, subscribe, hit the bell and give us a like. What is the purpose of a roadmap?

  - Oh, that's a very good question. I'm pretty sure if you ask 10 people, you get about 12 different opinions. So it really depends on in which company you are at what point and what the C level has heard as a definition of roadmap is. I think let's just go with something that is useful. I would say it is the intermediate layer that you unfortunately need between the strategy, the vision, where you want to go in the future with your company to make a lot of money. And the operational layer that we have in the teams, it seems to be that a quarterly planning of what you want to do next is not enough. So roadmaps are like, just like I feel like they are the connecting glue between the strategy and the OKR level, but it is a glue that you should not sniff too much. I'm gonna say that. Yeah.

  - Yeah I was actually working with one of my coaches yesterday and he was saying after we had a conversation about the content, "It feels like it's only gonna take me half an hour to fill this in. Is it valuable?" I said, "If it's taking you more than half an hour, then I have a problem with it, because it's a storytelling tool." That's not kind of, if it takes you a long time to create the roadmap, then that means you haven't had the conversations beforehand to know which direction you're going.

  - Yeah, I guess that's true. It turns out also like if you go into scaling companies, so like if you kind of scale up the process that more roadmaps tend to take because you also need to sync it with more departments and then you might have some financial planning requirements from your finance departments on what you have to kinda have to start to model all the costs, you know, like all the stuff that nobody wants to deal with, like how much money will we make in which month at what kind of velocity. And the roadmap unfortunately is kind of like one of those tools where they just wants to see what your plan is and then you try to attach some numbers to this, which are definitely wrong. And then you also have no idea on what they're going to be, but they're still better guesses than, you know, you just, I don't know, not substantiating anything. And that's usually what it is yeah.

  - And so you start to hint there at kind of who's looking at this, so who's the audience of our roadmap?

  - I don't know, like you'll be my guest. Like everybody can be the audience of the roadmap. I feel like the, so the way that I teach strategy, which is kind of like the same in the sense of for whom you do it, it's the first layer for me is always you have investors, which are people, you are owing something in terms of performance to. You have usually the board, then you have the C level, you have the operative layer, so like the teams, the people that are actually working on the specific products and you have marketing and so forth. And for all of these people and these have completely different, the roadmap has a completely different purpose. There's just one group that I did not mention on purpose, which is the customers and the users. And there's a very specific reason why I do not put roadmaps out to customers and users. If you assume that, or like if you are from the school of thought that roadmaps are inherently fuzzy and they will be wrong, then you should not put something out to the customers because they will hold you accountable. You will get the bad reviews if you promise something to customers that is not happening. There is a difference though, if you talk about a roadmap for, I don't know, an internal alignment, you know, like, so, okay, so what is the big market opportunity that you're going to address in the next five years towards investors for instance. Investors kind of have this really funny relationship with you where we kind of accept that there's some kind of level of BS in all of it, but we also know that it is necessary to make a really good roadmap. It is basically just like the best guess that you have for the next, I don't know, couple of years. Do you see some kind of path to a good opportunity? We all know necessary, not necessarily, like we might all know that this is not going to be the path most likely that you're going to take, but if you cannot see a path in a roadmap that at least sounds reasonable and that might sound counterintuitive, then you have no case at all. That's just like my personal, that is my personal opinion. And if I'm on the other side, like as an investor, like if I do angel investing or like I look into company's performances before I advise with them, I want to see a good roadmap, a good storytelling from someone that is in the business because that means if they can tell me a compelling story, then they can also tell a compelling story to the new joiner. And that is also very important, you know, like to get people to bring their power on the road relatively fast.

  - Now obviously I know you have a focus around product-led growth, so I'm wondering if there's anything related to that in terms of the audience and the purpose of it. How's it linked in there?

  - Maybe just as a very quick overview of what product-led growth is. If we talk about a distribution framework or like a distribution model that puts the product front and centre. So we show a lot of the value that we have sometimes over self-served models. That means like we're doing it for free or we give you some kind of free version of the full experience. And then we try to close these accounts by their engagement. So we wait until someone is using the product and then if we have signals that they're actually doing it, then we go after them with sales if it's a bigger contract and so forth. So at heart, this is what product led growth is. It's about showing value and not talking about it. There are some constraints when we talk about product-led growth companies. And that is as fancy and as fun as this sounds, your entire organisation operates in a very specific way, otherwise it does not work for product-led growth. So if you have a strategy and subsequently a roadmap on how to address this strategy that focuses on the product and only on the product, then you cannot run this from a top-down perspective where you are directive and tell others what to do. What I mean with that is if you are, you have fundamentally two choices. You can either run your organisation in a very collaborative operative from the bottoms up, right? So like the teams are coming up with their own roadmaps or they make suggestions and then we try to address them with, from the leadership level in some regards, or you dictate into the teams what needs to be done. The problem that we have with product-led growth where the product really is the driver of key value. So there's no one next to you to explain to you what the product does. It needs to be self-explanatory. It needs to be easy to use, it needs to really deliver value quick. You cannot do this if you're not close to the customer constantly. And it is impossible for business leadership at a specific scale to know everything about the customer. I can give you an example, right? So like at Smallpdf, we used to be 150 people when I left and we had about 20 different sub tools. It is you, you can spend your entire career on one audience for one very specific, one of the bigger tools simply because they had a completely different behaviour. They had a different demographic, they had a different ICP and they were just using the product completely different. And this is why you also have to approach roadmaps in this way on a very, very collaborative layer. And that means every quarterly planning, the teams are coming up with a roadmap and so not every quarter, but like every year they kind of define an overall roadmap and then they tie this to the OKRs that they have. But to this level, it is defined by the teams and not by leadership. And that is quite important in my opinion. It does not work any other way.

  - Sure and I guess I'm wondering if there's a dimension of having some of that forward facing direction of travel. Is that useful in terms of helping or from a growth 'cause you said not sharing with a customer. In my previous B2B life, which wasn't a PLG type organisation, sharing a roadmap with a customer was just normal practise. So I'm interested about how that plays out.

  - Yeah, so this is very normal or like this is how we used to do also business in enterprise sales driven companies. This is very, very common. Like also back at Microsoft, I mean we were just like telling, okay, like you know, in the next two years we're gonna bring a new OS and so forth. But I think you have to be careful when you apply huge companies that have running growth motions, that have running distribution systems, you know, like and release cycles that are just kind of like predetermined. I can as a company still announce a new version of the product like Windows 11, Windows 12, 13, 14, 15. That does not tell you what I'm actually promising you from a feature set. And there's a good reason for this why you don't wanna do this. Again, assumptions change, markets do change. You also wake some expectations. And there's another thing, I don't know a single company that ever closed a contract in a higher level, in a higher level plan based on a feature that was not deployed at the point where they signed. You still need to deliver some value at the present time that you have. It is kind of like a little bit of a myth that sales is sometimes peddling when they say that, "Well, you know, if we just had this particular feature, then we could close all of these customers over there." Or "Well, you know, maybe we are gonna give you a special price and then once we have the better features, we're gonna uplevel you into this other thing." You do not make deals on future performance. This is a fundamental shift in the market on how we treat customers. And the reason for this is that we have multiple commoditized solutions right now for the same problems. If you want to have a CRM for your company, you have a lot of choice now. Are you going with the company who is promising you something down the line in a year? Or are you going to go with the company that has it right now that lets you test it also in a demo. And this is because the friction of integration into your life of a tool is getting less and less and less and less, right? This is easier to onboard in a tool, it's easier to import and export data and so forth. And what that does is, is that, buying decisions happen faster, but there're also less valuable. Retention is harder to maintain in that sense. And the roadmap serves very little purpose in this buying decision for the customer itself. But it is an important tool for your internal product development for the bigger bets, and how you look at the market in like two to three years' time and the operative way there. Yeah, I would say this is a very important factor to keep in mind.

  - So we've got this thing called a roadmap then. Who owns it and maintains it?

  - Again, I think I would expect this on, this depends a little bit on the size of the company, but I would expect it usually coming from the product teams. So if you have product and you have growth teams, and with growth, I mean operative product growth teams, so not just like marketing, I don't mean marketing, I mean marketing can also have a roadmap. You can have like, this is the thing, it's the same as with strategy. As you become bigger, you might have a company roadmap, which is a very, very broad defined thing. And then per division, you have another kind of roadmap, you know, like, I dunno, a marketing roadmap, a product roadmap like this kind of stuff. But so who owns it? Again, I think it comes from bottoms up. I think it should be owned by the teams themselves and within the team structures. I'm a huge fan of distributed responsibility. So you have someone who's responsible for putting it together, but it is owned by the team itself. So like you're responsible for doing it, you're responsible for making sure that it happens, but you're not the one that puts their kind of opinion behind it. So I not only not want to have a top-down approach for management to tell others what they should do, but also within the teams, the product manager does not stand above everyone else. It is usually more of a, I don't wanna use the term democracy because it's not really a good term for describing organisations, but it should be carried by the entire team. So if you have a senior team, you can definitely have the team own it.

  - Totally agree with you there. I gave a talk called "Your roadmap Sucks." And one of the dysfunctions I've identified is that it's seen as one person's artefact as opposed to the team's artefact. So absolutely agree.

  - There's another point that is quite important, and I think this goes a little bit into, you know these story point estimations, right? That we do sometimes in product management. Like we get together and then we try to estimate with Fibonacci numbers, how big a story is that kind of stuff. So we tend to do the same with roadmaps. Like we sit together and then we think about how long that something takes and then you, you know, like a month later, you can just bend the entire thing. I think oftentimes the process of doing so is more important than the result because if you have five people in a room and someone says this takes a year to build and the other person says it takes three months to build, we need to kind of figure out where the misalignment is happening. Why is this the case? And you cannot look at decisions and discussions that you have in your company as a binary thing like, "Oh, you know, like this particular discussion is now happening on this thing and now it's contained." Every time you disagree with someone and you find a compromise, you learn something in between. You learn whether someone is too defensive about their estimates, whether someone is too optimistic about their estimates, people start to work better with each other. Sometimes a roadmap is the only kind of process, where people actually sit together, dedicate time and really think about what is going to happen beyond the next three months. And that is quite important because it is difficult as an executive. And I experience this every day to get people to think further than their own tip of the nose. And the tip of the nose is, has a different length depending on the position that you're in for the operative teams, it's usually from sprint to sprint. So you need to pull them up to the three months level usually. And then for for middle management, it's about three months and then you need to pull them up to like, you know, half a year, six months, maybe a year. And then senior management, like depending on how big the company of course is, then you talk about, okay, now I need to make sure that I have everything under control for the next one or two years. And that's how I kind of think about it. So roadmap is a tricky thing in that regard, but I think it's very interesting if you just pull people, if you use it as a tool to make them more strategic than they naturally gravitate to.

  - I mean I was almost anticipating a Pinocchio story there of like the length of how far out the nose is depends on how much they lie and is that something through with seniority?

  - We're very good at lying in C level for sure. That's true. I mean, you know, we've always been telling people that we have everything under control. So like we always pretend that everything is under control, but I tend to be a little bit more honest, I think. We don't know better than anyone else, but sometimes the value in a roadmap is also about the conviction. You can have two directions, both of them are correct, but if you pull in both at the same time, you're not gonna reach none of them. And that's where I'm just, I really believe that disagreeing and committing to something like this is invaluable.

  - Yeah, sometimes leadership's role is just to exude confidence and say this is where we're going because of X and there might be other valid paths, but this is the choice we are making.

  - This thing that you just said is quite important, why are we doing this? So I frankly do not accept any planning or document that comes in front of my eyes where I don't see the reasoning on why someone came to the conclusion. I really don't care whether you're gonna accidentally hit something or whether you have accidentally impact for the company or not. If it was not a good reasoned bet on why you think that and why you're not doing something else, we have to take luck out of this, right? So like this is not, we cannot, like this is maybe a little bit of a controversial view. You cannot use a roadmap or any planning tool as something to reward people if they were right about something. Cannot do that. It is about, you know, in the longer term you will be more right than wrong if you do a good job. Sure. I mean that's kind of like the entire idea. But we tend to only reward people who have good impact. But that is problematic because if you are working in an innovation team, and let's say you have on your roadmap three bets that are very highly innovative, in a typical product team, it is possible that for two quarters you're not gonna deliver anything because it's just very innovative bets or taking very long time to build, very long time to validate. And they're highly, highly finicky. So they have a huge upside, but they're also likely, they more than likely fail than they succeed. And this is sometimes also a little bit of a company culture problem. So we have to be careful about just rewarding success. That's not what it is about. Sure we want to succeed, but a good substantiated business case is also worth something. And that's what essentially goes into a roadmap.

  - And I guess it sometimes that comes down to how we define success maybe. I hate the phrase fail fast as an example because unless if you fail to learn, you failed. And I don't want to do that. If you learn along the way, you didn't fail, you learnt. There was an outcome that was a positive, that means you'll make better choices later on.

  - Yeah, I think, yeah, not more to add. I think if you don't learn about something, I think we always say this though, right? So like we say like, yeah, you have to learn, but then we never really give you some kind of framework on how do you learn. And I think you have to be very intentful about what has failed and what has succeeded. And again, if you have a dedicated structure, where you talk about the outcomes of bigger bets or anything that is beyond, I don't know, two sprints or whatever, regardless of whether it was a success or a failure. And we celebrate the thoroughness of, you know, reporting about it and what we learned from it. And that's more valuable than just meetings where you just like celebrate, "Oh look, look what I did, look what I did. It's so good." You know, like it reminds me a little bit about the little kid that is in the public bath and that just wants the attention of their parents "Look, look, look, look, look, look, I'm jumping into the water. It was so great." And it's just like, "Okay, cool." But like, you know, it also depends on, in are you learning from it? And how are you learning from it? And that can be measured as well.

  - Yeah one of the things that I know I personally like to do when we're thinking about, okay, I was just thinking about how big is the stretch? Let's define, okay, we might, if we're shooting for the moon, let's say that and explicitly say that because then we also are explicitly saying we know it's got a high chance of failure. And if we're going through just a small incremental, we want a team to do something incremental, say that, set a lower object or key results and ask them to take less risk and then understand that if they'd fail, it's a lot worse than if the team over here that was going for the moonshot fails.

  - I'm a big fan of listing company initiatives that are highly risky with a low success chance. I love it. Right? So like you will see slides in my presentations that say, say like, okay, like this is the strategic opportunity that we go for and I think we have a chance of 10% of succeeding it. And then you have the first question that comes from the audience and that's like, "Leah, why are we doing this if we have only a 10% chance of succeeding it?" Well that's a good question because the upside is so big, right? So like, we're gonna make a lot of bets like this. And there is a misunderstanding from people sometimes that they think you should only do things that are more likely to succeed than they are to fail. And it's not true 'cause it's all kind of connected to the upset that you get. And I very simple kind of played that you can make in your mind about this is if you roll a die, and you get $10, when you roll a six and you have to pay $1, if you roll a different number and it's a six-sided die, what are you gonna do? Of course you're gonna roll it forever because you're gonna make more money from the six than you get from paying on the other stuff. And this is how teams sometimes have to think because it's just, we have this tendency of like just comparing like, "Oh look how many times this failed. Oh look how many times this succeeded." Your job is to fail fast in the sense that, are we now on the wrong path? Okay, now we're willing to let an idea go and we're not just gonna go through like iteration 1, 2, 3, 4, 5, 6 until we get, you know, like until it comes out of our ears.

  - One of the things that I often talk about is that people talk about carrying some risk. Yeah, we'll carry some risk here, but the default assumption is we're just gonna deliver, we're gonna carry some risk, we're gonna deliver. Someone's gonna have to work the weekend because something goes wrong, but we'll pull ourselves through and still be successful instead of understanding that risk can mean we might fail or not deliver what we're talking about here.

  - I have very rarely in my career had the privilege of experiencing this binary reality that everybody says that you have like, "Oh this a success and it's a failure." Oftentimes a lot of experiments are kind of like somewhere in between. You just don't know like, or they haven't completely validated and it's like, "Ah, it is just like 3% uplift." Should we release it or should we not release it? It's just not, you know, like maybe in the next iteration we can fix a little bit more and so forth. So the world is not as black and white anyways. But that's why it is very important to define beforehand what you consider to be successful enough before you release something or whether you don't. I'm gonna be honest with you, I rejected most of the experiments that I have designed in my time in the end and we didn't ship them. It's just what it is. It's the life of an innovation product manager.

  - There's an interesting, so an innovation product manager, is that a specific discipline or is it just part of product?

  - No, I think I would just say that I was always quite good in bringing products from zero to one. I don't know why. This is just like how I ended up in earlier, in my earlier career as a product manager. If you bring products from zero to one, you have a very high likelihood or like a very high chance of failing. So just like increasing your chance of survival per experiment from 10 to 15 is already a huge achievement, right? Or like trying to find product market fit. Maybe 15% is a bit extreme, but we tend to say that it is good practise to optimise your product's granularity, right? So like you have a specific version of the product, then you change this little bit up here and this is like how you do a good AB test because then you can actually figure out, okay, the change is happening because of this particular difference 'cause most products in the world do not have enough users to test granular changes in their sub products. Now I add 50 million monthly active users at Smallpdf. So this is a lot of people to play around with. But even there you sometimes have products that are just too small to really measure a significant change somewhere in a subpage that is worth it. So when we talk about innovation that we talk a lot about more qualitative interviewing, so it's less about quantitative validation and then you have to make a really big kind of bet on something that you have to validate without an MVP. I mean the MVP at some point is always happening, but the time that you invest beforehand tends to be much, much bigger than a classical product management role. And this is where I came from, right? So like I was always busy in enterprise and sales and like the bigger projects where you really have to be very, very, very specific and intentful about the innovation that you built because you had very little points of verification on the side until you were launching anything.

  - I think I've spent most of my life in a similar space. So that kind of, that similar end of the spectrum in large B2B sort of activities. So interesting. Now we've talked a lot there around kind of we've had some related items like vision and strategy and objectives and how the roadmap bridges between those and the operational or kind of execution level. Are there other artefacts that link into our roadmap that we might need to think about?

  - So I really like to have correlation trees like some people call them also depth mapping. I'm not very good with terminology, right? It's like I always use what works. So the way that I think about this is if you have a tree of metrics that are influencing each other. So let's take the case of Smallpdf or like any product that you know that deals with documents you have at the very top we have the revenue. So like your value capture metrics on revenue, the amount of trials that we generate, like if you have a freemium product, that kind of stuff. Below that we have metrics that are kind of flowing into this. So the more documents that our customers are processing, the more money we make. That doesn't mean that per document, that's not what I mean. But in general, more engagement from users means we make more money because more people using the product means more people will buy it of course, right? Because they're successful with it. Now if you go further and you think about, okay, so like what influences the amount of documents that are being processed per person, then you can start to say like, "Ah, okay, hmm, this is interesting." So the more people we have that do a specific different action below this also tend to have a correlation to creating more documents. So for instance, if they, I don't know they recommend a product to other people or they use different tools on the website, like there are all kinds of different correlations or like they are in a team or whatever it is. So you have all these sub metrics that start to become really good goals for teams to work on. And usually you can also take a roadmap for a division for instance, like I say, I don't know, like say you have 150 people who have to work on something very specific, instead of just tying this all to revenue simply you can also say like, "Hey, this particular division or this particular part of the company is now responsible for this kind of level of metrics that we have in the company" and they don't need to be actually revenue dependent. So this is definitely something that I use and I like to use, right? So like you have this kind of correlation of like this correlation tree, it's very, very useful for customer facing products in lower B2B and B2C markets. And the other thing is, I call this a fuzzy roadmap where you just have like this triangle that opens up more and more and more, where at the very start, so the very near future. So everything that is happening kind of in the next three to four months, you can only put one item in there, you know, that would be a bigger item, but you have to give it a name and you have to put in there what you think you can actually execute. Then the, I don't know what it's called, I think it's like a funnel, but like an inverted funnel, right? Yeah, exactly. It's a cone yes, there you go. So as it becomes bigger for the next six months, you can put in two walls and for the next nine you can put in three and then four and so forth. It doesn't mean that you're gonna execute on all of them, but it should make it probably more intentful on where you see the product could be going. And I like doing it in this way, but then in the end I delete the dates, right? So because it's not about dates because they're not gonna happen anyways. And I also try to avoid effort estimations, but I do expect as an artefact, a short page for every item on my roadmap from myself and from others on a short description what the hypothesis is and you know, like what we expect to actually reach and what the foundational knowledge is or like what was the trigger that we took this up. And also who had the idea originally, that's also quite important it turns out because nobody knows why, who put this particular idea there in the first place.

  - It's probably useful to go back to them and say we've put it on the roadmap. Can you just remind us again a bit more about it? Why was it useful?

  - Yeah, you know, and it is funny because I think people oftentimes think that they are aligned when they're not and there is not. I've never been in a company where there was too much alignment on anything.

  - And it's such that that current style is I have something I'm working on at the moment that's my 12 styles of roadmap visuals and that's one of them funnily enough.

  - Yeah, there you go. Great minds think alike. There you go.

  - So that's a great segue actually into thinking about the design of roadmaps. So we've got this thing in front of us, you talked about a number of items on there and you kind of talked about taking dates off and maybe putting them on as you were designing it and then taking them off before you shared it. So what are the key things you put onto your roadmap? What are the elements on there?

  - Unfortunately, this depends again on the company itself, but I think in terms of whatever lands there needs to be comparable to each other. So what you need to do is you need to kind of find some kind of form of comparability. We try to do this with other things, as I said, with the numbers, you know, like, oh this is an eight point story or five point story or whatever. Like we do this for effort in stories. With roadmap items or anything that goes beyond the quarterly planning, this is what I mean now with a roadmap, right? So like anything that is longer than three months, because yeah, some companies have six months roadmaps, this is also possible whatever, they need to be comparable in some kind of way. While I'm not a fan of putting big numbers on effort, I am a big fan of putting numbers on it in terms of the impact that it might have for the company in relation to each other. So what do I mean with that? If you have four items that are like, let's say every one of those is a 3 million opportunity for a business that has, I don't know, 30 million in revenue, that means we're gonna make at least 10% on an idea. We say like this is the minimum size of idea that we want, right? Like those can also make sense that we say like we don't accept anything that is below a specific percentage of revenue because we want to be an innovative company for instance. I'm a big fan of that as well. So you say like, I don't want to see any idea on this that is smaller than the specific amount. So it could be usually 10 to 15%. And the more you kind of drill this number up, the more innovative the bets have to become. It's just natural, right? The more likely they will also fail. So let's say you're doing this and then you have these ideas, you need to still put them somewhere in some kind of relation to each other and a number of to the impact like a 10 opportunity is obviously more valuable than an eight opportunity. These are interesting discussions, but you need to see them next to each other. So we can make a decision on saying like, okay, we think right now based on the knowledge that we have right now, that this is a bigger opportunity than this one. The danger that you have if you start to evaluate the effort, because that's what people usually also do. They think about like how difficult is something to build is that, let's say you have two items on your list and both of them are a 10, and you might think, why don't we just think about which one is harder to build? It turns out that we are very good in estimating things that we did a million times before and that were incredibly bad in estimating anything that we've never done before. So we constantly underestimate what is in the future, what is a hypothetical versus what we already did. And that the result of this in a roadmap is that items that are complicated and known are more realistically estimated. They're still wrong, don't get me wrong, but like, you know, they're usually, they'll usually have less effort attached to them than complex ideas that we've never done before because we underestimate their complexity. And I think this is an important point to drive home. As you become experienced in planning, you just know that even if you do not see difficulties, that they will be coming up and you have to kind of attribute time for them. And you have to sometimes also search for them because it is weird if somebody asks you like, why does this take a year? And then you say like, well I don't know, it just feels like it's really long. So you have to kind of find your experience and then kind of work around this a little bit. But that's what I would say, like the comparability rather than anything is extremely important. And I like to do this in a very simple short form, which could be a notion document, you know, just like items next to each other. Not Jira. Definitely not Jira. No, I like Atlassian, they're a cool company, but Jira not in my house. No, not for the roadmap.

  - I'm now thinking maybe of, yeah, what about best practise on road mapping? If you had to think about one or two things that you consider to be, you know, the absolute best practise. I know some of it's probably already come up in the conversation, but if you had to state them, what they'd be?

  - Depending on the size of the company, make sure that everybody who is affected by your roadmap. And that does not mean that you are the one that, those are not just the ones that are executing on it, but everybody who's affected. So like if you have a product roadmap and you have not looked at this in detail with sales or marketing before you try to submit it in any sort of way, then you failed. That's just what it is. I'm even a big fan of bringing sales also to the table, right? So like if you have, I don't know, like if you define your quotas, I mean it's not about that other people are starting to talk into your compensation plans or anything, but a roadmap is not just for you, right? So like as much as it is not for the external customers, it is really for internal alignment. And it is important that other people also can talk about your roadmap before you actually commit to it. And for that you need to have some kind of cross-functional roadmap setting in some ways or like ideas and directions that we go to. And that's the very first thing. The second thing is keep it simple, keep it simple, stupid. That's really what it is. The last roadmap document that I did that was bigger than, I don't know, 10 pages, let's put it that way, right? So like excluding excel sheets and financial plannings and so forth, it was over 10 to 15 years ago. There's just no point if it's too long because nobody's going to read it. If you cannot talk about it, if you cannot link it to artefacts that are already existing, for instance, if you have a business opportunity that you are trying to map out and so forth, then it starts to become useless. So keeping it simple is a constant repeating effort that you just need to do. I am not a big fan of complicated frameworks. I just don't think that they deliver ever any value. If you have to explain to someone first for 10 minutes how you meant something, then it's anyways useless, right? So, and that's, and I think keep it simple. Be aware that plans will change and make sure that the bigger your throw is, that the less substantiation you can put behind it, but the more realistic you have to be about the certainty of it, even if you do not see the difficulties. So yeah, I'm just not a big framework person in that sense, right? So like I think that's what I would say yeah.

  - And you never, you didn't actually say this, but if I summarise what you said something earlier that ties in nicely what you said, it's like, it's the active road mapping, not the roadmap itself that's important. So that keeping it simple as a essentially a memorialization of that act is, is a good thing and an important thing.

  - Absolutely so there's a funny story that that happened at Smallpdf at some point. So we had our annual roadmapping, not my favourite time in the year, for sure not. And I think I said at that point in the meeting that, Oh, shit I hate roadmaps, right?" And my microphone was open and everybody heard it. And then at some point my CPO had to kind of clean it up because everybody said that "Leah said, we're not doing roadmaps." So, you know, these kind of things, they take their, they take a life on their own. I just don't think that things are as organised as you think that they should be. Even in, I mean this is why we have corporate processes and governance and all this kinds of stuff because people tend to be less organised than they claim that they are. And that's why you just have these huge processes that I definitely don't play well with. So yeah, I guess.

  - I mean that would tally nicely with the innovation end of the spectrum, right? If we think about in terms of three horizons, if you're in the third horizon on the innovation, the two true new business area, you need a lower process horizon because the current organisational processes are like corporate antibodies against those things.

  - Yeah, that's very true. And that's also why I position myself as well. Like I love doing strategy, right? Like I love doing, figuring out where the market is going. Also with my clients, I really love doing that. But the road mapping that is, that is an operational effort and they have to do themselves of course. So that's a boon that I enjoy. So I'm getting paid for the cool stuff about work.

  - And so if you were to think about a roadmap, is there a pet hit you have, something you really just never want to see on a roadmap?

  - Two detailed effort estimations, as I said already, I think that's always a bad sign because you can pluck them apart at all times. Like any project that goes longer than four months and you are too detailed in your effort estimation, like, you know, like, "Ah, this is going to take two weeks and then this is going to take two weeks." I think it's a waste of time. That's definitely something. And then the other thing is any roadmap that focuses too much on today and too much on competition. So that's more like of a strategic topic in the sense that what you usually see on roadmaps is delivery defined goals where they just start to deliver on features. You can still have an outcome defined roadmap where you just say like, "Okay, we're gonna increase retention of our core customers with this and this initiative." Sure but the goal itself is not to deliver a specific feature. It's very rarely the case. But like if I say, okay, in the next two years we're going to enable collaboration in our product, that is an outcome driven statement that I can still solve in different kind of ways. Because we know that collaborative features, for instance, are driving LTV and so forth, right? So like then you have a business hypothesis behind and so forth. So I would say output too much output, too much output driven, not enough outcome and too detailed on effort estimation. It's just not, it's just not feasible. I just don't think so.

  - Yeah I mean I tend to think almost in really short term, maybe that next quarter we might be more outcome focused because we have some certainty. We're getting into the, that next time horizon should we say, well, maybe we're getting to user outcomes. So it's what problems we're gonna solve for them. And then in the even longer time horizon, maybe it's product outcomes or business outcomes that we might be looking to move that we haven't discovered the user outcomes to drive yet 'cause I think we can have a bit more certainty then.

  - Yeah, certainty would definitely be nice.

  - Okay, so we've been listening to some of your advice here, Leah. Whose advice do you listen to on road mapping?

  - There's not that many people, to be honest, that I listen to when it comes to roadmaps. I mean, I'm not consuming like podcasts on roadmaps, but I would say the closest, the closest I would say is anything that has to deal with strategy because a roadmap is in the end an artefact to kind of enable strategy in that sense. I think Adam Fishman has some really funny takes about annual planning. He's incredibly funny about this. I've been talking with him quite a few times on my podcast. He has a great newsletter, fishmanaf.com, I think. And yeah, it's just very funny to read his stuff on this because it's also quite actionable, right? So like anything that we do not see really deliver a very operational impact is just, it's just for an alibi. That's how it feels. Yeah.

  - If you had to distil your philosophy on road mapping down to one or two sentences, what would it be?

  - The direction you go is only as good as the font that you use on the road sign that guides you. And I would say this is very true for roadmaps in the sense that you might think that everybody understands your roadmap. Maybe everybody comprehends the words, but if people do not understand the same thing, then they go into this into different directions. I would say that's a good summary.

  - Is there anything about roadmaps that I should have asked you that I didn't?

  - I don't think so. This was the most thorough interview I've ever had on roadmaps by itself, for sure. Yeah, maybe you should have asked so like, how long should a roadmap be and maximum, and I would say a year is already pushing it. But again, it depends on the company because everybody's talking about their own experience. But I would say like a year is already pushing it for most companies. I would say 99%.

  - I think I'd agree with you in a software context, in a hardware physical product context, it often pushes out. But that's because they have hard timelines, so absolutely.

  - Yeah, yeah. No, for sure. So I mean, anything that has to deal with hardware, I mean, yeah. So just for the listeners, I'm a tech and software filthy PM, yeah.

  - At the end of the session, we always like to give you an opportunity to pitch yourself your offering, how people can get in touch and how you can help 'em.

  - I help companies to get their distribution right. How do you think about reaching your customers more efficiently? I teach about product like growth in B2B dominantly, which means that if you have a running growth motion and you want to make it more efficient, which usually means you have more than 10, 15 million of ARR and less than a hundred, because afterwards it gets a bit too big, maybe, then I'm your girl. I really like talking about this stuff. As you can hear, I am, I'm very passionate about helping companies on this way and I also do executive coaching and a new service that should be live by when this episode airs, which is growth as a service, which means I'm gonna bring an entire team into a company and they coach others on how to do growth, right? So that is a new thing that I'm gonna try out. And yeah, other than that, I have my blog, which is www.leahtharin.com. I'm sure you're gonna put it into the show notes. I have courses, my podcast, there's just so much stuff. I don't wanna bore people, but if you don't have enough, there just sure is more to consume.

  - As always, at the end, please do like, subscribe, hit that bell icon, remember to listen in and share it with some of your friends. Leah, it's been an absolute pleasure having you on the call today.

  - Thank you for having me.