Lean Roadmapping to Power your SaaS Product with ProdPad's CEO and Co-Founder, Janna Bastow

to join the conversation, you can either just unmute yourself and jump right in. You can use the chat function or also use the raise hand function. We'll keep an eye on that in the participant list. So you can find that raise hand function by just going to the participant list and clicking next to your name. I just want to let you all know that these sessions are being recorded. If you do have to jump off for any reason, or if you'd like to share with someone else on your team, and then also hope that you'll be able to take advantage of the one-on-one networking opportunities through Brella that we're offering with the event today and tomorrow. I'm going to drop a link into the chat just so you can take advantage of that if you haven't set your profile up yet. So without further ado, Janna, I'll pass it over to you.

Take it away. Wonderful. Well, thanks for the, the great intro and really good to be here. So let me kick off. I'll start with an intro. So my name is Janna and I'm one of the co-founders of Mind the Product. It's a community of product people from all around the world. And I'm also one of the co-founders of ProdPad, which is a software for product managers. And, you know, before this, I was a product person myself. This is how I ended up getting into all of this. I wanted to meet product people who did what I did, and that's what I found when I did Mind the Product. And I wanted tools to help me do my own job, and that's what I found when I created ProdPad itself. So I'm a product person at heart, and along the way, I've done a whole ton of mentoring, consulting, training, and just generally talking to the product community and talking to product people about how they manage their roadmaps, how they manage their product teams, their product ops, and everything else in between. So I'm happy to share with you today some thoughts that I have on roadmapping. And, you know, I'm going to start with a rant about what's wrong with roadmapping. Because one of the biggest problems that I think that's still plaguing tech companies today is their terrible roadmaps. You know, and if you want to see how prevalent it is today, just do an image search right now for Google— like, on Google for product roadmap. And you'll see something like this. And you'll mostly see just like a bunch of timelines, like essentially like a bunch of Gantt charts, a bunch of timelines, a bunch of pretty looking things that sort of make a promise of a bunch of features and deadlines and stuff like that, but nothing of particular substance, nothing that's going to actually help the companies. So what's actually going on here? Why are these roadmaps setting teams up to fail? Well, this is actually how a lot of roadmaps look today. And I know this format makes you look great today, but the format is essentially setting you up for failure. You know, your board and your bosses love when you can give them this level of certainty, but here's what's actually happening underneath. See, if you deconstruct this format of the roadmap, you basically get a chart that maps out time versus things to do. And you get this time on the x-axis, and it creates this timeline. And at first, it seems pretty easy and intuitive to use, particularly in the short term. But the further out you plan and the more you put on there, the harder it becomes to manage. And because that timeline sits at the top, always marching forward, no matter what you put on that roadmap, everything includes a due date and a time estimate, just by the format of this roadmap. And so you end up with a big pile of features and a big pile of deadlines, and it's all based on this big pile of assumptions. And so the first assumption that you've made with this format roadmap is that you know how long each of these things is going to take. And that might be easy for the stuff that you've broken down in detail and had the developers give some estimates on, but the further down the list you go, the less clarity you've actually got. And you're also assuming that nothing else is going to come in to mess up your timeline on that roadmap. No new changes in the market, no new competitors, no fresh ideas coming from customers, no need for iteration. And you're also assuming that each of these— each of these features are going to work as soon as they launch. So assuming you put 3 weeks to build that new checkout page, well, then at the end of those 3 weeks, it should be converting exactly as well as expected, and then you're free to move on to the next thing, right? Unfortunately, it never works that way. And by explicitly adding these features to the timeline, you're also assuming that each of these features actually deserve to exist, that they form part of the strategy and therefore deserve to be codified. And at the end of the day, you're making one big dangerous assumption, and that's that nothing is going to change. And so what could go wrong? Well, you end up with these made-up release dates that end up forcing your developers on stressful marches to launch on time. Your sales and marketing teams and your customers get expectations that you just can't meet, and you end up missing opportunities in the market and often downright building the wrong things. And this leads to you being a sad product manager or having a sad product team. And there's actually a vicious cycle that it leads to as well that can be really hard to get out of. Because in the team, no one wants to be the one caught holding the hot potato. No one wants to be the one giving the miss, like missing the deadline. And so what basically happens is that people give bigger and bigger buffers. So they say that something's going to take longer than it's actually going to, than they estimate it's going to take. And what then happens is that time expands to fill the work given. And this is actually called Parkinson's Law. Where things actually end up taking longer because you've given longer estimates for it. It's the reason why you always seem to be running up against deadlines, no matter how far out they've actually started. Scope always creeps, and procrastination always happens. It's just a fact of life. And so these longer estimates create longer and riskier-looking timelines, and execs become even less comfortable giving any freedom to build in any sort of lean way. And so they try to tie down even tighter deadlines, so they feel like they have a control on costs. And so there's never any room for discovery in there. There's no room for rework or any quality work to be done. And so the wrong things are constantly built, problems are never solved, and quality just ends up suffering. And it leads to blame culture, where no one feels safe being the one to take that misstep at work, meaning people resort to just giving bigger buffers and bigger estimates for the work in hopes that they're not the one to get it wrong again. So is there a better way? Well, yeah, of course there is. That's why I'm here. I want to talk to you about lean roadmapping. This is where it comes into play. Now, lean is— I mean, we're all familiar with this. It's all about that build, measure, learn cycle. And it's really simple, right? The key thing about lean is the learn part, right? This is essential to the benefits of Lean. Lean is really about learning quickly with as little cost as possible in order to reduce wastage and eliminate unnecessary risk. This is why we practice Lean. So where the roadmap comes in, I see it as a tool that can actually help you learn and iterate at the product strategy level. And so to put that more succinctly, I see the roadmap as a prototype for your strategy. Now, let's put this in terms that we're really familiar with. When you go to build a new feature, you don't run straight in with a fully designed interface that you pulled out of your head and gave directly to the engineering team. You start off with a piece of paper, something that you put on the whiteboard, something that you scrap down on a sketch or a Marvel or often just something you've put into a notebook. You start off with something really basic and you show that to a colleague or a customer and they give you feedback. Maybe they tell you to move that button here, add some copy there, or change something. And that first sketch gets thrown out and you make a slightly better one, taking on board the feedback that you learn from. And you repeat that process until you're reasonably sure that you understand how that feature is going to solve the problems at hand. And what you're actually doing is you're de-risking that feature. You're making sure that that feature is likely to solve the problems at hand. Well, the same thing can be done with your roadmap, where what you're actually doing is laying out the assumptions that you're making about the problems that are— the problems and the opportunities that are in front of you, and checking them with other people in order to solidify your vision of the future, right? Solidify the strategy. You start off with this flimsy strategy, and you check it with other people, and you throw out the process, you throw out the sketches. And so in reality, the roadmap itself is not what's valuable. It's the roadmapping process that's valuable. And so in a way, your roadmap itself is there to prevent wastage and de-risk your business. And so what you're actually doing is you're working your roadmap in a really lean way, and you're checking your assumptions about future problems way in advance, just like you're doing when you're prototyping an interface. You're learning really early on. Like, if you and a colleague run into a conversation where you disagree on what order to tackle a series of problems, or whether a problem even exists or not on a roadmap, it's really good you had the conversation now, rather than committing a whole bunch of brain space to it, or worse, committing code to it down the line, just because it was on the roadmap and no one dared to question it. You wouldn't believe how much time is wasted just because somebody said, well, this is the roadmap. And we just decided to do the roadmap because it said it was on the roadmap. So you're preventing this wastage, and you're de-risking your business by checking this stuff way up front. Now, it's important to remember that product is this big unknown. You're building into uncharted territory. There's no blueprint to follow. There's no right way to do this. No one has ever built your product before. People have built similar products that you can learn from, but no one has built your product. This is not like building a prefab house or an IKEA desk, right? You're not taking a bunch of pieces and just assembling them. This is more like landing on a new unknown shore and trying to figure out how you're going to make it to that gold-topped mountain in the distance and trying to figure out what the best path is along the way. And you might have certain resources with you now, and you've got to pick up resources and knowledge along the way, and it's up to you and your team to survey your surroundings and decide what you have and what problems you need to solve as you go. So every product is a unique journey. There is no one particular path. And so it's a fallacy to think about it in terms of being able to plan in the same amount of granularity in the far distance as to what you can plan now, which is where these time horizons come in. This concept of being able to say, well, here's where we are now. We're standing here at the present time. This is what I can see. I can see that there's a bear, a big problem in front of me. That's the big problem to solve right now. But I can see that there's a hill in the distance. We're going to have to learn to climb eventually. Maybe we'll have to learn how to pick up some kit to do so. But that's a further-off problem. So you can figure out— map out the different problems and how you're going to get there. But you've got different levels of granularity in how you map those out. And so these translate to a product roadmap. So instead of that timeline, which is a single date-driven line that marches forward, think in terms of these 3 buckets. So you've got things in the now, which have a really granular area of focus, very specific fo— scope. This is the stuff that's being prototyped and tested and built right now. And the later column is much less about specific initiatives, but more about outlining problems that, you know, think— that you think need to be solved in order to fulfill your vision, that you want to keep in mind, that you want people to aim towards to keep them on track. And this is really key. You want to make sure that people understand what that vision is. What is your gold-topped hill in the mountain, in the distance that they need to aim for? If you don't have a clear product or company vision, this is one of the first things that you want to sort. This is actually a vision template that you can use. You might recognize this from Geoffrey Moore's Crossing the Chasm book. It was originally used as a, elevator pitch template, but it asks the right sort of questions like, what problem does it solve, and who does it solve it for, and how do you differentiate? So this is a good starting point. And also, there's no point in setting off on a journey if you don't actually have a good understanding as to what's going to make you successful along the way, what your core objectives are. And this is where OKRs come in. OKRs are really key to lean road mapping. What's really key about them is that you set— is that the company sets top-level objectives, often called a North Star metric, and the team then works together to decide how they help contribute to that goal. And this is vastly different than the old-school way of doing management, where, you know, you think of management setting goals for the team and micromanaging the process. So what it means is that the knowledge of the whole team is used to set goals, which means that gaps are more naturally spotted and filled. It also means that the team can work more autonomously and isn't held up by limitations in knowledge or bottlenecks by that middle or top management. An example of this might be the company goal being set to something like maximizing revenue from a market segment, but each team is then able to step in and say something like, marketing, well, we'll attract the right sorts of customers. And design saying, well, we'll create a delightful onboarding experience that's going to convert and retain. Development saying, well, we can help this goal as well. We'll build a solid platform and deliver in a way that we can iterate often. So no one person is responsible for that North Star, but together, the whole team is working together to make sure that it happens and is able to spot the gaps in between. So they all know where it is that they're heading and is able to figure out how they're going to contribute and who's covering what and what holes might exist and what overlaps might exist as well. So if you take these three concepts, having a vision, understanding where they're meant to go, having objectives, what's going to make them successful along the way, and having the concept of time horizons, so where we are now and what sort of things are close to us versus further out, we can start putting that together into a lean roadmap, which might look something like this. And so each of these blocks here, each of these cards, is a problem to be solved. And each one is linked to a specific objective. And this is one popular way of outlining it, this now, next, later format of it. And what can actually be done with this is it can be used to communicate what the problems are to be solved, but it can also be used to show in a more granular sense as to what experiments are progress as well. So each card is tied to the problem to be solved. But then each card is then connected to the list of experiments as well that can be run in order to solve that problem and impact that objective. So the roadmap gives you this overview of progress on ongoing experiments, particularly in that Now column. Other key thing is that once a project is done in development, don't just throw out these results or tuck them away where you'll never find them. 'cause this is a habit that I see a lot of teams doing, is that they trash the roadmap, right? They release something, so they close all the tickets in Jira, they crumple up all the sticky notes on the wall, they wipe down the whiteboard, and they move on to the next thing, which seems good for keeping up an agile cadence, but it's bad for making sure that they actually make an impact. You know, just because something is launched does not mean it actually solves the problem you wanted it to. So it's really key to build in space for validation. The thing is, people in the team understand this. They often understand that they should be doing this, but there's not really time and space built into their process. So the roadmap can actually help here if you have something like this, what we call a validation roadmap or a completed roadmap. It's this historical backward-looking view of what you've actually done that sort of creates a space to say, "Well, here's what we did. Have we actually solved these problems?" So we thought that we were trying to solve for problem X in order to hit objective Y. Did it solve the problem? Did it move the metric we were hoping it did? And have this running list of what you did and didn't do along the way. Show your successes and your failures. And so by building this validation into your roadmap, you create a space to show the value of the work done. And so in general, what you're actually doing here is You're taking— like, the value of this format, what it does is that it takes the focus off building features and hitting delivery dates and helps the team work towards solving problems, which is really, really key. And the thing is that it also takes into account the fact that there are lots of paths forwards. Again, it's uncharted territory. There's lots of different ways of creating the best possible version of your product. And it takes advantage of the creative knowledge in your team. Makes use of that creative knowledge in your team. You've hired smart people. You don't want to lose that, that knowledge. And so what this actually leads your team to solve problems in better and more effective ways than they ever could with the alternative, if they, if they didn't have this concept of lean road mapping and more autonomous ways of working. So with that, I want to start opening it up to questions and see if there's anything that I can help answer around lean roadmapping and how it de-risks your business, prevents wastage, and otherwise makes for happier product teams.

Would you mind sort of summarizing it all in a few sentences once more?

Sure, absolutely. Lean roadmapping is a healthier choice for your company because it means that you're no longer tied to delivering on deadlines. You are focused on solving problems. You are ditching the concept of timelines on your roadmap and term— and focusing on objectives, so your team can work autonomously and be aligned towards the goals that they're aiming towards. And it gets your team out of the vicious cycle of constantly moving slower and slower and slower, and allows your team to move more lean, which de-risks your business and prevents more wastage. Does that about summarize it for everybody who was here for the whole thing? All right, cool, I got a clap. Thank you.

Yeah, thank you, very, very well done.

Thanks, thanks.

If anyone has questions for Janet, please feel free to jump in the chat, take yourself off mute, or you can raise your hand if you'd like. We have her for a few more minutes and would love to take advantage of that time and ask any questions that you may have.

And of course, if people do have questions, ask now, and also feel free to reach out to me on LinkedIn, connect with me there, follow me on Twitter, email me. Always happy to chat and dive into things in more detail. Anybody here a product person or leading a product team? What are our roles here? Hi, Jason. Hey. Hey.

Thank you for this. I think this makes a ton of sense, particularly from a product standpoint. In the— as I'm sure you've encountered in the enterprise space, there's often a lot of desire, I guess, from the revenue teams, the customer support teams, to a few things. One is to commit to specific features, feature requests from customers. But I think beyond that, to have visibility into what's coming next, you know, what's coming out this quarter, what's coming out next quarter, what can we expect in the next 12 months? So how do you, how do you blend that with this, this idea of going further back?

Yeah, so that's actually one of my favorite questions because whenever a business is asking for dates on things, I always want to ask why. Because there's a few different reasons why they might be asking for that and a few different things that you might want to push back on that. So for anybody who's interested, I've actually written an article that takes— I thought of all the different objections that a product manager might run up against from different stakeholders, whether it's your investors, your boss, your customers, yourself, whoever, and wrote down all the different reasons. But some of the key ones— sales and marketing. For example. So if sales are asking for dates, there's a couple things that might be at play there. One, it might be that you actually work for an agency. Your business model itself is actually set up where your company is not able to sell the, the product that you're actually selling, and in fact is operating as an agency, at which point, unfortunately, you're actually more of a project manager than a product manager. It can be saved, but it's really difficult. The company needed to be aware of the fact that they're doing this because it is a dangerous situation, particularly if they're selling at product rates and hoping that one day they're gonna scale like this, but they're currently at the flat bit and not like this bit. But selling their time or using their time up like agency rates, right? As in always doing that one piece of custom work, right? That one extra feature or whatever else. Every time you sell your time to do that one piece of custom work, it means that you're not able to do— spend that time in discovery mode, right? You're either in delivery mode or discovery mode. And that time that you're spending in delivery mode is time that you can get a little bit of money for, but you're not actually creating residual value. So if you've got a company like that, it's sometimes worth holding up the mirror and saying, you know, is this actually a valuable company? Are we actually building the right thing? And are we working in the right way? Other times, it might just be a simple fact of, actually, let's just make sure that the salespeople know that the rule is sell what we have. We have a good product. The product is fine. Sell what we have. We don't need to be selling, you know, our product plus one feature. So sell what we have today and redeploy the salespeople to help you validate what's on the roadmap, but never sell what's on the roadmap. Because that sets you in a trap, right? Because at that point in time, you can no longer spend time in discovery. You can no longer discover the bigger, juicier problems that you could solve, because you're constantly trying to chase down that extra buck that could be made. And it's always a cheap buck, right? It's never a good buck that's being made in those cases. Things that can be done: separate hard launch from soft launch in those cases. So what I mean by that is, People want to know— one of the reasons why sales and marketing want to know when something's going to come out is so they can plan their marketing activities and their sales activities and all that kind of stuff. They don't like surprises. Well, that's fine, right? Tell them when something hits soft launch point. When something is behind a feature flag, they can then take whether they want 6 days or 6 weeks or 6 months to plan the biggest, bangest launch they could ever imagine, they can then take that feature and plan out whatever they want. But the worst thing you want to do is try to stack the marketing planning on top of the really, really fuzzy, impossible-to-plan development planning and try to line them up to land at the same time, because that's where big, big bang launches go wrong. Because all of a sudden the development plan slips and your bus ads go out a week before your campaign goes out, right? Your product goes out. Or they're working from images or screenshots or mockups of the product that actually no longer look like what was actually delivered because you iterated in design or in development itself. Other cases, you know, sometimes you just have bosses or teams who say, "We want to see, we want you to tell us what's going to happen quarter by quarter by quarter or week by week by week because we think it's going to make you work faster. That's how we feel like we can get some control over what's happening." And that's a sign that the company is lacking psychological safety and lacking autonomy and isn't a great environment. And what you need to point out is that it's actually a really bad investment of their team, right? What they actually want isn't a laundry list of features. They want to know, for the most part, that the investment that they're putting into their company is going to turn out good results. and so you can use OKRs to help structure it in a way where you say, look, you are paying for a team for the year. That team costs $1 million, so that's $250,000 per quarter. And what we're going to do is not tell you we're going to build feature X, Y, and Z this quarter. We're going to focus on this problem, and we can't guarantee you how well we're going to fix this problem, but we can guarantee you that we're going to run 15 experiments this quarter to try to solve this problem. And last quarter, you can see that we ran 15 experiments and that number got better. This quarter, we're going to focus it on this number, and you agree that this is the most important number to you because you help set the top-level objectives. So the business helps set the direction and make sure that everyone's focused on the right thing, but is no longer telling you, go build feature X by date Y, which is actually wasting people's time. It means that they're actually getting less out of the team than if they otherwise let the team just work at their own pace. So if you start holding a mirror up to the execs or to the investors or whoever is saying, you know, work at this pace in order to tell us what's going to happen by what date, you start saying, well, actually, you're wasting everyone's time and money. You're wasting your own money. You often start getting a little bit more leeway by working that way. So it depends on who's asking for it, but there's often a good case that can be made that, that can help with that. Dane's just asked a good question, is there a YouTube talk on this whole approach? Yes, I do have some longer talks on this, and I think I've got some other articles and things like that, so I can absolutely share those around, email me. Drop me an email at janna@prodpad.com, and I'll send over what I can. I think I've got various cuts of talks that, that cover this, Dane, and anybody else who's interested. But generally, yeah, I end up talking to people and coaching them through how to get the team off timelines, and I've come up against every, every objective— every objection possible. So yes, bring me, bring me your objections and I can help talk people off the cliff with that one.

Any other questions for Jana before we let her go?

Maybe a short story of like a client that switched to this and what it was like for them and what happened?

Yeah, absolutely. I mean, I've seen a lot of people move from one form to the other. A lot of times, it's actually easier to ask for forgiveness than permission. I've seen a lot of people just change the roadmap out from, you know, that sort of timeline version to this lean version and show it to their execs and just go, oh, well, actually, it solves the problem because it's communicating the right sort of thing. And it solves the problem for them, right? It's telling them, here's how we're spending our resources. And the thing is, I think the only reason why product managers are stuck with this whole timeline roadmap thing is because it grew out of— we did release plans, which looked like little tiny waterfall things, and we stretched them longer and longer and longer. We gave this expectation that if something was, you know, 2 weeks long, we could tell them the next 2 weeks and the next 2 weeks and the next 2 weeks and the next 2 weeks. And before you knew it, it became year-long and multi-year-long roadmaps that just