Product Management Webinar: Now-Next-Later Roadmaps

[00:00:00] Megan Saker: Hello everyone. Welcome to How to Convert Your Timeline Roadmap to a Now-Next-Later.

[00:00:05] Just to introduce myself, I’m Megan, I’m the CMO here at ProdPad.

[00:00:10] Thank you for joining us. What I’m going to start with doing before we kick off is to just give you some info on who ProdPad are. I’m sure a bunch of ProdPad our customers are ProdPad, but if you don’t know ProdPad. ProdPad is a tool that Janna and her co founder Simon built when they were project managers themselves.

[00:00:30] They needed something to help them track, keep track of all the experiments and the feedback. And so they built it and it is ProdPad. So using ProdPad as a product management tool gives you control organization and transparency, and it helps you create a sort of single source of truth for all your product decisions and your product strategy.

[00:00:51] And it is now used by thousands of product teams across the world. You can try it for free. There’s a free trial which [00:01:00] will give you extra time, the more things that you do in the trial. And we also have a sandbox environment. If you visit popad. com forward slash sandbox, you’ll be able to register for our sandbox and access to that is free and forever.

[00:01:14] It’s populated with A whole bunch of example, best practice data so you can see a whole bunch of best practice. Now next later roadmaps. Okay, ours idea management and prioritization and much more. We also have the most advanced AI tools of any product management software and they are well worth taking for a spin.

[00:01:36] So you can do that. in our sandbox or you can do that by starting the trial. And the team is all product people here. So please do give us a try and let us know what you think of the ProdPad tool. But right without further ado, I will introduce you to our presenter for today. Janna Basta.

[00:01:58] Now Janna is, [00:02:00] as well as being are the ProdPad CEO and co founder, also co founder of Mind the Product, and most importantly today is the inventor of the Now Next Later roadmap. So who better to tell you how to take your timeline roadmap and transform it into a Now Next Later? Janna. 

[00:02:22] Janna Bastow: Excellent. Hey, thank you so much for for setting us up there.

[00:02:25] Everyone’s here to learn the steps of converting your existing timeline roadmap into an annex later roadmap. So this is why this is what I’m going to help you out with today. You’ve come to the right place. So I know firsthand from my time as a product manager, it was the pain that comes from timeline roadmapping.

[00:02:40] This is how I used to do it. I’ve lived through the pain of putting dates against each and every item on your roadmap and, having to pull estimates out of. Thin air or disgruntled employee developers months before, about that particular piece of work to create something that, stands a chance of being realistic, but then you have to answer to all those missed deadlines and [00:03:00] rejiggle the timeline and, just to help with disappointed stakeholders roadmap was going to hold true.

[00:03:06] And this is how I used to do my roadmapping, and it wasn’t until myself and Simon Kass started working together on ProdPad, we started getting some versions out in front of people, that we realized that the timeline roadmap was setting people up to fail. So we put our heads together and came up with what’s become now the NowNextLater framework that you’re all probably familiar with.

[00:03:28] It’s a format that aligns with the modern way of doing product management with the lean and agile way of working. So it’s really going to be able to help you out with delivering faster. You’re not having people baking in. buffer time into their estimates so that, the timelines never slip and therefore things actually take less time to ship because you don’t end up with that issue where scope always creeps and things get procrastinated.

[00:03:53] And then as you speed up, you actually end up having you can do more in the time that you have. So you’re [00:04:00] shipping more for what you were compared to what you were doing with your way of working. And you’re also going to be driving. Better results. So now next later, isn’t just about those time horizons that we’re going to talk about, it’s about being outcome focused.

[00:04:15] It’s about delivering valuable outcomes for both the business and the customer. And you’re also going to be able to respond faster to new opportunities or to, threats and risks that are on the horizon, because this format affords you flexibility rather than rigid dates and deadlines. You’re also going to.

[00:04:35] Be staying more strategic, strategically aligned because everything on the nanoclator roadmap is tied to your core objectives and you’re going to be operating with simply greater efficiencies. You’re not going to be wasting time rejigging timelines when things slip. And finally, you’re going to enjoy.

[00:04:52] Approved staff retention, right? People are going to stick around because they don’t have the stress of these external deadline pressures while you’re [00:05:00] also giving them more autonomy, more emphasis put on discovery and experimentation and learning. nOw, if you’re here. I can probably assume that you’re already sold on the benefits of now next later.

[00:05:12] But you’re actually looking at how to make that step. This is the big thing that people run into is actually taking your timeline roadmap and turning it into a more agile now next later format that you can actually show off to people. I’d love to hear from people though in the chat. What’s your roadmap like today?

[00:05:28] Would you call it a now next later? Would you call it a timeline? Like, where are you on that continuum of trying to move over to now next later?

[00:05:38] I’ve seen somebody saying non existent, which is a totally valid answer as well. So we want to hear from you folks as well. What’s your roadmap like? How would you describe it? I’m seeing hybrids, quarter based in the CEO’s head. Yeah, I’ve been there too. All right. So let’s talk about the defining features of a now next later [00:06:00] roadmap.

[00:06:00] I want to make sure we’re all on the same page. As I said, it’s outcome focused. So this is different than what you might expect from a timeline roadmap, which is output focused, and it’s organized around problems to solve and is therefore the most customer centric approach to roadmapping, and it’s structured around broad time horizons rather than rigid, exact dates, like a timeline at the top.

[00:06:21] And it’s therefore flexible. It allows for change based on learning. And that flexibility is both in terms of. In terms of timeframes, as well as on the exact feature you end up shipping. So it’s flexible on the time and the scope.

[00:06:38] And if we don’t move, then what tends to happen is things get delivered more slowly, right? People put in that buffer time and work expands to fill that time given. That’s called Parkinson’s law. And it’s a real trap that you run into with a timeline roadmap. Your tech debt starts building up because the quality of product gets shipped is lower because people are constantly rushing things out the door.[00:07:00] 

[00:07:00] You end up missing opportunities. You end up with the team being less accountable for the results. They’re just focused on getting something out the door and it can lead to your brand reputation being damaged. It can lead to people leaving, developers getting frustrated or product people getting frustrated.

[00:07:15] And frankly, Money ends up being wasted building the wrong thing. Does this sound familiar to anybody? So let’s talk about the steps to convert your timeline roadmap to a now next later roadmap. So we’ve mapped out. Nine steps that are going to take you to this now next later format. I’m going to walk you through each step and I see people asking the question.

[00:07:41] Yes, there is going to be a recording of this. We’re recording now and we will be sending it out to you later. Buckle in. We’re going to go through those nine steps and then we’ll have time for questions afterwards. All right. So first step is you want to make sure that you’re you got to go get your strategy and vision, but do you have that in hand?

[00:07:58] And are you happy with your vision [00:08:00] statement? So before we start transitioning, we need to make sure that you have solid foundations in place. Now, as I’ve said, a Now Next Later roadmap is outcome focused by its very nature and is intrinsically linked to the value your product is trying to drive for both your customers and for your business.

[00:08:14] As such, your Now Next Later roadmap should be grounded in a really strong product vision. Now I’m not going to dive in to the art of compelling creating a compelling and effective product vision here, but if you don’t have one, or you think yours could do with a refresh, a couple of resources for you, one, check out our product vision template for guidance on how to best create one or get it into.

[00:08:35] Your prod pad account. And we have what we call our AI product coach, which will give you instant and actionable tips on how to improve your product vision. It’ll help check as to whether your vision is inspiring and motivating, whether it includes details. On both your buyers and users whether it covers your value proposition and links back to your desired outcomes, the stuff you’ve put in Prodpad.

[00:08:58] And, just [00:09:00] checks that it’s not ambiguous and not open to multiple interpretations. So lots of different ways that you can improve that. And Prodpad has tools to help you do that. So step one, make sure you’ve got your vision. Step two, Let’s check your OKRs. What have you gotten on board here? Now, by OKRs, objectives and key results, but I’m not dogmatic about that, right?

[00:09:20] You might be using strategy map or GSM or balanced scorecard or any other sort of KPI and metric. Our goal and metric type of system the really key thing is that you are, you have a set of things that you’re trying to achieve as a product. And as a business generally speaking, you should have like around 3 to 5.

[00:09:41] Objectives, no more than that. And it can be less than that. We at ProdPad, we use OKRs. And so that’s built into ProdPad’s tools and the OKR management side. But again, if you need help with this, then you can we’ve got a bit of help here. One, we’ve got a a complete collection of product OKR examples.[00:10:00] 

[00:10:00] We’ve got a whole bunch of OKR examples ready to get you started. We have a course on how to create objectives and key results. Which you can find at prodpad. com slash downloads and also that AI coach that I mentioned can help you here. So give it your top level objectives and it’ll brainstorm good key results.

[00:10:16] And by good key results, I mean leading an outcome focused ones or key results or metrics measure. So you’ve got your vision, you need your objectives. Let’s make sure that you have those on hand while we work into the next steps. The next step is to start thinking, making, it’s taking a step away from feature thinking to problem thinking.

[00:10:37] So if you’re currently working with a timeline roadmap, chances are the items that you have on there are more specific feature ideas, cause you’ve had to break them down and estimate how long they were going to take rather than these broader themes or areas of focus or these problems to solve. So structuring your roadmap as a series of feature ideas is detrimental.

[00:10:59] Other, among [00:11:00] other things, it creates an output mindset instead of an outcome focused one. Why is this important? Because measuring an output isn’t relevant to your product success. You need to measure outcomes and, have confidence that you’ve actually solved the problem that you intended to solve.

[00:11:17] Everyone knows that a whole bunch of features doesn’t necessarily make for the best product. The now next later roadmap should never be populated with a series of cards or items or whatever that are specifically features. But what you should do is structured around a 2 level hierarchy.

[00:11:33] So you’ve got your roadmap initiatives and their corresponding ideas. So this is what the hierarchy might look like on a a roadmap item where you’ve got your broad initiative, which is the problem to solve or the area of focus or the opportunity, if you’re familiar with the opportunity solution tree then each initiative might have a number of ideas within it, or by ideas, solutions or features or experiments.

[00:11:58] I like calling them experiments. [00:12:00] And. A new idea here, a new experiment might be a new feature idea. It might be an improvement to an existing feature. It might be removing a feature or changing the pricing of the packaging or improving help documentation or your product tour and other stuff like that.

[00:12:16] These are all things, experiments that could be run in order to help you solve the problem you’ve identified at that initiative level and help you reach the objective that you’ve tied that initiative to. So depending on where the initiative sits on your roadmap, those ideas could be a list of possibilities that still need to be considered.

[00:12:37] They might, some of them might need to be researched, explored, they might have to run discovery on them or possibly their ideas that you have done that discovery on, they have validated and you are ready to proceed with because some of the stuff in your roadmap. Today might be stuff that you are currently developing.

[00:12:53] So we’re going to show you how to translate that to features from features to initiatives, ideas, and then how to spell [00:13:00] that out in the now next later format.

[00:13:05] So how do you take these ideas from your timeline and convert them into this initiative ideas structure? Get yourself a whiteboard. We’re going to step away from the usual tools and we’re just going to follow these steps, right? And this can be a digital whiteboard or your own whiteboard. But basically what you’re going to do is make a sticky note for every item on your timeline roadmap and stick them to the board.

[00:13:24] We’re then going to do an affinity mapping exercise, which is basically just grouping stuff together, right? You want to get your team, work on this collaboratively and start. Grouping these sticky notes by theme. And what you’re going to do is try to find stuff that are not necessarily, the groups aren’t necessarily around their, the areas of the product or a particular user persona.

[00:13:45] Think about the grouping them by the problem that they solve, right? What the, what outcome you’re going to get by doing these stickies, by doing these ideas. And These problems could be things that are related to customers, like a common customer problem, [00:14:00] or even things that are related to business problems.

[00:14:03] So for example, you might have a bunch of features on your timeline that are ideas related to helping your customers share content more easily, or features that are all attempts to improve collaboration for your users. In these cases, your problem to solve could be something like, how can we help customers collaborate more effectively?

[00:14:22] So have a look through all these sticky notes on your board and think about the value that the feature would bring to the customer or to the business if it were successful. And then think about that value as a solution to a broader problem. And then articulate that problem in a short sentence. I actually find that using questions works well.

[00:14:39] Like, how might we, or can we do this in order to X? Go through your sticky notes, and when you’ve identified a problem to solve that’s already captured on your board move that sticky note over to that group keep your problems To solve broad and try not to get too specific about those problems, right?

[00:14:56] Cause otherwise you’re going to end up with a big messy now next later roadmap. [00:15:00] So you might have a problem, a feature, which is a Slack integration. At this stage, the problem to solve might be. Much broader, right? The Slack integration is pretty feature specific, but the problem to solve might be something like, how can we help our customers increase collaboration with other departments or with their customers or whatever it is that you’re trying to do?

[00:15:19] So we’re going to come back to more of these examples in a bit. I just saw a question come up in the chat. So thanks for that. Somebody suggested or asked the question. who attends this collaborative exercise. You definitely want your product people here. And you probably want folks from your product inner circle and perhaps a wider circle as well.

[00:15:40] Depends on the context of your team, but you want to be able to get people who know what these products are about. Things on the roadmap mean where they came from and what sort of problems the business has. So in a small company that might mean people from every department or, everybody from the company, if you’re a very small company you probably don’t want more than.[00:16:00] 

[00:16:01] Five to eight people in a group like this. Otherwise it gets unwieldy. So try to find people who can represent different areas. Once you start breaking, that 10 person group size, it becomes more of a lecture than it does a collaborative session. So try to keep it small enough that you can all pitch in and have conversations around stuff without running over each other, keeping in mind that what you’re creating here isn’t a final version.

[00:16:23] You’re not going to just take these stickies these groups and then publish it as your roadmap. We’ve got a few more steps yet, so I’ll talk you through that. tHe groupings you’ve created with your affinity mapping are going to become your roadmap initiatives with their related ideas. So let’s start picking off any groupings that have and start making these the right size.

[00:16:44] We want to find groupings on your board that have a lot of feature sticky notes within them. And if there’s one or more groups with five plus features in them, you’re going to probably want to spend time looking at these, right? It seems like you’ve got some really core problems, but you’ll also need to break down any [00:17:00] problems where, you’ve got a huge list of features that are all trying to solve that same issue.

[00:17:04] So for an example here is we’ve got one that’s around helping customers increase collaboration with other departments, and it’s got a whole bunch of ideas, some of which are, they’re all related, but they’re disparate. So you might break it out into a couple of different groupings, like the initiative level being, how can we help our customers increase collaboration through integrations?

[00:17:24] And then you have a specific set of integrations that link to that. Sorry, a specific set of ideas that are linked to that. And, or at the initiative level instead, you might have how can we help our customers increase collaboration with the sales team? And then you’ve got a series of ideas or stickies that relate to that.

[00:17:40] So there might be different ways of cutting it up. There’s not always a best answer, but the best answers are going to come from teams who work together on this and talk through, right? The reason we tell you to put it on a sticky board is because things are going to move around quite a lot at this point.

[00:17:54] And that’s healthy. 

[00:17:56] Megan Saker: And actually, Janna, sorry to jump in. Sarah Beatty’s asked a [00:18:00] question just before we started this. If the initiative is broad, is there a chance it will always stay in now? And so this is one, this is an exercise that you can run if something is really broad and there’s a lot of work in there.

[00:18:15] Yes, it will end up staying in the now. So try and break it out. Try and get more specific and put, iteration one in the now column, iteration two 

[00:18:26] Janna Bastow: in the next. Yeah. Oftentimes we have, we see teams all the time who are faced with big chunky problems to go solve. And if it’s something where you’re saying we’re always going to be working on this, then I’d argue that it’s not an initiative that you’re doing.

[00:18:40] There’s probably multiple problems to solve within that. Or that, that, that initiative is actually more of an objective, which is a layer above, right? It’s one of the goals for your company, and you’re always going to be working towards it at getting closer to, moving, hitting that goal or moving the needle in the right direction, at which point that.

[00:18:57] Help support the idea that you break it down into [00:19:00] smaller pieces and use the objective to tie them together and give a bit of cohesiveness to that roadmap to say, Hey, we’re always going to be doing this, right? If you’re a revenue base bill building business, you’re never going to have a you’re never not going to have an objective that says, increase market share or revenue or something like that, right?

[00:19:16] That’s an objective level. Whereas the ways that you’re going to go about doing that are going to change. And know your now column doesn’t have to move quickly, right? It’s not like you have to say this is all we’re going to do this quarter. And it fits within a quarter. If something does need to take longer than that, then you can acknowledge that.

[00:19:32] And the now next later roadmap can actually help articulate that problem. So thanks for that question and definitely keep pushing your question sending your questions in Megan’s going to try to catch them as we go. Randy made a good point. He’s as he said in the chat, he said, always push for small batch size, right?

[00:19:48] The, one of the key tenants of being agile is that you can break things down into smaller pieces and deliver along the way so that you can show value. As you go, you definitely don’t want something clogging up and you saying, ah, we’re [00:20:00] not going to deliver anything in here until we deliver everything in here.

[00:20:02] That’s not what we’re trying to do. We’re just trying to articulate what problem areas you’re working on, and then what experiments are being run. And as those experiments are being run, you’re shipping them out, ideally, right? You’ve got a dev team is able to send stuff to production as you go, and you can learn from that, and that might change the other experiments underneath it.

[00:20:24] THe last step in these initiatives is to map them out back to your product objectives, right? As I said, you might actually discover that some of your initiatives are actually more objective level if they’re so big, if this is an all encompassing thing, but this is one of the really essential components of the now next later roadmap is that it’s outcome focused.

[00:20:43] It’s led by your objectives. It’s tied back to your objectives. So everything on your roadmap, you should be able to say we’re working on this experiment in order to solve this problem in order to reach this objective.

[00:20:57] So grab your objectives. And we’re going to [00:21:00] take this over to the next step, which is to determine. For each of your initiative groupings, determine which objective is going to each one is going to help them to achieve. So you either want to color code your objectives or add some sort of flag or icon or emoji or something like that.

[00:21:15] So you can easily tell them apart. But what you’re actually getting at is being able to really clearly see the why, and that goes at the top. Your objectives goes at the top of your initiatives and are highlighted. So it’s really clear as to whether you’re working on one objective now or another objective later, or multiple things at the same time.

[00:21:33] Any initiative can have multiple objectives. You probably don’t want more than two or three, because beyond that, you might realize that you’re actually either your objectives aren’t separated enough or your initiatives are too grouped up still. So you’re finding that then break the initiative up and say this is the one we’re going to do to increase revenue.

[00:21:54] And this is the one we’re going to do to decrease churn. If those are your objectives.[00:22:00] 

[00:22:00] And then let’s define your time horizons. This is probably the most contentious part of NowNextLater roadmapping, because people love their timelines. They love that line along the top that’s always running forward, giving a definition as to when everything’s going to be done, even if that date, deadline is made up.

[00:22:17] And we all know it is past this quarter. So how do we translate that to a NowNextLater roadmap, particularly one that you can get away with in your particular company? Now I’ve seen thousands of people now change from timeline roadmaps to now next later, and most people actually just go with this straight up now next later terminology and put things into those buckets, but we do see people using other terminology, like particularly around Companies have come away from, quarter based planning or timeline based planning, they might use Q1, Q2, Q3 plus, and that plus is saying a lot, right?

[00:22:53] But it’s weaning them off the idea of a timeline roadmap that tells them when everything’s going to happen and gets them into [00:23:00] the idea of thinking in time horizons. So the now is the stuff that’s right in front of you. That’s the well understood problems and committed dev resources. The next is the stuff that’s a little bit further on from there.

[00:23:12] This is the stuff that’s in design or discovery. And you still need to check those assumptions. You still need to do some validation before you start breaking it down into the now column. And the later is your aspirations. This is the stuff way off into the horizon that you know is coming.

[00:23:28] If you want to reach your vision, if you want to reach your goals, you’ve got to tackle these big problems, but they’re big, they’re nebulous. They’re not broken down in more detail. And that’s totally fine because they’re off in the distance. So I have seen a number of different terminologies used for this.

[00:23:44] Now next later is our favorite. Fun fact, it actually started off with the much more catchily named current near term future. So you sometimes see that terminology around still, but now next later has a better ring to it, I think. We see this quarter, next quarter, beyond that. Active [00:24:00] development to be implemented next suggested future projects.

[00:24:03] One of my favorites though, is doing, discovering, dreaming. It’s a little bit whimsical, but it does describe what’s happening in each of those stages. All right, now you need to talk about how to get your initiatives into the right columns, right? So you know what you mean by now, next and later, you should be able to roughly map this to your timeline horizon.

[00:24:22] And this isn’t going to be perfect art, but really what you’re looking at is you need to think about the fact that you’re going to have a bunch of stakeholder expectations. hanging in over your timeline roadmap. So realistically, you might actually create some pain for yourself if you completely start from scratch and dismantle all those expectations.

[00:24:43] We don’t want that for you. So when you’re transitioning from timeline to nanics later, you can start by trying to just match those rough timings that you’ve previously presented in your timeline roadmap, just to get people on board with this first version. So you put your initiatives in that same [00:25:00] priority order.

[00:25:00] And then this creates a space that your team can collaborate around it and just, and figure out whether this still makes sense, right? Once you take the deadlines off, it opens people up to a clearer conversation around whether these are actually in the right order, but to start with, you can just translate your timeline to your now, next, later, and start using that as a baseline.

[00:25:21] If there’s any initiatives that you have a hard deadline against, then put that In the initiative information itself, right? And ProdPad, we have a space for you to do that. It’s a, I think it’s the most common misconception about now next later roadmaps is that you can’t have dates on it. Of course you can, right?

[00:25:39] All we’re doing is making sure that you don’t have a timeline at the top, which dictates where everything is based on where it is in that roadmap. If something has a due date, say so. Put it in the roadmap. Make sure it’s clear in there. Ideally, you don’t have dates on everything. Otherwise, you’re probably not a product company.

[00:25:55] You’re more of an agency style company. What you’re actually going to do is point out of our roadmap, [00:26:00] only 10 percent have hard dates. The other ones have more flexible dates. Or maybe it’s 70 30 or 80 20 or 50 50, but it allows you to identify that and then put the Timing information that’s key for that initiative on that initiative.

[00:26:15] So it might be that it has a strict hard date because it’s a regulatory legal thing coming up. That happens. You’ve got to put that on your roadmap. soMetimes it’s more around like a time sensitive feature. Something that’s only relevant to users that are particular time. And if you miss it, it kills the success of your feature.

[00:26:31] If you’re building for, The academic school year or for a Christmas rush. You need to get certain things out. Otherwise you got to wait until next year or not at all. If it’s commercial, if it’s like externally driven or strategically important either to your commercials or to, the way that your business runs, then you might need to put those dates on as well.

[00:26:52] The goal is to make sure that you’re not putting dates on things that don’t have to have dates. Don’t penalize yourself. Okay. By putting dates on things that [00:27:00] don’t need dates, because otherwise you’re going to lose that flexibility. You’re going to lose that ability to adjust on the fly. But do put the dates for the things that need to be communicated to the team, because this is part of your strategy and the roadmap is a strategic communication document.

[00:27:16] And then you’re going to take a step back and sense check whether, the feature ideas are actually right in the now next later stage that you’ve put them on. So you can have a look at whether they are in the right stage and make sure you adjust for that. So for example, if you’ve got an initiative that’s around you’re doing it right now, then the ideas that are in there are probably in the validated writing specs devs estimating or being built, area.

[00:27:42] You might have some ideas on the bottom that aren’t aligned with that, and that might be fine because you might be saying we’re going to do these ones first because they’re really key. But then if this doesn’t solve the problem, but this problem is still the most important thing to do, then here’s three other things we could go do.

[00:27:55] And you’ve got that list of ideas you could go tackle. So instead of prioritizing based on [00:28:00] what your backlog says you should do, you’re prioritizing based on what your strategic goals are, what your problems to solve are as a business, and making sure you crack those problems before you go run off and do something else.

[00:28:12] The stuff that’s in the next is generally around doing discovery and running experiments. And then the later stuff, this is the more nebulous, defining the problem, if you find that there’s a big difference between, you’ve got a pile here and a pile here two different initiatives, and you’ve got ideas that aren’t congruent, then you might need to shuffle up the initiative groupings.

[00:28:33] It is important to note that what you’re creating here is a product roadmap. It’s not, and should not be a release plan or a delivery plan, right? This isn’t something to be confused with your sprint backlog. They’re completely different beasts. The roadmap is a strategic communication document.

[00:28:51] It communicates the direction you’re taking with the problem with the product and the problems that you’re prioritizing that are going to Make an impact on your [00:29:00] goals. tHere are other tools out there for managing a a more tactical project management view of the work that’s coming up.

[00:29:07] So don’t try to use your roadmap to articulate every last ticket. That’s going to be done. Every last bug, every last piece of work that’s going to be done. The roadmap is a place to articulate the stuff that needs to be communicated at a strategic level. So if somebody looking at where, what your goals are and how you’re going to get there, then put that on the roadmap, if it’s relevant.

[00:29:26] If it’s irrelevant, some stuff is just business as usual, or just get it done. Then just go get it done. Don’t feel like it has to go through your roadmap. I give you permission to not put everything on your roadmap. Your release plan, the stack of tickets that you’re going to be putting out and the devs need to pick from and work from that’s going to be more fine grained and the two can be related.

[00:29:44] We have ways of connecting. Prod pad with your dev backlog and pushing the stuff over. But don’t feel like it needs to be a perfect visualization of everything that’s going through dev. Cause that’ll just drive you nuts.

[00:29:59] [00:30:00] Somebody’s asked a really good question here. Tamina said, if it’s not in the roadmap, does it not get lost in terms of visibility? No, because the roadmap isn’t meant to be a place where you see all of the stuff that’s being built, just like the roadmap doesn’t tell you everything that your marketing team is working on, or, everything that your you know, every bug that your dev team fixes, what it’s basically doing is creating a clear pipeline and clarity around what is being built in the product.

[00:30:33] And why so that when that goes through to the devs, they’ve got a good picture of that. And as it’s going through, you’re able to clarify that, make sure the right stuff is happening, but it’s very much tied to as somebody’s pointing here. It’s more of the the more focused on the outcomes that you’re aiming to get, but think about it this way as a product team, it’s not your job to fill up devs time.

[00:30:54] 100%, right? Your devs are going to have other stuff to do besides the product stuff. Some of that’s going to be [00:31:00] DevOps tasks, like making sure, the site is secure and the apps are all updated and everything like that. There’s also going to be a whole bunch of bugs. No one is bug free.

[00:31:07] And those bugs, for example don’t come through the product team. Some of you are going to be like as a product person, I do bugs. Totally fair, but you’re wearing a different hat. Those bugs are really coming through from your support and your Q& A hat your QA hat. And what’s really happening there is that you might have 10 percent of your backlog filled with bugs and 10 percent filled with maintenance stuff and DevOps tasks.

[00:31:32] And then the other 80 percent is new build, or it might be that you’re closer to a 50 50 where product only takes up 50 percent of devs time because dev has so much stuff, so many bugs and so much maintenance to do. The clear picture of everything that’s going out in dev is going to be your your dev backlog, because that’s where all these filters come together.

[00:31:49] All these different sources come together and filter together into one backlog, but prod pad is on, sorry, product is only responsible for that one piece of it. Generally, it’s a large sliver of the [00:32:00] work, but it’s not the full sliver, if that makes sense. As Pavel has said, so the stack is to use prod pad for your roadmap and Jira for delivery.

[00:32:09] Yes, that is the most common pattern that we see. Jira is by far our most. Common integration and followed by Azure DevOps. Basically, we’ve got lots of people are using tools like Jira, Trello, Azure DevOps and others to manage their backlog. And that’s where the stuff gets filtered in, but your roadmap and prod pad is there to make sure that the stuff that does go through in product is in fact, the right stuff.

[00:32:32] Does that make sense?

[00:32:36] All right. Thanks for the questions. So we’re nearly there. Couple more steps. First, we’re going to review the work and make sure that this is in the right place. Now think of your roadmap as a I like to call it a prototype for your strategy, right? It’s a place where you can say, here’s where I think we’re going.

[00:32:54] This is the direction we’re going to, we’re going, the steps we’re going to take based on, talking to the different people and looking at our [00:33:00] backlog and talking to the customers. But this is my first cut. Just like a prototype for a new feature isn’t the final version. It’s a version that’s there so you can get feedback on it.

[00:33:09] So your roadmap should be a space where you can go and show it to people and get feedback on whether your strategy is any good, whether those steps you’re taking are the right ones. And you should be able to take this first version that you’ve created using this affinity mapping and, dropping them together piece.

[00:33:24] You should be able to get feedback on that and you might show it to a colleague and they go, huh. Okay. Yeah. Totally get where you’re going here, but we forgot about this problem or, I see that you’ve got this problem on the roadmap, this area here, but I don’t think we need to do that because AI has solved it or whatever the thing is.

[00:33:39] So what you’re going to do is get feedback on this first version of your roadmap and people are going to destroy it, or they’re going to give you feedback that tells you, you didn’t think of this. He didn’t, you should have thought of that. And what about this? And you’re going to adjust it.

[00:33:51] It just like you would adjust a prototype that you were building for a a new feature. And so a good product manager [00:34:00] doesn’t just dictate a roadmap. They don’t just write down what they think and then go at it. A good product manager leaves a good collaboration effort around product roadmapping.

[00:34:13] All right, and then the final step is to publish and communicate your roadmap, get it in front of the right people. You’ve got your NowNextLater roadmap, you want to be able to show this to the right people. And it’s only by showing it to the right people that you’re going to be able to get that feedback.

[00:34:28] So first versions, you might show them the Mirror board that might be part of that inner group. But then as you start articulating into a now next later roadmap, like the one we see here, you’re going to want to share that love. As I said, it’s a strategic communication tool and the best way to communicate your product strategy is to get it in a way that people can really easily understand.

[00:34:49] So this is why you can put it into this now next later roadmap format, because it’s easier to read. It’s easier to understand at. We’ve got these things that we’re working on in order to solve this problem, [00:35:00] in order to reach these goals. Or, from the opposite side, these are the goals, and here’s what we’re going to do about it, and here’s what we’re going to do about that.

[00:35:07] Who needs to see a roadmap? You need to consider what level of detail. Different stakeholders need, and then you can create custom versions of your roadmap for different stakeholders. We can do this natively within product within prod pad, right? So you can take your master roadmap and then you can say, actually, just show the super high level version and ship that off to the execs or take this version here and hide some of the cards.

[00:35:30] Cause we don’t want to make them public and make that the sales and marketing roadmap, or take this version here and make it really detailed and share this with my inner circle and get feedback on it on a monthly basis as part of the roadmap session we do. we’ve actually got a a guide there.

[00:35:44] You can use that QR code to go in. It gives you a little bit more detail on who these different stakeholders are and how you might share it with them. But you want to make sure that you are getting it out in front of people, right? A roadmap that was just been made by a single product manager and not shared is about as good as, a napkin drawing of a [00:36:00] feature idea that you have.

[00:36:01] It’s just not the, not going to be the best version of it. You want to make the best version of your strategy by socializing your roadmap. Now, I know that people often ask this question, right? There’s going to be people who need convincing. I think Bradley’s just asked a question around, how do you.

[00:36:21] Set expectations for salespeople and it’s not just sales. They’re famous for it, but marketing as well. Sorry, Megan. Your investors, your execs, your customers. So we’ve actually written a guide on how to get these tricky stakeholders on board and provided you with it’s a take home.

[00:36:41] Presentation that you can use to sell other people on the the NowNextLater format. So people are going why are we moving? I like the old version. You can give them a presentation run by this or led by this presentation. It has speaker notes and everything you’re going to need to go with it to help you get everybody on board.

[00:36:59] We also have a [00:37:00] course that you can sign up for, so it includes what we’ve covered today, but more in depth detail on selling you on why timelines are bad, if you don’t already know how to get certain stakeholders on board, how to combine it with your OKRs in detail, so a lot more so make sure to grab this if you want to dive deeper into this.

[00:37:18] I just saw somebody say, Richard just said he can’t scan because he’s on his phone. That’s fine, we’ll be sending these links out to you afterwards, so definitely feel free to wait for that and we’ll get you signed up for that. 

[00:37:30] Megan Saker: I’ll sorry, I’ll also drop them here into the chat. 

[00:37:33] Janna Bastow: And it’s in the chat.

[00:37:34] Thank you, Megan. Great. Okay. And on that note, I want to say thank you very much and open it up for questions. I know I tackled some as we went today, but let’s have a look in that Q& A. I can see one in there. 

[00:37:48] Megan Saker: Yeah. And I’ve I’ve grabbed a bunch out of the chat as we’ve been going. So I’ve got a list. So shall I kick off?

[00:37:56] Right, Jana. Yeah. In fact okay, [00:38:00] here’s one from Lachlan. What about commitments that were a few quarters out in development, but take time? 

[00:38:08] Janna Bastow: Yeah, absolutely. The reality is that there’s going to be things that take some time. And this is why the now next later roadmap is actually powerful.

[00:38:15] Cause a lot of people think that as a as a larger business or as a more complex business, you need to be able to it’s not going to fit within the now next later roadmap, but actually what you’re going to do is basically say, here’s the stuff that is on our horizon, right?

[00:38:29] When you’re looking ahead at what needs to happen, is it something that’s happening in front of you? You’re actively working on right now. If so, that’s a now, if it’s something that happens beyond that then that’s the next. And if it’s something that’s beyond that, again, that’s the later. And sometimes the now, Is a chunker, right?

[00:38:45] Like you work in a complex space, right? You’re tackling healthcare or government problems or something like that. Kudos to you. But do keep in mind that some of these things are going to take longer to work through because you’ve got a, matrix [00:39:00] structure, hierarchy in your company and you’ve got regulations you’ve got to work to so that more planning has to happen.

[00:39:05] It’s okay. If your roadmap has. A chunker in the now if it is something you can break up, then you can put something, in the next or in the later to say this is what we’re working on now. And the rest is actually going to happen later. So be realistic with what you’re actually doing, but sometimes you do have you’re solving world problems, so it’s going to take a while. But it helps give people visibility as to what is happening now and then what is on the horizon beyond that. A lot of teams, because the timeline roadmap tends to set to like the 12 month goal is that’s too short sighted, right? So these companies have a whole bunch of stuff that’s happening and you’re not moving through it any faster or slower.

[00:39:45] It’s just that you’re actually only looking at a bunch of stuff that’s happening this year. Whether or not those dates are going to be right or not, but it only shows you what’s happening in the now. For some companies, the now column is a year. The next column is the next couple of years. The later column is 10 years, [00:40:00] right?

[00:40:00] Because you are tackling big chunky problems, and that’s totally fine. You want to actually be able to use the roadmap to look further ahead. anD you can think of the now column being like your entire timeline roadmap squished into one spot where you’re saying what are we actually working on now?

[00:40:14] Some companies though are the flip opposite where, if you are a fresh company, just starting up anybody here like Greenfield brand new startup, you haven’t even got your MVP out yet. Your now next later roadmap, the whole thing might be six months, right? Cause your vision, like you can’t see very far.

[00:40:32] You’re not standing on very much yet. You don’t have a big platform. Six months out is like a long way to plan. And your now is quite literally like this sprint and your next is the next three sprints. And that’s totally fine too. As your product matures, as your company matures, as your team matures, you’re going to build up like a bigger platform.

[00:40:51] To stand on so you can see further out and the more that you have a well equipped team, good instrumentation around measuring stuff [00:41:00] existing, history and constraints and tech debt, you’re going to have more to build from and therefore look further out, but also generally move slower.

[00:41:07] It’s the reality of of of how things go. And going back to that original point of trying to break things down to say, this is what’s actually keeping us busy now can make a really big difference in helping some of these slower moving companies move faster by breaking it down and delivering smaller pieces of it where possible.

[00:41:27] Megan Saker: Great. Thanks, Jenna. Some other questions we’ve had. This is interesting. Are there instances where timelines are actually better? 

[00:41:35] Janna Bastow: Yes. If you are building a project management, the timeline roadmap is based on the Gantt chart, which is a project management tool. If you know what it is that you need to build, You are certain about what the scope is then you can actually spend the time and get estimates for that and know that scope is not going to change.

[00:41:53] And you just plan it out and you build it. That’s how construction projects are built and stuff like [00:42:00] that. And it’s actually less wasteful, but the reality is that most of us don’t know what the final product is. And by final, what do we mean? Do we mean the product that it’s going to be in a year from now, or do we mean like the final Check it’s done.

[00:42:12] We can go work on the next one. If you’re working on a project, then you can have a project mindset around it. And that will be less wasteful than. Pretending you’re trying to figure it out as you go. But the reason we do the pretending you’re trying to figure it out as you go thing, the agile thing, is because we don’t know what it is that we’re supposed to be building.

[00:42:29] And if we assumed something without actually knowing, we could end up building the wrong thing, which is what so many people have been doing for so many years. I’ve been there. I know everybody else has been there. So think about whether, you have certainty about what it is you’re going to build and you’re not going to want to change, even if competitors do something or the market changes or whatever, and you’re just going to invest your resources and have that thing.

[00:42:51] You’re just going to build that thing, build, use a timeline not a timeline roadmap, but use a project plan. If you don’t know what the final version of your product is, [00:43:00] work in a lean agile way and use something like an annex later. Yeah. 

[00:43:04] Megan Saker: And I just, I think, yeah, if you’re working on a platform product it’s never finished.

[00:43:11] It’s always evolving and it’s always changing and you’re always improving it. So if you have a Gantt chart, Style tool, if that’s what you’re calling your product roadmap, then you are, it’s forcing you to think about specific features and too early, you’re committing to specific features and therefore you just will end up.

[00:43:35] building a feature, shipping a feature, because it was on the roadmap, rather than these are the outcomes we’re trying to drive, this is the problem we’re trying to solve. And then having the flexibility to, based on testing and learning, change it and iterate. 

[00:43:51] Janna Bastow: Yeah, said. 

[00:43:53] Megan Saker: Cool, if you have committed to a specific smaller item or bug that you need to [00:44:00] communicate to a client or a stakeholder, do you add these to the roadmap or handle them separately?

[00:44:07] Janna Bastow: It depends. So this depends on whether this thing that you’re doing is strategically impactful, right? Is this something that you need to communicate? Upwards and say, to the wider team, like this is part of our product strategy is to do this thing for this client and therefore it takes up this space on the roadmap.

[00:44:25] And that might depend, like if it’s something that’s going to push back existing work and people need to know, Oh, the reason we’re not working on this thing is because we have this other problem to solve, which is to solve this thing for the client. And I’m going to come back to that Point in a second.

[00:44:38] But if it’s something like, Oh we’re, this client has pointed out this bug, or actually this is really obvious feature that we’re missing. We should just make it so that, it’s there and it’s going to take a day’s work or an hour of dev team’s time. Just get it done, right?

[00:44:51] You don’t have to communicate everything in your roadmap because that would just be too much noise for the people who are looking at the roadmap. Then it doesn’t help them understand what the product strategy is. [00:45:00] You should have some time In carved out in development and in your support and QA teams that you can go and fix one off things and do small bits here and there without it going all the way through product and product going, oh, yeah where does this fit in the strategy?

[00:45:15] It doesn’t matter. Part of your strategy is that you have time to just do stuff and you’re not swamped with only product stuff. Now, as to whether you can arguably say that, doing this thing for this client is solving a problem versus, other problems with the business, you can absolutely classify it as that.

[00:45:31] However, if you find that every problem on your roadmap, every initiative on your roadmap, everything on your roadmap is around, Solving for individual clients, you might have a different type of problem, which is that you’ve fallen into the agency trap. And I know this cause I’ve been here as well. And the agency trap is when a product company has aspirations to build a product that’s going to solve for a wider market, right?

[00:45:59] It’s going to, we’re going to [00:46:00] grow from here to here, right? We’ve promised that the investors hockey stick growth. We got to here. So we’re working away. We’re going to do this any day now, but we had this one client over here who asked us to do this piece of custom work.

[00:46:11] And if we do that, then they’ll sign up. And we had this other one who asked for this other piece of custom work. And if we do that, they’ll sign up. And what you end up doing is custom bits of work for individual clients. It’s like you sell your time. You’re selling, March to client A and April to client B, and May to client C.

[00:46:27] And before you know it, you have no time to work on the discovery stuff that helps you figure out how you’re going to solve the wider problems for the world and what’s actually going to make you do that inflection point and go up, right? You’re almost certainly never going to get an inflection point like that if you’re just building.

[00:46:41] Individual client specs. So I always encourage people to take a step back and figure out as to whether, the stuff on the roadmap is being driven by sales or by their business because the business is just trading off their time for short term gains. If so, as I said, you might be in the agency trap.

[00:46:59] We’ve [00:47:00] written an article on this and we’re going to have an upcoming webinar on this at some point in time as well about the agency trap. So we can share that link with people afterwards as well. 

[00:47:10] Megan Saker: Great. We’ve got a an interesting question here from Luna, who is clearly a ProdPad customer because one of the things we have in ProdPad for anyone who doesn’t know is as well as Now Next Later, there’s also a bonus column on the left, which is completed and indeed a candidates column.

[00:47:28] so Luna’s question is when would you move an initiative to completed? Do you move it when You know, you as a product team have passed it over to Dev, Dev are working on it, or when do 

[00:47:41] Janna Bastow: you move it? Yeah, so it depends. I generally recommend moving it when you’ve got all the experiments, all the ideas on it finished to the point that it’s done in that development flow.

[00:47:53] So it’s no longer future work to be done, but there may be additional pieces of work in there that live in your completed section. In [00:48:00] ProdPad, you can track things like whether they aren’t they successful or failures or whatever, but we also have a state called measuring success. And so this is a place where you might be saying, okay here’s all the stuff and we need to measure success not over the course of the week that it went out or the month that went out, but over the next few months.

[00:48:16] So your completed roadmap is a place. It’s like a backwards looking roadmap of all the things that you’ve solved or tried to solve and how well you did with them. And you might have an initial measurement that you capture in there, and then you might have measurements at the one month, three months, six month mark, depending on what it is you’re trying to do.

[00:48:31] sO if you find that you’ve actually completed like. Half a card, half an initiative, because you’ve got, a bunch of ideas that here that are done and measuring success and the other ones, which are, waiting for something because, or, need to go back to discovery or whatever.

[00:48:46] Break that card in half, put one in completed and start measuring that, and then put the other one back into next or now or wherever it needs to be based on what you’re actually working on. So that you can successfully measure what you did and then And use that [00:49:00] to help inform what you should be doing as the next stage.

[00:49:03] It’s not uncommon to have to break cards up. Great. And I see questions in the Q& A as well. Thank you for that. Megan, do you want to pick one out? 

[00:49:13] Megan Saker: Yeah. Yeah. Okay. Bradley, and actually, Bradley, I was just about to ask one of your questions from the chat as well. But let’s do this. How do you think about sharing a Now, Next, Later roadmap with prospects and what sort of expectations do you recommend 

[00:49:30] Janna Bastow: setting?

[00:49:31] Yeah. I love showing our roadmap publicly. You can go to Prodpads roadmap on our site and you can see our public roadmap. And we know lots and lots of other companies who do this as well. What what the now next later roadmap does, it frees you up because you’re no longer committing to specific.

[00:49:49] Dates on when things are going to be done, or even specifically which features are going to be done. The last thing you want to do is show people a list of features and due dates that you have committed to internally only to [00:50:00] break their hearts when something goes wrong, because it usually does what you can do.

[00:50:03] If you take it up a level, you can say, Hey, here are the problem areas we’re tackling. And if you show that to a prospect or to a customer or to whatever, and they give you feedback saying, Oh, I don’t get it. This doesn’t align with what I’m hoping for in a tool. Okay. Maybe they weren’t the right customer for you.

[00:50:17] If lots of customers give you that feedback, then you might want to change your roadmap because apparently your market doesn’t like what you’re going to go do. And there’s nothing more lean than that, right? Getting feedback and feeding it into what you’re actually working on so that you don’t build the wrong thing.

[00:50:32] So it’s actually really healthy to get these problem level things in front of your prospects in front of your customers to make sure that it does align with what they’re hoping out of you. It’s a really good question, Brad. Yeah, 

[00:50:44] Megan Saker: we’ve got a couple of articles actually on the ProdPad blog, which look at public roadmaps and what to include on them and what not to.

[00:50:53] Yeah. Great. Just conscious 

[00:50:55] Janna Bastow: of time. We’ve just got, I’m happy to answer a couple more if people are sticking around. [00:51:00] Cause I know we always get the flooded questions right at the end. There was another one in Q and a there. You said around when do things typically transition from chunky problems to well formed features?

[00:51:10] And does the final version of the NowNextLater end up looking like a feature or an outcome? It’s going to be a bit of both, right? Because ultimately let’s admit it, most of the time when you’re aiming to reach an outcome, it does involve building some sort of feature. It’s not always new features.

[00:51:26] It might be removing features, right? Removing a feature is a great way to fix usability problems, right? Speed up onboarding. It might be that you’ve changed features or it might even be things that aren’t. feature related, maybe you did a pricing analysis and changed your pricing. Maybe you changed the proposition on your homepage.

[00:51:44] And that impacted how your traffic conversion flow to sign up worked, right? These are all problems you might have. And so once it actually moves from your roadmap to your completed, you’re completed is actually a list of here’s the things that we did and the problems we were trying to do. [00:52:00] Solve for and how we did with that, whereas you’re now next later, the now is that, here’s the problems that we’re looking to solve and the features that the experiments were specifically tackling.

[00:52:09] And the next and the later are often here are problems we’re thinking of. We haven’t even begun thought, think breaking down, like how this might be solved. And that’s okay. Cause it’s often the distance we’ll get there when we get there. 

[00:52:22] Megan Saker: And we actually on back on the in the slides. So if you.

[00:52:26] Watch the recording back when we send it. We have on one of the slides there, there is a a list which shows how your initiative title can evolve as your initiatives move. from right to left. So you can also find this example within the course that we’ve sent that you’ve got the link to there, but you something that might start off, for example, in the later column and the initiative title, the problem to solve could be, how can we help customers collaborate with other departments?[00:53:00] 

[00:53:00] Then as you mature and do that, all the ideas in that initiative, it could then, You could refine the title of the initiative to be something like increase user collaboration with other departments through integrations, if you’ve decided that actually that’s the best way. And then by the time it gets to the now column.

[00:53:21] Through all the discovery and research you’ve done into all the ideas, it could then you could your initiative title could become build a slack app to drive user collaboration. Yeah. So you can also mature what 

[00:53:37] Janna Bastow: you’re calling your initiative. And with that, think of, stuff in your later column as big boulders, and then you break them down into smaller rocks, and then you break them down into smaller pebbles, right?

[00:53:47] You want to get to the point that you can talk about things in this pebble sense, but you need to start with the boulders, and you need to figure out how you need to break those down. So that’s with Megan’s examples there, you could just see it going from big chunky, how do we do this, to, oh yeah, we could do [00:54:00] this, through to, oh, we’re doing this, because we did all the discovery on it.

[00:54:03] And I’m going to finish on one final question Tamina asked how does now next later work when strategy vision objectives aren’t agreed or in flux? And I hate to say it is that it, it doesn’t work as well, right? This is why you need to start with having a clear ideas to what your vision is, what your objectives are, because if you don’t have clear objectives, then whatever you put on the roadmap is right or wrong.

[00:54:25] You’ll find out later, right? You need to get that clarity as to what sort of things are key for the business before you start running off. Now, when you talk about, when your strategy is in flux, keeping in mind that your roadmap is a tool to figure out your strategy, right? So as long as you have clarity on, what distant mountain you’re heading to, then you can start saying what if we went this way?

[00:54:47] Or what if we went that way? And that is strategizing. So use your roadmap to help you clarify your strategy, but make sure you know which hill you’re heading to first. So on that note, I think we’re just about [00:55:00] out of time and out of questions. So I want to thank everybody so much for their time and thank you, Megan, for setting this up.

[00:55:07] As everyone has been asking, yes, there is a recording of this. So you will get that. And there’s been a bunch of links and other requests for stuff. We’ll send that over to you as well. So feel free to share that around with your colleagues. Absolutely. 

[00:55:20] Megan Saker: Thanks everyone. Thanks for joining.