Have you ever thought about how your product roadmap can become your secret money-making tool? Janna Bastow, a savvy product pro and the brain behind the Now-Next-Later framework, is ready to shake up your ideas on what a roadmap really is and what it can do for your bottom line.
This webinar was not your usual tech jargon-filled snooze-fest. Janna's here to bust the myth that roadmaps are just a to-do list of features and code. She introduced the Now-Next-Later framework - a straight-up, no-nonsense strategy that can turn your product roadmap into a profit powerhouse.
Janna shared how this handy tool helps you not just pick the next cool feature but plot the course of your product that brings in the cash. You'll learn how this strategy can affect your revenues, keep your budgets in check, and turn your business into a lean, mean, profit-making machine.
Watch for this fun and eye-opening ride, where you'll learn to turn your roadmap into your golden ticket to profitability. Say goodbye to the old and hello to a roadmap that actually makes you money!
About Janna Bastow
Janna Bastow is a product manager and the inventor of the Now-Next-Later roadmap, and currently CEO and co-founder of ProdPad, product management software that helps you manage your roadmap and your product backlog. Janna continues to work with companies as a trainer and mentor to help them figure out how to build and learn, without breaking the bank. She likes to inspire great product conversations by asking: “What problem are you trying to solve?”
Janna also co-founded Mind the Product, an international product management community and series of events for fellow product people. It was started in 2010 with the very first ProductTank meetup in London and followed by the Mind the Product conference in 2012, and it now has grown to consist of more than 300,000 members and sold-out events in hundreds of cities around the world.
Transcript
*Transcribed using ai. Please excuse any spelling and grammar errors
Jason Tanner 00:00
All right. Well this was a question about recording
Janna Bastow 00:09
all right. Hey everybody. See ya. Test the chat
Jason Tanner 00:16
Yes. Welcome everybody already see people joining this is awesome. Okay. Welcome to everybody who's joined us this great working and Welcome to sunny Cary, North Carolina. Is this unusual? It's like you've got a heatwave going on in the UK and it should be really hot here and it's mild. It's sun. Nice rhinos beautiful weather. Yeah. Like Andes during the day, it sounds a lot like 65 and nine. Yeah, unfortunately, I mean, summer's over around here, which not thrilling
Janna Bastow 01:08
pro tip for anybody using the chat, there's a drop down in zoom, where you can change it from hosts and panelists to everyone. You want everyone to be able to see your messages. Otherwise, it's going to be just me and Jason seeing your messages, which is fine. But kind of limit the conversation there. We are someone from Austin, Texas. Hey, David
Jason Tanner 01:37
Let's see. Well, welcome to webinar, let's get this party going another Texas
Janna Bastow 01:45
versus massive turn. Cool.
Jason Tanner 01:50
everyone for joining the typical preamble is that we're so glad you're here. Of course, continue to chat, use the q&a panel if you want to post questions. And of course we're recording. And we'll be sharing the recording as well as how to get the slides agenda is going to share. After the webinar, we're just talking a moment ago about a template for an Amuro verse. Since we are doing this webinar series in collaboration with Miro, our partners in this so we're collaborating on a template that you can use for roadmapping available after webinars. So let's kick it off. So I've got the stock bio, the agenda share. But I I gotta say that I read more about what Jana wrote about product management before I ever met her. Because she has shared so much with the community as a product management thinker. And Jan invented the now next later roadmap framework, and is the co founder and CEO of prodpad. So actively running a software company, and I'm Majan being the product leader with her team there, which is really very helpful product roadmapping software for product people. Jana also is the co founder of product tank in mind the product, which is global community of product managers, so very well connected and networked into the entire community. And this is one I love. She often starts and stops conversations with the question, what problem are you trying to solve? So put that in your bio? Why is that in your bio? Jana?
Janna Bastow 03:33
It's one of my favorite questions, because it's it helps prompt the conversation into the next stage, right? I mean, if a conversation is going off in the wrong direction, you're sitting here going, what problem are you trying to solve? It can bring it back to the room and everyone goes, Oh, it's not solving a problem. Or actually, here's the problem we are solving. Let's work on that. It can prompt somebody to think more about what it is they're trying to do. But it can also stop something in its tracks if it's actually not the right thing to work on. So it can stop and start or continue a good conversation just by asking one question, what problem are you trying to solve?
Jason Tanner 04:08
Yeah, awesome. Great. So let's get going.
Janna Bastow 04:14
Yeah, so I'm, I'm really excited to chat with you all today. Excellent. Should I kick off and share my screen and talk to you about what I was going to talk to you about?
Jason Tanner 04:25
Yes, please. And again, everyone ask questions as Jana goes along and shares her thoughts.
Janna Bastow 04:31
All right, excellent. Well, I'm going to be talking about roadmaps to riches. So you probably know me as the person who talks. Maybe the most about road mapping. road mapping is a very contentious subject. It's one of the reasons why I love talking about it so much. But I want to talk about how you can unlock treasure troves. You know how you can pump up your bottom line by really thinking about your roadmapping itself and how you can think about your product strategy. So Jason, already did a great introduction. But just to clump that out, I'm a product person at heart. As you might imagine, you might know me as one of the founders of mind the product, which is the big global community and the series of events and training for product people, you might know me as one of the founders of prodpad, which is the product management platform. And that includes roadmapping, and idea management and customer feedback management. Built it when I was a product manager myself, because I needed tools to do my own job. And along the way, I've done a ton of mentoring and training and consulting in the product space as well. I've got the slides ready for you here. So don't worry about taking screen grabs and all that sort of stuff, feel free to just grab that URL or grab that QR code. And you'll have a copy of the slides for yourself. But please see it feel free to use the chat or the q&a, ask any questions. And please do connect with me. I'm best found on LinkedIn, you can email me jana@prodpad.com. I'm still vaguely on Twitter, I think maybe for a little while longer, but we'll see where that goes. But I'm easy to find. I'm the only Janet Bastow out there. So I look forward to chatting with you about product roadmapping profit, profit making whatever else you got in your mind. So got a bit of a theme here. There's roadmaps to riches, these Treasure Trove is we've got a treasure map here, I like to think about your product roadmap as a treasure map, where the X marks the spot where profitability lies. But just as any seasoned adventurer knows, it's not just about the destination, it's about the journey. Just as a simple line drawn on a piece of parchment won't guide a pirate to the treasure, a mere timeline of features will chart your course to peak revenue. It's about understanding the intricate terrains, the lurking challenges the golden opportunities of the market, much like an explorer, facing swamps and deserts and mountains. Our teams grapple with obstacles like tech debt and misaligned incentives and feature bloat. So let's dissect the traditional roadmap to start and see if it truly leads to the treasure, ensuring our products not only shine, but bring in the gold. Because you know, this is the traditional roadmap. This is how a lot of roadmap look today. And I know that this format makes you look great. Your board and your bosses love when you can give them this level of certainty. But it's setting you up for failure. Let's break this down as to what's going on in here. The if you deconstruct this format of the roadmap, you basically get a chart that maps out time versus things to do, you have time on the x axis creating this timeline. And at first, it seems pretty easy and intuitive to use, especially in the short term. But the further out you plan in, the more you put on there, the harder it becomes to manage. And because that timeline always sits at the top, always marching forward, no matter what you put on the roadmap, everything on there always includes a due date and a time estimate just by having this format of the roadmap. And what you end up with is a whole bunch of features a whole pile of due dates, and it's all based on a whole pile of assumptions. And the first assumption that you're making here is that you assume you know how long each of these things is going to take. You're standing at the front here, and you're saying this is going to take a week, this is going to take five days is it gonna take three weeks, two months, whatever. Now this might be stuff, this might be easy for the stuff that you have worked with developers on you've broken down into more detail, you've had the developers give you some estimates. But the further down that list you go, the less clarity you've got, the more we all know, we're making it up, right. And you're also assuming that nothing else is going to come in and mess up that timeline. And, you know, if the last few years tell us anything, change is a constant. So I mean, you're assuming no changes in the markets, no new competitors, no fresh ideas coming from customers, no need for iteration. And you're also assuming that each of these features is going to work as soon as they launch. So if you put three weeks into that new checkout page, then at the end of three weeks, it should be converting exactly as well as expected, and then you should be free to move on to the next thing. And also, you're assuming that by adding these features to the timeline, that each of these features should definitely exist, that they form part of the strategy and therefore should be codified. And ultimately, you're making one big assumption that nothing is going to change. And really, this timeline focus keeps your focus on features and deadlines. If that's what it gets your team looking at more than anything else, and it doesn't get you looking at solving problems for customers, or ultimately making money for the business, which is what we're here to do. So, I mean, what could possibly go wrong? Well, we end up with made up release dates that force your developers on stressful marches to launch everything on time. It ends up with your sales and customers getting expectations about what you have said you're going to deliver that you just can't meet. And often means that you miss opportunities in the market, and you end up leaving money on the table. Because you know what seemed like a good idea six months ago, turns out, you ended up building that as opposed to what turns out could have been a better idea if you kept an open mind and open roadmap. And often means that you're downright building the wrong things. And often, this is stacked with tech debt and low quality code. And this leads to you being a sad product manager. And it gets worse, because ultimately, it can create this vicious cycle that can get it can be really hard to get out of. And this is a cycle. It's not only vicious, but costly. Like here's how it eats into your profitability. No one wants to be caught holding the hot potato missing a deadline. So they give themselves ample buffer time. They enlarge the budgets that they put towards building anything unnecessarily, because they don't want to be the one who said that it was going to take a week, and then it took a week and a half or two weeks. Now, I'm not sure if you're familiar with Parkinson's Law, but work following Parkinson's Law expands to fit these parallel timelines. It's why projects always seem to brush up against their extended due dates as why scope always creeps. It drains resources and stretches out your return on investment. And so as project timelines get bloated, they appear riskier to stakeholders. And so execs, they start looking at this loaded longer roadmap, and they start feeling uneasy about these prolonged commitments. So what they do is they seek tighter controls and shorter deliverable dates. They think it's giving them a firmer grip on costs. But in reality, it's strangling the flexibility needed for genuine innovation and value creation. And so this rush leaves no time for discovery, or quality assurance, even teams are churning out project products without thorough market understanding. They're often misaligning customer needs and skipping quality checks. And so every flawed product or unsolved problem directly translates to miss revenue opportunities or additional post launch costs. It's costing your company money. And so what's really happening here is that you've got this constant tension that's breeding a blame culture. In a setting where every misstep feels like a career risk. Team members are growing contrary, cautious. They're overestimating tasks, and they're further inflating project timelines and costs, because they don't want to be the one who got it wrong, who gave a an estimate, and said it was gonna take this long, but it took this long, so they make it even longer next time. So they're not the one getting it wrong. And so the cycle continues. blame culture, essentially corrodes trusts, and it's the antithesis of psychological safety. It's psychological safety is a proven factor in high performing teams. And so with this stifle creativity and innovation, your products competitive edge, and its product, its profitability starts to diminish. And so this is how you end up with big, costly teams, you know, teams of like 150 developers and 30 product people and all that delivering very little value but being outperformed by nimble lean teams of like five they're not spending half their time on planning cycles and covering their butts. They're just out there creating value. So I talk to individuals all the time about this and everyone nods their heads and goes Yes, absolutely. This is how I want this to work. I totally get this. But organizations don't jump on board so easily. Like what's going on in orcs, show of hands in the chat anybody feel this in their org but feel like it hasn't really stuck before? And I take this chance to have a sip of water All right, I'm getting some fissures and thumbs ups. Some of those are going to the host and patent list. You guys feel free to use the everyone or you can just chat to me as well. That's fine. All right. So what is going on in these companies, I end up talking to companies all the time, who are trying to figure out why their companies can't get on board. But what's really going on inside organizations? Well, a lot of times, particularly the bigger, closer to, you know, publicly shared companies, publicly held companies, there's this fiduciary duty to increase shareholder value. And what that really means is the CEOs are incentivized to show quarter on quarter growth, and if they don't, the turfed and so management style lends itself to slow improvements, quarter over quarter driving costs down or revenues up, but rarely giving any opportunity to invest in proper future growth. So in that case, predictability becomes this huge factor where you know, upward growth growth doesn't even have to be that much like even sub 1% per years fine, as long as the outcomes match the forecast because unpredictability, spooks investors that can have a bigger knock on effect than anything else operational happening within the company. And so if you want predictability, the best way to do that is to break the business up and understand it in smaller, more manageable chunks. And this sort of makes sense. Except what that does, it leaves you with silos. And we all know that silos probably aren't a good thing. We've been trying to get away and break down silos for our entire careers. So what happens was silos, this is how vanity metrics are born, right? This is a dangerous territory. You know, divisions actually find themselves competing to max out their own proprietary metrics, instead of collaborating for the good of the business. And you end up with counterintuitive, businesses decisions, where, you know, one division makes sense for the bottom line of one particular division, but doesn't make sense for the bottom line of the entire company. And so the company ends up losing because they've got teams almost competing against each other. So what's actually happening in these silos? Well, here's what's happening. Here's why they kind of end up competing, because you see, the company will see some of these as profit centers. And some of these as call centers, like sales is a and marketing as well are seen as profit centers. You have money in your bucket, you put money into sales and marketing, and you get more money out of it. They're their revenue engines. Whereas cost centers are often things like operations and HR and things like that they cost money, but you have to have them. Well, where do you think product and customer service and innovation sits? More often than not, we're seen as a call center, which is detrimental because what you end up with is these vanity metrics for our division, and this is where you end up with vanity metrics like cadence and story points, and burndown. And things like this, it gets us trapped in this old pattern of writing finer and finer grade grained specs and breaking them down into points, which are really just a rough measure of time, essentially. And then measuring things like velocity or how quickly your team can burn down through a stack of points. It's coming from the need to have a predictable, stable business. At the end of the day. This model of working simply optimizes for building the most features as fast as possible, because it's reporting up to somebody whose job it is to keep costs down. But everyone knows that a whole bunch of features isn't the answer to building a good product, this isn't necessarily the best way to build the most profitable product either. Its output focused when it should be outcome focused. All this pointing and burning down at high velocity rarely leaves room for discovery and usually leads to teams burning out and to creating more tech debt. Measuring by output only and treating r&d Like a separate cost center is detrimental to the way that a lean company should work. And what is ultimately doing is not leaving room for discoveries, not leaving room for the company to be lean. And discovery is really key to any company's success. And I've just spotted somebody's comment in the chat saying using points of time as an incorrect way of using points. Yes, and yet they And this is how they're often used. And honestly, one just becomes almost a not a replacement, but it is a loose measure of one or the other. And so you see it being a way to measure even though you're not using time anyways. And so yeah, you're losing this ability to spend time in discovery. But these vanity metrics per division, don't just impact the product and r&d space. I mean, you see it impacting other spaces as well, like in sales and marketing teams. You ever seen any shady acquisition tactics that only work in the short term, here's one that actually hit up our team. Some time ago, actually now, but this was a an email that was blindly sent out to guest contacts, you can figure that somebody in the team said, You know what, just add a bunch of emails to the mailing list and make it so that we hit as many people as possible if your goal was just to hit as many people as possible, this hit it, but it's going to hinder the company in the long run, because I went through and spam flagged every last one of these. And you can bet that a lot of other people did this too. So it's going to be dragging down on something else on the other side. And so what you end up with are companies who end up with no room for discovery or shady tactics or, you know, other not great ways of running the business because they are trapped in these ways of working that are to service, a predictable way of running a business. So with that in mind, is there a better way? Well, yes, of course there is. I'm only here to talk to you because I have worked with, I guess you could say 1000s of other companies now on better ways of working. So I want to talk to you about Lean roadmapping. And mean roadmapping is a better way to navigate. And reason why we call it lean, lean is all about the build, measure, learn cycle. And really, it's more about the really important part of the lean. The Lean cycle is the Learn part, it's really essential to the benefits of lean, and it allows you to apply your learnings to ongoing iterations. Now I see your roadmap as a tool to help you learn and iterate at the product strategy level. Or put more succinctly, I consider your roadmap as a prototype for your strategy. So to to make that a little bit more concrete, a lot of us have probably done prototypes. But for new features, like when you go to build a new feature, you don't run straight in with a fully designed interface that you put together from scratch, you probably start with some basic sketches on a piece of paper or a whiteboard, or, you know, some sort of sketching tool, and you take that sketch and you show it to a colleague or a customer, and they give you some feedback, maybe they tell you to move a button here, add some copy there. And you throw out that first sketch and then you make a slightly better one, you take on board the feedback that you learn from it, and you repeat, until you're reasonably sure that you understand that the feature that you've got is going to solve the problem that you want it to in the first place. Well, roadmapping can be simpler, like your job is not to know the whole strategy and just lay it out blindly. Your job is to ask questions and get collective insights. And so at the roadmap level, what you're doing is you're laying out your assumptions of the problems and opportunities that you're seeing in front of the company and checking it with others. And it probably means making quite a few iterations based on feedback that you hear from different people. So the value isn't in the roadmap, the value is in the roadmapping process. So your roadmap itself, like your prototypes will get thrown out, particularly your first versions of the roadmap, you're going to present your first version of roadmap somebody and they're gonna say, that doesn't make sense. I think you should go this other way. And you're going to learn from that. A great product manager should lead their team in a collaborative roadmapping process and then use a flexible roadmap format to capture their assumptions so they can be checked regularly. Honestly, if each of you walked out of here and started your first roadmap like this, this is a crayon roadmap. I'd be really proud. Like, it shouldn't be pretty. It shouldn't be slick, too many people get too tied up and making this perfect roadmap. And you know, what you're really doing with a roadmap is you're saying As the product person here, I've listened to all the stakeholders around me, you've all given me some interesting insights. I've heard a series of problems, and I've interpreted as this, I think we should tackle this than this than this. What do you think? Have I got it right? And then take these assumptions to a colleague and check their opinion, if they agree, you might be on the right track. But if they start pointing out holes in the plan, then you can make adjustments, you know, maybe they start to add in a new problem that you hadn't thought to capture or change the order of things. Or maybe you don't learn something that you thought was a problem, but actually isn't a big deal and can be removed. Like there's nothing more lean than that. Here's a slightly more practical example, if you don't have crayons on hand, you can do this in Miro, for example, this is a roadmapping session that you could just do using quick post it notes, again, you're not looking for pretty, you're looking to lay out your assumptions, and just say, here's what I think here's some problems and opportunities and challenges that we have, let's just put them in vague order of, you know, importance for us. And let's see, if we agree on those to start with, what you're trying to do is build a stronger, more cohesive strategy that actually solves key problems with businesses, that the business lines that you're working in, and has fewer blind spots, and the sooner you get the the earlier in the process, you start this, the better you're gonna get at it. Now, I know that some of you, actually most of you, if you're working in product, I probably adopted someone else's roadmap. Or maybe you have your own roadmap from last year or earlier this year. And it's a big bag, oh, timelines, and junk that a whole bunch of assumptions. I encourage you to try roadmap bankruptcy, it's actually really freeing. If you've got a crap roadmap, just push it all to the side tomorrow, and start for fresh eyes to start over. Throw out your old roadmap and start again, you might go through and recreate that roadmap and check those assumptions with people. Now, what you might discover is you recreate the roadmap perfectly. And it proves that everything you had on your overall roadmap was in fact, the right thing. And you have validated it from beginning to end. But I almost guarantee you that there's going to be things that turn up on your new roadmap that you hadn't thought of in the old route roadmap, because you're you're blinded to it, you hadn't had a chance to actually see outside of your current plans to think of the new problems on the horizon that were actually close with any thoughts. Or there might be things that are on your old roadmap that actually aren't problems anymore. And as soon as you remove that roadmap, they don't become the most important problems, you actually realize that there's space for other important problems to tackle. So throw out that roadmap, start again, and then compare the two, you might discover that you're actually on a better track with a stronger strategy at the end of it. One fundamental thing that's really important to remember is that product is a big unknown. Like you're building into uncharted territory, there's no blueprint to follow, there's no right way to do this. It's like landing on a new unknown shore and knowing that, you want to get to that big gold top mountain in the distance, but you have to pick out the best path along the way. And you've got certain resources with you now. And you're going to pick up more resources and knowledge along the way. It's up to you and your team to survey your surroundings and decide what you have now, what problems you need to solve as you go. Every product is unique journey, everyone here is building a different product, no one has built the same thing as another person before no one else has built the same product or been on the same product journey. So this is where the concept of horizons come in. Like you're standing here in the present time, what we call now and you can see what's keeping the team busy right now and what problems are right in front of you. Like let's say you land on this new shore, and immediately saw that there's a bear right in front of you, like that's your first problem to solve. It's crystal clear, unless someone sees a bigger, different problem, you better start thinking of ways to solve that problem. But you can also see way off into the distance, you know, that mountaintop that you aspire to conquer, there's probably problems to solve there too, on your way, maybe something to do with keeping warm or you know, getting us some ice climbing gear, but that's too specific right now, you can figure that out. When you get closer, you're a long way off. And there's a lot of things you can do before you get there to gather resources, knowledge, but if there are known chunky problems, like get up the mountain, it's worth noting them down so you and your team can keep an eye out for ways to break them down and solve them over the course of the month a year of the journey ahead. And you can also see off into the middle distance in various directions and to various levels of degrees right how well you can see depends on how well equipped you are and what your starting position is now. You might spot opportunities to take advantage of that will help you along the way to reach that ultimate goal or problems that you need to overcome or avoid. You know, maybe there's a glistening city for the money that you can reach. Maybe there's a bog that you'll need to get over. So spot those and call those out and work with your team to identify what those different opportunities and challenges are. But there's probably multiple paths that you could take through this journey. And from where you're standing, you don't know which is the best one. After all, the further things are in the distance, the less certain you are about them. It might be faster to build the bridge, but it means that you're going to miss the uplift in resources you get from visiting the city. But from here, maybe it's a mirage in the desert anyways, you might not want to wait till you get a little bit closer. Unfortunately, you can't just whip out your phone and pull up Google Maps. That's not how it works. This is uncharted territory. No one has been here before to map it out for you. There is no right answer. But some answers aren't going to be better than others. The best answers come from teams who work together to survey the surroundings and lay out what they can see on the road ahead and regularly regroup to make sure that they're still on the best path. And just a cue from Jason there. If you have any questions, add them to the q&a, I'm just going to take a sip here. So these horizons translate to a product roadmap instead of a timeline, which is a single data driven line marketing forwards thinks in terms of these three buckets. So in that first bucket, you're granular about your focus in your scope. That's the stuff that's being prototyped and tested and built right now. And the later column is less about specific initiatives but more around outlining the problems you think needs to be solved in order to fulfill your vision. Now, if you're setting off on a journey like this, you might imagine the team might immediately start bickering because they haven't yet agreed on what it is they're actually trying to achieve. They know that they want to reach the summit, but they have no framework for measuring their success, and therefore they don't know whether they're actually working on the right things. After all, if you have no way of saying whether you're working the right things, who's to say whether you're working on the wrong thing. roadmapping without objectives can be chaos. So what we're trying to do here is align yourself to the outcomes. But why does so many teams give up on OKRs show of hands who here has tried OKRs loves them hates them had good experiences bad experiences? Right, so OKRs stands for objectives and key results. They are the objectives are the high level qualitative measures. And the key results are the specific and measurable metrics they usually time bound as well. The magic of OKRs is that the company sets the top level objectives, often called the Northstar metric, and then the team works together to decide how they can help contribute to that goal. And this is vastly different to the old skills, old school way of doing management where you think of management setting goals for each team and micromanaging the process. It means that it's using the knowledge of the whole team to set goals, which means that gaps are more naturally spotted and filled. The team can work more autonomously and isn't held up by limitations in knowledge or by or time by that middle or top management. You know, it's like when you might have a company goal of maximizing revenue from a market segment. You might have team member or each team stepping in with something like marketing, saying we'll attract the right sorts of customers design thing will make a delightful onboarding that converts and retains development saying we'll build a solid platform and deliver in a way so we can iterate often. So no one person is responsible for the Northstar. But together the whole team makes it happen. And I help spot the they help spot the gaps. Now a term that you'll need to know in the OKR world is initiatives and for some reason, it's like the Forgotten middle child. I guess because Wakers doesn't have a good ring to it. But initiatives are really important and initiative describes the specific activities or projects that the team is working on to influence Success have an OKR. Even if you identify what you need to achieve, which is the objective based on the company strategy, and determine what good looks like, which is the key results, you're not going to get very far if you're unable to clearly communicate the actions you plan to take in order to get there, which is the initiative. So let's use this as an example. Let's say you want to improve your overall health to avoid illness or injury. That's your objective. You might have a key results, you're measuring progress by something like let's lose 15 pounds by the end of the year. That's a key result. For this one key result, you're not going to just lose the weight by wheeling it away, you might set an initiative to introduce regular exercise to your schedule, or refactor your diet and start eating well. And chances are, you're going to make progress on both of these initiatives to hit your goal. And within each initiative initiative, there's probably a number of things you can try, all of which will take some time to see some results from now, for some reason, a lot of come a lot of OKR systems Miss initiatives, and it tends to lead to OKR drift. And it's what happens when you set up your objectives and key results in one place, you're saying we're going to go increase revenue here. And you know, we're going to see this measure go up by here. And then the team goes off and does a whole bunch of product things over here. And at the end of the quarter, they're asked to report on those specific goals. But it's been left in a spreadsheet or another tool over here, and they haven't looked at that spreadsheet or that other tool or cortex, they've been busy in the product space doing and learning and iterating. And it leads to this OKR drift. And so what you can do here, I mean, one of the what I hear is, people say that people saying that OKRs don't represent the stuff that I work on day to day, or we move so fast that the OKRs can't keep up. But really what you can do is connect your OKRs to your lean roadmap. So they stay front of mind. So by tying these three, these things together, this can be done with a alleen roadmap or an A now, next later roadmap. So each of these blocks are initiatives, or these problems to be solved. Each is linked to a specific objective or OKR. And then each one in turn is connected different experiments, ways that you might solve those particular problems and broken down into those three columns, the now next later. So this is one popular configuration. And this is a another that's similar, but groups initiatives by objective. Now, your roadmap can also help you with experimentation and validation that you're actually solving problems, because I see so many roadmaps running off to just be a whole bunch of features. And that's not what roadmapping should be about. So I'd like to think about the roadmap as a place to say, here are the problems we're looking to solve. And here's how we might go solve it. Here's a bunch of experiments that we are undergoing in order to solve that. And once the project is in development, don't just throw out these results or tuck them away somewhere that you'll never find them again, don't trash that roadmap, I see a habit all the time where people close the tickets, in JIRA, they crumble ball with sticky notes on the wall, and they start moving on to the next thing, which might seem for good for keeping up cadence, but bad for actually ensuring that they're making an impact. After all, just because something was launched, doesn't mean it actually solved, the problem you wanted it to doesn't mean that it actually had the impact you wanted it to. So you can use your roadmap to build in space for validation. And you can do that by creating a validation space on the roadmap. We call it the completed roadmap or the validation roadmap, where you literally have a space within the roadmap to say, here is what we did this objective. This was the experiments. And here were the results that we got from it. And it's connected or adjacent to or somehow connected to your roadmap so people can see it. And they can see here's what we're planning on doing. But here's what we did do. And this also helps to build trust in your future roadmap plans as well. So people are saying, well, why should we have you spend time on these other things you can say? Well, here's all the problems that we've solved in the past. And you can see the impact we've had, we raised revenue here, we decreased costs here, we changed our market share there, we can turn figures here, and you're able to show what you did and didn't do in the past. But the really key thing is that this format of the roadmap and takes the focus off delivering road dates and helps your team strive towards solving problems. Now, if you are budgeting for next year, a lot of People ask about, well, I've got to work to a particular budget, we've got it work to costs, how does this work, you can actually use OKRs to your advantage. Because think of it that this, if you've got a budget for a year, then you can say, well, let's say your budgets a million for a year, then your quarterly budget is a quarter million for your team for the quarter. Instead of saying, we're going to commit to specific features and initiatives, commit to working on the right objectives for that particular set of time. So q1, you're going to go commit to this particular objective, maybe it's increasing revenue or decreasing churn or whatever that objective is, and you're committing to a set time, which is equivalent to a set budget. And you're not saying what it is that you're actually going to deliver. But you are saying that you're going to run at it and do as many experiments as possible in that time, you don't know how many experiments you're gonna be able to do in that time, last quarter, you're able to do 30 experiments, some of which failed, some of which passed, and you increased the OKR, by 15%, whatever you did, that's why you had the validation roadmap, this quarter, you don't know how many you're going to be able to do, maybe you'll be able to do 15, may be able to do 50 experiments, you don't know what you're going to run out and do as many experiments as you can. And you have a process by which you run experiments. So what you're doing is you're saying, Give me that budget, and give me the space to do as much as I can, towards solving this problem, we're not going to lay out and do the planning and all the you know, laying it out in a roadmap format to tell you which features are gonna be delivered. And when because we're going to waste a lot of time trying to tell you when that's going to happen, we're just going to do as many experiments as we can, some will fail, and some will pass, we don't know which ones will fail, which ones will pass, but at the end of the quarter, almost guaranteed enough will pass that this number will go up into the right. So which number would you like us to increase, you want us to increase revenue, you want us to decrease churn, you want us to increase market share. And so the people doing the budgeting and the people setting the company direction, can help set that direction can help set that budget. And it's all set within that nice, fixed boxes that they like to see. But you still get the freedom to decide how you spend that time. And if you get pushed back on this, think about how other teams work. Sales, for example, works in this way, sales doesn't say, we're gonna close this deal by this date and this deal by this date. They don't know that they run experiments, they have a budget for the team and a process by which they run experiments. And those experiments are they pick up the phone, and they call people and they read send emails and they do sales touch points, some of those sales touch points fail, they get hung up on some of those past and they make sales, they don't know which ones are gonna pass or fail, but they have a process by which they're given money to for their team. And at the end of the quarter, enough people buy the product that they give the they're given trusts to repeat that the next quarter. So we're not looking for any more freedom than sales is in this type of process. You can actually use budgeting and quarterly OKRs to your advantage in this way. So I see this question a lot, which is cool. I like this. But how do I get my team on board? Well, I wouldn't be a real product management talk. If there wasn't an it depends slide in there somewhere. But I can tell you that it depends on the context in which you're operating. Who are you getting pushback from? And what are they making arguments for and against? There's nuances here, and I'm not going to go into all of them in this one quick session. But there are things I can tell you to convince your boss that deadlines will make you work faster, or show your investor that their work wasting your time if they want you to work in a waterfall way, or get your sales and marketing teams on board with a better launch and customer development flow. So they're not always waiting on you and the devs are showing your customers that you still have vision and are creating value even if you can't promise them delivery dates of their pet feature. I have written a detailed guide, if anybody would like to grab that QR code or I can send that through to you as well. This is a free guide. It's six pages. And that last page touches specifically on how to convince various stakeholders to move over from a timeline roadmap to a lean now neck later style roadmap. I'm always happy to chat to people afterwards if you send me an email if you've got a particularly tricky stakeholder as well. But with this guidance, I hope that I've helped at least a few of you move away from your old roadmap habits that have been having you leave money on the table and Come in with some new leaner ways of working that will unlock faster route to creating value while costing less to boot. And with that, I want to say thank you very much. If you found this interesting, I'd love to hear from you. Please do connect, feel free to grab those slides. Reach out to me on LinkedIn, email, Twitter. And I'm always open for chat. Thank you very much.
Jason Tanner 45:24
Awesome. Thank you, Jana. So first question, what if we actually do have some type of date, like a large trade show that is driving development of a new capability and new feature, we actually need to get some return on investment on the trade show? What do we do then when we actually do need to figure out how to deliver to a date?
Janna Bastow 45:51
Yeah, so I mean, we don't live in lala land, sometimes you do have dates, if they are strategically important or externally driven, you might have dates that you have to work to, if you have a date, then you have to either be flexible on scope, or quality. And of course, you don't want to be flexible in quality. And therefore, you've got to be flexible on scope. Or you've just got to plan it way in advance to make sure that you are not going to miss that date. If you've got like a one off date, you know, once a year, there's like a trade show, and you've got to have something out for that, then you can put that on your roadmap. And you can say, like, for example, in your robot format, there's nothing to say that you can't have. In those cards, this card has a due date, this card is flexible, this card has a due date, this card is flexible, what we'd recommend doing is making sure that you don't have that time line at the top, which means that everything has a due date on it. If a couple things have due dates on them, then you can still be flexible around that. But you're not penalizing yourself by having dates for everything. If something does have a date, the reality is, is that you've got to either plan way ahead, and you've got to spend that time in planning, breaking it down in lots of detail to remove any risk that it does go over or be ready to be flexible on something, either you turn up to that conference, and you're saying, Hey, we thought we were going to have these amazing 12 things. But we turned up with these pretty cool seven things and be ready to just rock the stage with that. Or be ready to be flexible on date saying hey, you know what, we were going to do this thing at this trade show. But actually what's gonna happen at this other one instead? Or be ready be flexible on quality. But that's where tech debt comes from. I wouldn't recommend that.
Jason Tanner 47:45
Right. There was another question that was asked about a book that you wrote the foreword to. And we appreciate you writing the foreword for our book. Yeah, of course. But the question was about product roadmaps, relaunched and any nuances or differences between that book and what you just presented that you would want to highlight?
Janna Bastow 48:07
Oh, right. Yeah. I mean, that book was written in 2017. So I have updated my thinking somewhat from that. Now, keeping in mind, I wrote the foreword for that. I didn't write everything about the roadmapping thinking in there. So I don't agree with everything that's written in that book. But it did have certainly forward thinking for its time and did have some really good thinking about roadmaps. It was the first book to talk about now. Nick's later roadmapping and had some really good stuff on that was the first place where I got to talk about your roadmap as a strategy for a product prototype, your roadmap being a prototype for your strategy? Yeah, so I'm trying to think as to what else I could different differentiate. I think one of the really key things that roadmapping has evolved to is that roadmapping is very much around nowadays showing the impact of your work, and accountability to the rest of the team and to the company. I think roadmapping before then, was more around a tool to help you show what was going to be delivered, or what was in the pipeline for development. And it's evolved into much more of a tool to say, here's how we're going to make an impact for this business. And that's where things like the completed roadmap came in. And I don't think they talked about things like the completed roadmap, for example, like what impact you've had on this roadmap, or by having a roadmap for example. So I really recommend taking up stuff like that.
Jason Tanner 49:51
Yeah, which is the connection I'm most interested in to profitability. So when you're looking at the different items added to the next later version of the roadmap? How are you assessing the economic impact in terms of return on investment? Or the economic opportunity for those items? Do you have any rules of thumb to use when you think about this, even for prod that?
Janna Bastow 50:15
Yeah, I mean, ultimately, it's about what comes down to is important to the business. Now, in most businesses, prodpad included, that should be very well aligned to what's important to your customers, it shouldn't be customer driven, but it should be customer informed. And so you're looking at in terms of oil, this is something that we see a lot of customers are asking for, but not just customers, because if you just do what your customers are asking for, you might end up building yourself into a corner, you should look at what does the market need, as well. And so look into wider discovery processes to figure out what's going to help you stay relevant to a wider market. And so sometimes it isn't what your customers have been asking for. But it is stuff that's going to help you, you know, get people through your onboarding more smoothly. You know, your customers never asked for a better onboarding flow, and yet they needed it. And that's can be really important to your, to your business. If you just built what your customers asked for that ask for free product, you'd be giving it away. Obviously, that's not profitable, right. And so it's really important to tie it back to what does the business need? And what does the wider market need? And? Well, there are rubrics, it is a matter of looking at it's a n dimensional puzzle. You know, it's where's the market today? And what's important to people? And what is the context of our particular company as well, because what our roadmap would be would be different from what a company very similar to us would be building, because we've got different context, right, we've got a different brand, we've got different existing code, different customers, different slightly different markets, even, you know, a product strategy really should take advantage of your position in the market. And what's unique about you in that space.
Jason Tanner 52:21
Okay, last question. What's your advice for avoiding Now next, later, overload like 50 things and now 75 things and next and 100 things in later?
Janna Bastow 52:32
Yeah, so one, I mean, make it a forcing function. If your roadmap is more than like a scroll or two, if you print it out, it's more than a couple of pages printed, it's too long. Either you have just put way too much on there. Or you are going way too granular. But generally speaking, what's happening there is people are putting solutions on the roadmap and not overarching problems, what you should be doing is thinking about what are the problems we're trying to solve? You might have several different ways potential solutions to solve those problems. And you could, you can bulk those in underneath it saying, well, here's, you know, five different ways you might solve this. But here's the problem, let's identify the problem level. And you shouldn't be saying that you're gonna be able to solve more than a couple problems at a time. Right? That should be your Now your next might be a few problems that are on the horizon, your leaders a few problems that are beyond there, any more than that, and you're either never gonna get to it, and you've got to prioritize more ruthlessly. Or you are, you need more product people like it's actually multiple product lines that you need to split out and share.
Jason Tanner 53:40
Yeah, so roughly a couple of problems per team. Yeah. All right. Awesome. Thanks so much, Jana, for accepting the invitation. And the great presentation certainly did enjoy it and for sharing so much. Yeah, absolutely. Meishan both in the deck, but also in your tips. And just one ungracefully. So I'll say goodbye now, because when I ended Webinar will will be gone. But certainly enjoy seeing you and to everyone who joined us as participants of the webinars, certainly enjoyed your attendance and appreciate you and again, we'll be sending out an email within 48 hours with the recording. And you've got the link there for slides and wish you all a great rest of your day, wherever you are. So thanks again. Take care.
Janna Bastow 54:30
Thank you, everybody. Take care. Bye for now.
