Skip to main content

Product Management Webinar: Roadmaps and Backlogs

Finding the Perfect Fit: Product Roadmap and your Product Backlog

Watch our webinar with Liz Love, Chief Commercial Officer at ProdPad, and Head of Product, Kirsty Kearney-Greig as they explore the difference between the product roadmap and the product backlog, and how to use them together to ensure complete transparency in your product processes.

About Liz Love

 Liz Love is the Chief Commercial Officer at ProdPad. Having worked in software development since 2001, including 10+ years in product management, Liz knows the day-to-day struggles of product managers all too well. She’s passionate about helping others to be successful in product management, whether that’s process improvement, mentoring, or helping with best practices.

Key Takeaways

  • How to ensure constant movement towards your product vision
  • Where to focus your attention to prevent bottlenecks in your product process
  • How to create transparency in your product processes
  • How to prioritize your backlog like a pro
Webinars

[00:00:00] Megan Saker: Hello folks. Welcome to our webinar today on convincing your stakeholders that Now-Next-Later works best. I’ll just introduce myself very quickly. I’m Megan. I’m the CMO here at ProdPad. And yeah, what we’re going to cover today is how to go about winning buy in from your stakeholders, from your team, to make the move to the Now-Next-Later roadmapping approach.

How to get everyone convinced that it is the right decision for your organization. But first Just a bit of housekeeping. We are going to make sure there is time at the end for a Q& A. So please, whenever you think of a question whilst Jana is talking, please pop it in the Q& A box. So you’ll see across from the chat.

There’s a box there specifically for those questions. So throw them in at any point during the webinar. We’ll make sure there’s time at the end. We’ll come back to them and go through them on. Janet will answer them. Also, just to say that this webinar is just one hour. Apologies to any of you that have a daunting 19 minute slot there in your diary.

It’s not. We’re going to keep this to an hour. Obviously feel free to use the chat at any point. We will, after this webinar, send you a recording and the content that Jana is going to be sharing today is actually a slide deck that you can download yourselves as a template and use it, edit it, adapt it, do whatever you want, use it with your own stakeholders.

So let me introduce you to Janna Bastow. Many of you will be regular ProdPad webinar attendees and know Janna. Jana is a product management guru. She’s in fact, along with her co-founder of ProdPad Simon Cast, the inventor of the now next later roadmap. She’s co-founder of Mind the product.

So today, as I say, she’s going to walk you through all the arguments you’ll need to present to your team and your stakeholders to win their buy in, to move to agile roadmapping, and then our next later format. As I say, Jenna is going to take you through a ready made presentation slide deck that you’ll be able to download.

Edit and use yourself and we will email that link to you at the end, but you’ll also see a QR code that you can snap at the end. Without further ado, I will hand you over to Janna. 

[00:02:32] Janna Bastow: Excellent. Hey, thanks so much, Megan. And hey, everybody. Thanks for coming along today. Reason why we chose this subject is because it’s the one that vexes product people the most.

We talk about now and X later until the cows come home and product people get it. But when they try to bring it. Into their teams. This is where they start hitting objections and friction. Now we have coached literally thousands of teams, helped so many teams move from timeline roadmapping to now next later, we’ve got a few tricks and ways that you can start, bringing them on board with this. So we’re going to share that with you today. And as Megan said, we’re going to be using a particular part of the slide deck that you can take for yourself to use in house to convince your product people or your, the rest of your team. Sorry, not the product people, the everybody else that now next later is the way to go.

So let’s jump in. But before we get too far, I just want to introduce you to ProdPad. Some of you are already using it, which is great. Thank you so much for your support. Some of you, this might be new to you. ProdPad is a tool that was built by myself and my co founder, Simon, back when we were product managers ourselves.

Basically because we needed tools to do our own job. We needed something to keep track of all those experiments and all that customer feedback and to create a roadmap that would show people on the team where we’re going. So we built something. And so what we realized is that ProdPad was something that was going to give us control and help us organize our work and provide transparency into the product management space.

So people stopped wondering what us product people were up to and why we kept making decisions like we do. And what it does, it helps you create a single source of truth for your product decisions, for your product work. So nowadays it’s used by thousands of teams around the world. It’s a tool that you can try for free.

We have a free trial. You can jump in and start using it right away. And we also have a sandbox mode in ProdPad. That’s basically a version of ProdPad that’s preloaded with example data, like lean roadmaps and OKRs and feedback and experiments and all this other stuff. Sat in one place so you can move it around.

You can try it out and you can see how it’s going to work for you. And our team is made up of product people. So it was founded by a couple of product people and we’ve got product people throughout the team as well. And so we are constantly looking to learn and iterate and adjust. So we’d love to hear your feedback, jump in, give it a try and let us know.

And I also want to highlight some really cool stuff that we’ve been working on, right? We’re constantly iterating ProdPad, as I said but one of the really interesting areas that we dove into. Last year was AI, right? We got our hands on the the GPT API and started playing around. And we realized that we could enable product managers to reduce so much of their grunt work by making it easy to generate ideas and to flesh those ideas out, have it answer questions like how you might measure target outcomes or whether this idea is actually any good, you can compare those ideas to your vision.

You’ve got your objectives. You probably, a lot of you are probably working on your OKRs right now. You’ve got your high level objectives. This will help you brainstorm key results and not just any key results, but we’ve tweaked it to be to give you results that are outcome focused and leading metrics to measure your objectives by.

And it gives you feedback on stuff, right? We didn’t just want something that generates stuff. We wanted something that can be like your sidekick, like your coach. And so you can take things like your product vision, which you’ve gotten product pad, and it’ll give feedback on it and tell you how to strengthen that vision and iterate on it.

And we’ve also built out, this is the newest piece of it, a chat bot that you can talk to and get product insights, product advice, but also it knows what’s going on in your product pad account. So you can ask it questions like. Hey what should we work on based on what our customers have been asking for?

Or can you help me give, can you give me feedback on this roadmap? Or can you help me identify things that we could put on the roadmap that would match with our objectives? So it has this sort of insight and it’s available for you to jump in and give it a try. So we’d love your feedback on that.

 And ProdPad is a tool that you can start a free trial for. So jump in, give it a try and let us know what you think. Now on that note, I want to start talking you through how to get people over to the now, next, later format of ProdPad, right? Because of a roadmap, which is the format that we use within ProdPad.

Um. The thing is that you’ve got to think about who you’re presenting to, who is it you’re actually trying to get on board. You’re going to have a lot of people often within your company who don’t want to move away from a timeline roadmap for various different reasons. And so we’re going to look at how to get your exec leadership team on board, show them the benefits of Why you should be working in an agile roadmapping format, like now next later, as opposed to the timeline that you’ve been using for the last few years.

But also we’re going to help you get other departments on board with this, right? So let’s say it’s your sales team who is holding onto that, that timeline roadmap and those delivery dates that you, they used to promise. And what about your marketing team, or what about your customer facing teams?

So there’s different stakeholders within your business who might have different reasons why they object. To moving away. And so we’re going to give you some tips on objection handling. So really you need to understand who it is you’re going to appeal to, who it is in your particular company, like who is your tricky stakeholder and you might have more than one.

And from there we can start looking at ways to successfully win them over. So before we craft our arguments on to persuade these stakeholders let’s try and understand the reasons why. They’ve got preferences for timelines. What is it that they think timelines give them? What makes them think that they’re necessary?

Let’s start at the top here. The, your big bosses, bosses, your exec team, they like deadlines. Deadlines give them a sense of control or at least a sense of security that everything’s going to go according to plan and timeline blankets are like a security blanket for them. They’re a comfort blanket.

They reassure them that everything is working. In some organizations, you can find that the business leadership will lack trust that any department is not explicitly commercial, so your sales and marketing teams that they don’t trust that they have a mature enough appreciation for the commercial imperatives of the business.

They think it’s necessary for the non commercial teams, those who don’t have enough revenue, who don’t focus enough on revenue to appreciate the urgency to have deadlines and dates. So those people who do understand this urgency can push them and drive that pace. So this is how leadership can easily enforce pace and help them clearly see when it’s not being delivered.

But it’s also important to understand that sometimes leadership, especially in organizations who are transitioning from that traditional business model to more of a platform or SaaS model can have a mindset. That’s a bit of a hang up. From the days of selling individual one off project products or instances of a product to individual customers, right?

They’re doing custom work. so It’s not uncommon to have deadline expectations coming from your exec team as a hangover from that, I call it the agency trap, right? When companies are working in more of a an IT project or agency model. And put it this way, software agencies need dates and deadlines because they’re running with a very defined.

Project right? A client gives them a scope and a time and a cost and they deliver to that. They have billable hours and a specific quote to meet. And these are paying customers waiting for delivery of the product by a certain date and possibly contractual obligations to meet. But if you’re not an agency, this isn’t how you should operate.

It’s what I call the agency trap when product companies act like agencies taking on custom work, and it takes away the time that they have to spend in discovery work. So we’re going to address that one. Um, also bear in mind that some of the pressure you might be feeling from leadership. Is actually transferred pressure, right?

It’s from outside forces. They might have stakeholders of their own. It might be investors or customers who are pushing on them to get these dates. So you’ll need to show the execs how they can manage investor or board reporting, or, manage other teams around these dates as well. So this is why getting your execs on board is so important.

Now, sales teams are the. Other particularly vocal stakeholder group when it comes to ditching the timeline, right? This is the other group that’s going to give you problems. And why is that? What is their problems? tHey might run into fears. They might have fears like they’re no longer able to make commitments to their prospects, which screws up their plans on how they’re going to close deals.

This is particularly. Painful if the company is running in that sort of agency style mode, as opposed to thinking about themselves being a product company. They’re worried that delivery is going to slow down if there’s no deadline pressures. So similar to what your execs sometimes think. And.

They’re also sometimes afraid that they might look foolish if the road map pivots, if you change something that’s on the road map. So we’re going to talk about these types of fears as well. And then you get marketing, right? So marketing might be concerned with how they’re supposed to plan campaigns and launch stuff without a timeline, if they don’t have an idea as to when something is going to be out there.

But we can talk about how we can work with these fears as well. And then your customer teams are going to be primarily concerned with how they can confidently respond to customer questions. Customers are going to be wanting, wondering what it is that you’re actually up to and whether you’re building into the direction that makes sense for them.

And so your customer teams are going to want to cite as to what’s going on as well. So we’re going to look at how we can win over each of these stakeholders and get them all on board with the now next later way of working. The way that I really recommend doing this Is to get your stakeholders in a room and show them the light, show them what they’ve been missing because oftentimes they don’t understand why you’re making this change.

And so if you can explain to them. Where you’re coming from, what the value is for their particular function, and for the business, you can start getting people on board. One of the best ways to do this is to get people into a room together, a Zoom room is fine, right? And what you want to do is share with them the values of a Now Next Later roadmap and make sure that they’re on board with it.

So what I’m going to do is I’m going to show you some slides that we’ve created that we’re going to hand out to you afterwards that you can use. For your own stakeholders. So these next slides are ones that you can take home and the slides themselves also have cues in the slide notes, presenter notes.

So you can follow along and use that to get people on board. So keeping in mind that we are coming from a place where we have convinced or we’ve helped people, thousands of companies convinced their bosses and their teams to get on board with it. This is basically the formula the points that you can use now, because this is a take home thing that you can use for your own company.

Feel free to make adjustments, right? If there’s a different stakeholder you want to take in or take out or, address a particular concern, change these around, right? Chop and change these as you see fit. But here’s a way that you can start doing it. So imagine that you’ve got your hands on this deck and you’re convincing the rest of your stakeholders.

Here’s where you might start. So first of all, you want to bring them in and start talking about why Better Roadmap is going to get you better results. This isn’t just about you removing the pressure of having to put dates or you’re not too lazy to go get estimates from the rest of your team.

You’re doing this to get better results for your team. This is about driving high value outcomes for your company. So this is the frame of mind that we’re going to start this argument in this conversation in uh, and what you’re looking to do is help them move from timeline road mapping to agile road mapping.

So point out. What it is that you’re trying to do your proposal here is to move from one format to the other format. And what we’re going to do is talk them through what the now next later format is, and how the timeline roadmap format hasn’t been working for them point out the cracks in this facade and start.

Bringing forward this new idea. So again, this is very much an outcome focus. This is all about delivering solutions that are or to strategically important problems and measuring those results. So you’re going to provide more to them. You’re not taking something away. So what you’re going to be doing is you’re gonna be making a promise, right?

You’re going to be promising these different things that you could do for the company. One, like delivery will speed up. You will be able to deliver faster using a a timeline sorry a now next later roadmap, but you’re not caught up in trying to do all of the project management estimations before you jump in and try to solve the problems you’ll be shipping more.

You’ll be driving better results, right? You’re driving towards outcomes rather than just a whole bunch of outputs, a bunch of features. You’ll be responding faster to new opportunities and therefore not missing opportunities in the market, which is so important in this world when everything just changes on a dime every.

A few months, it seems, uh, you’re going to be better strategically aligned. So you’re going to be using cases like this to make the, you’re going to be making a case around how it aligns the whole team around it by having a simpler roadmap that identifies what your strategy is, as opposed to just having a list of features and things to do, and you’re going to be operating with greater efficiency, less waste.

There’s a reason we call it the lean roadmap format is that it’s less wasteful. And finally, you should be getting, you should be able to make the case that it will help you retain staff, right? No more sad developers who are leaving because it’s full of tech debt and, they’re sick of building just feature after feature with no real cause.

So I’m going to expand on each of these more later so that you have the points to drive these home. And those are going to be included in this deck. So first of all, make sure people know what you mean by agile road mapping and we use the term agile road mapping now next later road mapping and agile road mapping.

They go all by different names. Call it what you want, right? Call it whatever seems to work for your particular company. But I like the term. Agile because it speaks to that broader approach, the Agile methodology, which is, it allows for flexibility. It’s there for continuous improvement and rapid response to change.

And so therefore Agile road mapping has been adopted into road mapping or the Agile methodology has been adopted into your road mapping methods. And that’s how you get this now next later. So we’re definitely going to try to focus and sell people on the fact that this is outcome, not output focus, right?

You’re not just taking away dates. You’re actually giving them something, the outcomes here. You’re bringing the company into a more customer centric way of thinking so that the problems are organized around. Customer problems to solve. yoU are structuring with broad time horizons rather than rigid deadlines.

And so this is really important because this gives you that flexibility, but still gives people a sense of direction and pace and, distance how far something is from being done now. And really most importantly, it’s flexible. It gives you space for learning. So these are the things that you’re going to want to share with people as you are getting them on board with your.

Now next later way of working so you can then introduce that now next later road map as a specific way of doing agile road mapping. So this is the approach that was invented by myself and Simon. It actually came out of the fact that we were building prod patents early days and started looking at ways that we could build a road map that wouldn’t track people.

And so really we wanted to end the focus on features and deadline in favor of a greater emphasis. On discovery and it’s now being used by literally thousands of teams around the world. So many product managers are now using this and we’ve got proven cases of how this has helped team deliver more and be more outcome focused.

It’s also an easy to understand format, right? It’s it’s not convoluted with a whole bunch of junk. It helps you, it’s inherently strategically aligned, because I like to think of it as a prototype for your strategy, a way to outline The, your high level strategic steps before you dive into deep it gives you that flexibility so that you can change things on the fly based on insights that you get at the strategic level.

And it’s inherently outcome focused, right? Each of the things on your roadmap are going to be tied back to the outcomes that you’re looking to get for each of them. And it’s the most customer centric approach to roadmapping. bEcause what it’s doing is giving you clarity on what those customer facing problems are and outlining how you’re going to go about solving those problems.

So then you can start diving into deeper, right? So how does the the now next later roadmap work? As I’ve said, it’s often referred to as a lean roadmap or a time horizon roadmap. Now next later are the time horizons. The ones that are in the now column are your well understood problems with defined solutions and committed Development resources.

This is stuff that team is working on right now. You’ve got your next column, which is the problems that are generally at design or discovery stage with some assumptions that you need to validate before committing those resources. And then you’ve got your later column, right? These are your aspirations.

These are the things that are a bit fuzzy and are still taking form. They’re on the horizon in the distance. Although we do know that we want to solve them if we want to get to. That, the big vision for our company. And so basically, as you start working on things, you’ll take things from your later and you’ll break them down into more detail and they’ll move into your next.

And then you’ll break them down in more detail and they’ll become part of your now, and it’s not fully linear. Anybody who’s made a roadmap knows that your roadmap is not linear. And this isn’t trying to be, what it’s doing is mapping out what you understand. The product space in front of you looks like if this is what we tackle now, then what are we going to tackle next?

And what are we going to tackle further off in the distance? And as you take steps, think of these cards on the road map is stepping stones. As you take steps and you get closer to that future vision, you’re going to adjust and you’re going to say, Oh now that we can get, we can see more, we might actually take this direction instead.

And you shuffle the direction of these cards depending on what you learn. So it’s inherently a flexible roadmap that changes as you learn more. You also might call your roadmap columns different things, right? I, one of my favorite takes on it is calling the Now, Next, Later columns Doing, Discovering, Dreaming, because they outline the things that you’re going to be doing.

At those particular times during the, that far out on the roadmap, the things that are in the doing or what you’re doing right now, things in the second column or what you’re discovering. And the later column, the third column is you’re dreaming, right? Here’s where you’d like to get to, but you’ll figure it out as you get a bit closer as well.

Other teams like to wean themselves off the timeline roadmap. One way that really helps to work, helps people move over is to move from their usual timeline roadmap into something that has more of a fuzzy this quarter, next quarter, Q3 plus, right? And that way you’re getting people used to this sense of, time horizons, and they’re getting fuzzier as they get further away but not taking away those dates on day one. Once they get used to the, the Q1, Q2, Q3 sort of format, you can start bringing them closer and changing the wording to now, next, later, and that way you’re not stuck with things within particular columns.

But, what’s important is that understanding that the maturity of initiatives in each and in each horizon. So now is where you’ve got a granular area of focus. And whereas initiatives that are in the. Later are broad high level. They’re subject to change as you discover more about them.

And as initiatives move from right to left, they develop, they evolve, they, the mature and by the now column, they’re known pieces of work specs that are being written. Delivery dates are being planned. Development work is being done. aNd I can see that somebody Chris is saying in the the chat here that they found that Q1, Q2, Q3 to be a good safety feeling for people, right?

It feels more tangible to them. And I agree with this. It’s a really good way to get people on board with this. And there’s no shame in having. dates like that on your roadmap, on your now next later roadmap, because you’re still going to be getting most of the benefits of it. It’s still going to be outcome focused.

It’s still going to be customer centric. It’s still going to be easy to understand. And it’s always something that you can change later as people get more used to the three column view. So how it works, you’re gonna be talking to people about how you’re going to be populating this roadmap with or basically instead of populating your roadmap with features to be built your now next later roadmap contains what we call initiatives or roadmap cards, or, these chunky blocks, the big white blocks on the roadmap.

anD I like to think of them as problems to solve, or opportunities, or areas of focus, and within those initiatives are then a series of different ideas that could be worked on to try to solve that problem. We call them ideas in ProdPad Land, but I like to think of them as experiments as well. Because what you’re basically saying is we’re going to find several ways to experiment and solve this problem in order to reach the goal that’s on our roadmap.

And by using experiments, it gives you a little bit more flexibility to to think about how you’re going to solve this problem. You’re not meant to do all your experiments. There’s a bunch of ways that you could solve this problem. And so really you’re changing it from our roadmap is a list of things that we will do.

And instead, it’s a list of problems we want to solve and then broken down into how might we solve this problem. We could try this, and this. And as you work your way through, you get better at understanding how that problem is going to be broken down. And you start tackling that problem. You start working towards your outcome.

So the other key thing is that initiatives on the roadmap should be linked to at least one of your core product or company objectives, right? Those objectives are the that the green line or the blue line or the pink line at the top. These are all things that help you identify the why.

Why are we doing this? Why would we solve this problem? And so you should be able to create a roadmap that you can collapse down and ProdPad offers these collapsed views. You should be able to collapse it down and squidge your eyes and just get a sense as to what your roadmap is about, what your product strategy is.

Are you growing your user base up front and then getting revenue? Or are you going to tackle revenue and then market share or tackle the churn problem first? So you should be able to see these almost trends within your roadmap. That will help outline what your overall product strategy is. And then you break it down into more detail about what problem you’re going to solve.

And then break that down into even more detail about how you might solve that problem. So that’s the gist of how it works. Now there’s more on this that we can teach you. But we’re not going to dive into that because there’s a lot of nuances about how to do road mapping. I’ll show you a course.

Afterwords that allows you to dive into this stuff in more detail. But we’re all at this level when you’re bringing this to your team, they don’t need to know all the nuances. What you want to do is sell them on the benefits. So what is it that they actually get from this? Let’s go through these.

I mentioned this is the same list that I mentioned earlier. So we’re going to dive into these in more detail. bEcause NowNextLater does not rely on exact deadlines for its structure, teams aren’t asked to plan schedules ahead of time and commit to exact dates which are, for the most part, entirely fictitious this far out.

So that requirement for dates almost nearly nearly always sees teams Bake buffer time into their estimates in the hope of mitigating missing those deadlines and then being blamed and then feeling the pressure for that. Um, What often happens if you’re adding a whole bunch of buffer time to your work and putting that on your roadmap is that if you’ve ever heard of Parkinson’s law, it’s the law that states that work expands to fill that time.

And so what was once a cautious estimate becomes the actual time taken. You rarely hear of teams finishing things early and then cracking on with the next thing. Things are always coming out just about on time or a little bit late, regardless of how much time you said up front you were going to spend on it.

So the broader time horizons of pro of the NADx later means that no one is baking in buffer time just for the sake of having it. And things actually get delivered faster. If things move faster, then more work can get done, right? More features are built. What you’ll find is teams using NowNixLater deliver more, more often, and get things out the door faster than teams who have to spend all that time doing the planning and figuring out exactly how long they’d want it to sit on the roadmap, and then try to line them all up in a row.

Agile roadmapping and the nanoslator roadmap means that your team is going to move faster and ship more. This is a really key selling point and it’s sometimes a bit counterintuitive. People think that having deadlines is going to get them to move faster, but it’s not true. Deadlines have never inspired people to move faster.

What it’s really going to do is mean that you’re having to protect your butts and not get as many things put on that roadmap and therefore deliver less.

One of the other things that you can emphasize here is Talking about the outcomes that you’re going to be getting rather than the output that you’re going to be focused on, right? So each roadmap item is focused on a particular outcome, solving a particular problem for the customer and for the business.

So this emphasis means that the product team is accountable for an outcome, not just those outputs. This is really key because, remember, delivered does not mean done. Results have to be measured and iterations and improvements made where needed. Products bloated with ineffective features essentially become a thing of the past, right?

You’re not going to want to worry about that. So with Now Next Later, teams are motivated to drive real value and deliver against their objectives, not just have a feature because the roadmap said to have a feature. So you’re declaring the problem. Not the solution and the roadmap is a space to discover what’s actually best and the best way to solve that problem.

So roadmapping and the now next later format, what you want to really enforce is the fact that it’s there to help you deliver greater value to the customer to the business.

Other really key thing that you want to drive home is the flexibility afforded by having this timeline or this time horizon way of working, right? You’re focused on those outcomes. You’re focused on the time horizon, but really you’re focused on the order in which you’re looking to tackle things.

And you can adapt that order, right? You might finish one thing and then realize that the next most important thing is not what you thought it was last quarter. It’s something new because. The market’s changed or people reacted differently to what it is that you built last quarter. So the roadmap format should give you space to adapt.

Naturally, as you learn more, so there might be ways that you need things you need to respond to. So there might be new discoveries from user research. There might be market research. There might be a competitor analysis. That’s been done. There might be shifts in the markets, just in the economy. Lots of things happen.

We know this now. There might be new opportunities like a. AI comes out or the next big thing comes out and you realize that there’s a huge opportunity to build that in where you no longer beholden to building, whatever it said you to build in June, just because June is here. You should build what’s most important for the business as that point comes up, as that time comes up, as that opportunity comes up.

And there might just be changing strategic priorities, right? The company might have to shift its goals and therefore your roadmap needs to be able to shift as well. So the now next later roadmapping approach, what you really want to drive home is that it’s going to be, allow you to respond faster to threats and capitalize on new opportunities, right?

You’re going to be able to adjust your plan as you go.

Other key point is that the now next later format. requires all initiatives to be linked to a product objective or a company objective, right? This is an IR clan way of ensuring that the team is prioritizing and working on things that actually bring strategic value to the business. You can’t put things on the roadmap.

Just because you wanted a new feature, you’ve got to be able to say what features does this problem solve? And why do we want to solve this? If you can’t answer those two questions, then it probably doesn’t deserve to be on your roadmap. So it’s a really good forcing function to get your team thinking about the strategy and aligning the work that’s being done to that company or product level strategy.

So really drive that point home about that alignment and then it’s also going to help you operate with greater efficiency. Everyone loves to save a bit of time and not waste their time doing stuff that ends up not being used, right? So the now next later time horizons stop product teams from wasting time planning out super detailed schedules that are far in the future about, what’s going to be delivered and when oftentimes that stuff.

Just ends up getting reworked or thrown out or ignored because they naturally have to change along the way. And it’s also hard to estimate that far out. And so the more that you’re doing it, the more that you’re making it up and that’s not a useful. Way to spend your time as a product manager.

You can be spending that time talking to customers or learning about the market or, figuring out the best thing to build next, as opposed to trying to figure out how long something’s going to take in three months time, it doesn’t matter and you don’t know. So it drives efficiencies and it’s going to unlock more time for higher value product management work, really drive this point home as well.

And then the last one, this is really key for people who are in the exec team are Drive home the fact that it makes for happier teams and therefore better retention. What you’re really getting here is the fact that you’re, when you remove the practice of setting deadlines too far in the future, you alleviate the pressure and fear that comes with hitting unrealistic dates.

The delivery dates. Put in place with now next later way of working are only set once work has been defined and specifications have been written. You’re not trying to plan way out and then hold people to these dates that haven’t been that aren’t realistic. 

What you’re really looking to do here is to what you’re actually looking to do here is also it reduces the amount of tech debt, right? If you have a whole bunch of. Projects that end up getting delivered one after the other, but you end up cutting it close at each turn, you’re going to start accruing tech debt.

And that tech debt stacks up, creates a tech code base that becomes unworkable. And you end up with teams that have just tons and tons of difficulties building things, unhappy developers who end up. Leaving, right? And so having this way of working helps to retain your staff and reduces your hiring spend, right?

You don’t have to replace people, you don’t have to train people up. fLip this around the other way as well, right? You want to tell them about the benefits, but you also want to give them the warning about what happens If they don’t, right? So delivery is slower, tech debt builds up, and you end up with a tech project, a tech stack that needs to be rewritten opportunities end up being missed, right?

You’re too blinded by what you said you were going to build at the beginning of the year, and you’re halfway through the year now, that you have to go build whatever it says to go do in June, that you don’t look outside and say, oh maybe we should be building this instead, because this is going to solve the right problems for us.

You end up with people being less accountable for the results, and you end up with your brand reputation sometimes being damaged if you build the wrong things, or if you end up missing promises that you’ve made in this roadmap, you end up losing people in the team if they’re not able to work in a autonomous way to solve the problems in the best way, rather than just cranking out feature after feature, which is soul destroying and oftentimes money is wasted building the wrong thing.

So many teams end up just building stuff because it seemed like a good idea when they mapped out this road map at the beginning of the year and aren’t actually building the right stuff. So other really key thing is that you want to make sure that you’re getting certain you want to make sure that people on the team are feeling this win, right?

So a lot of what we’ve spoken about so far are benefits for the wider team or for the exec team. You really want to be driving those benefits home. But also you can use these slides here to tell, to talk the sales team through or talk different mark different Stakeholders through, and we’ll go through a bunch of different ones as to how they’re going to win doing this.

So this is a win situation. You’re not taking something away. So for sales team. They’re going to end up with better objection handling, right? So presenting your roadmap through problems to solve can provide your salespeople with a simple way to handle objections and answer needs, right? If a prospect says a competitor has one feature that we don’t, the salesperson can drill into the problem that the feature is trying to solve, and then they can scan.

And then they can start explaining a different feature that we might have or soon to have that solves that problem and, maybe suggest that it’s a better way of solving it. So it’s driving salespeople to think about the problems that people are having, as opposed to just saying tick box, do we have this feature or not compared to our competitor?

You’re really truly getting people to think about the problem view. It’s also a safer way to share the roadmap, right? You might have two different types of salespeople, right? You’ve got one who is smart enough not to show the timeline roadmaps with prospects. But we all know some salespeople will just take that roadmap and share with prospects and go ta dum, go Take your pick.

What would you like to buy? And when would you like to buy it? Because we’re going to have all these cool features, which we know the roadmap never gets delivered. A timeline roadmap never gets delivered as. It was written out. And so it’s dangerous, right? You end up with salespeople who get mud on their face because they’ve made promises that the team can’t keep.

And so with using a now next later roadmap, you’ve taken the dates off. You’re not talking about specific features that can be delivered by specific dates. You’re able to turn that around and say Hey, here are the problems we’re looking to solve. We’re going to go from here to here, these types of problems.

And you’re not making promises of specific things that are going to be delivered for them. But you can use this as an opportunity to discover whether these problems align with your customers. And if one customer comes back and looks at your roadmap and says, Oh, this isn’t right for us. It’s probably not a big signal.

If a lot of customers look at your roadmap and say, Whoa, I can’t believe you’re solving this problem before you solve this problem. That’s good insight. And that might be a time that you can adjust that roadmap. So you can work with your salespeople to share the roadmap as you have it, get feedback on it and use that feedback to inform you as to whether you’re heading in the right direction that your customers care about, that your market cares about.

And it’s a huge misconception that now next later roadmaps cannot have dates at all, one of its biggest misconceptions. And this is the thing that often holds sales teams or even execs back. If a huge deal hangs on a particular feature being live on a particular date. Then you might be able to work that out, right?

You can it doesn’t mean that you don’t have dates on that roadmap. It means that you’re not driving that roadmap by dates. So something has to have a hard date. You can show that on the roadmap. Now, what you’re giving up is that your team does need to do the project management work to line up to get that.

But you’re still able to show specific dates. You’re still able to communicate dates where they are strategically important. And externally driven, right? So it’s not just about putting arbitrary dates on everything, but if something does need to be communicated, you can still communicate that on a now, next late, now, next later roadmap.

iF you’ve got a sales team on board with, or if you’re trying to get the sales team on board with the now, next later roadmap and they’re pushing back on it, You might find that they’re struggling because they’re not used to selling the product that exists today, right? This can be a tough conversation to have because sometimes it means that the sales team just isn’t up to the job, right?

They’re selling something that doesn’t exist yet because it’s easier to get somebody to just come along and state what they want rather than working. Harder to find the types of leads that they actually do that actually are going to make use of your product as is. So really key thing that you can be doing is working with your sales team to identify your ideal customer profile, your ICP, and they should be able to.

Target the right types of leads that are going to find your product useful for what it is today, rather than just constantly throwing it out to anybody and bringing in anybody. So you’ve got to be that, that that voice to say, here’s who is going to use our product. Here’s the jobs it does solve. Go find people who need to solve those jobs.

So that’s a a really key point is that you’ve got to work with your salespeople on what your ICP is. The marketing team is often afraid of moving to the now next later format because they think that they need a deadline so that they can launch their. Features they can launch their campaigns on the same day that you’ve launched your features.

And that is always fraught with difficulty because what you’re trying to do is you’re trying to line up a development project to land on the same day as a marketing project. And if that development project gets pushed back, your marketing project. has jumped the gun, right? Or they’ve lost money or they’ve lost time.

What you want to do is you want to separate your hard and soft launches, right? So your soft launch comes out and from that point you’ve got a version of the product that is in a feature flagged area of your product or is in a beta subdomain or is, turned on just for specific customers. And what you want to do is you and then you can turn this thing on just for your internal users or a specific set of users, maybe a beta group of people, and then from there, marketing can pick it up and they can plan out the biggest bangest launch that they can imagine, right?

But now, instead of trying to tie their launch date with your feature launch date. They’re starting from a point that the feature already exists. They can get pictures of it. They can get videos of it. They can start getting testimonials of it in this soft launch format. And then from there, they can plan out a huge launch, right?

Whether this takes them six days or six weeks or whatever it takes them to do this launch. It separates your soft launch from your hard launch. And at that point that hard launch goes out, you know that feature is going to be there because. It’s in a feature flag mode. It’s in beta. It can just be turned on as opposed to you trying to figure out if you can actually get things out on that date and possibly losing scope and quality along the way.

So make sure that you use the soft launch to give your marketing team heads up on Where they’re going with it use that soft launch to give them confidence in the feature and, show them what the feature is actually going to be as opposed to them hoping it matches the original design specs from earlier on.

And basically this means that your campaigns have a better chance of success. You’re always going to have a constant stream of campaigns going out. They’ll just be shifted by Whether it’s six days or six weeks or six months for the marketing team to make their their launch happen. But it then has a list of really solid campaigns that always work and the product’s always there for them backed up with great testimonials and videos and everything they need to create to make that campaign really pop.

And then with customer teams, right? One of the really key things we have customer teams. We’re talking support, customer success, account management, customer service. They no longer have to deal with complaints when dates are missing, when dates are missed, right? Cause you’re not sitting here making promises of what’s going to be delivered and when you’re focused on solving the right problems for the business.

And things are constantly going out the door because you’re shipping faster, but. If you have a customer facing roadmap that shows a whole bunch of due dates and delivery dates, you’re beholden to either hit those dates or let somebody down, and you’re no longer going to be letting people down. You’re just going to be shipping the right things that make sense for your business and just constantly keeping your customers updated on what’s coming or what’s been launched.

yOu no longer have to field endless feature requests. It’s more focused around which problems to solve, right? So you’re still going to feature requests, but you can align them with the problem to solve and be able to give people a sense as to whether these are the types of areas that you’re focusing on or whether these are areas that aren’t congruent with your strategy.

And you’re no longer taking in customer. Requests and constantly thinking, Oh, should we build this one or should we build that one that we heard last week? You’re focused on solving problems that are important for the business. And then the roadmap itself, the now next later roadmap, as I said, with the sales team, it’s safe to share, right?

It’s easier to understand this roadmap. You can basically say, here’s where it is. We are now. Here’s where we’re going with it. And here’s the reasons why we’re trying to hit. We’re trying to solve these types of problems and build this type of company. And that helps your customers understand whether your product is aligned with their longer term vision.

So it’s not about getting their pet. feature in there. It’s about whether it solves the right types of problems for them, regardless of which feature you actually end up building to solve that problem. So you can use this opportunity to get customer validation and to get buy in on your product strategy and your vision.

You can show them the Now Next Later road map and get that buy in. And then you can iterate your road map based on insights that you glean from these customer conversations. So make use of your roadmap, get it in front of customers and use it to get your get insight as to whether you’re heading in the right direction that, that works for where the market needs you to go.

Justin in the chat had a really good point here. He said, your customers can often be more forgiving than your internal teams. So once you’re able to show people that. You are building towards a solid vision. You are solving key problems. They’re not going to get picky over which feature gets delivered.

When they’re going to worry that you’re actually still constantly building. So show them what it is that you are building and what have been building and then show them the problems that you’re solving that you’re solving for as you move forwards. So let’s really drive this home for your team.

We want to finish your, your presentation to your team here with some stats. And you want to say, let’s not be a statistic, right? We know that 75 percent of businesses anticipate that software project will fail. That whole planning things out in. Many projects lined up on your timeline roadmap.

75 percent of them aren’t going to meet the time scope or cost or quality requirements upfront anyways. So what is this whole planning thing that we’re doing anyways, it feels like a big waste of time. We also know that 32 percent of it projects face challenges because they’re, they don’t have clear objectives.

So let’s solve that by making sure that roadmap is tied back to an objective. If you can’t tie it back to an objective. Don’t put it on the roadmap. We also know that 45 percent of features and functions in software projects are never used. So let’s try to solve for that problem, make sure that we are building stuff that solves real problems and aren’t just being put on the roadmap because somebody asked for it to be on the roadmap, which frankly is how a lot of that stuff gets on your timeline roadmaps.

And we also know that 17% Of projects run the risk of failing so badly that they threaten the existence of the company. So let’s not put the business out of business. Let’s make sure that we’re focused on solving the right problems in the right order and tying our problems, our strategic steps the problems we’re trying to solve back to strategic goals for the business and not wasting any time, not risking the business by building projects so badly that it takes down the whole company.

So with that, I recommend that you wrap up. This is why we’ve got a a slide deck here for you to use. You wrap up and then ask questions, right? Get people’s feedback. Product management process, a roadmapping process is something that you can build and then you can iterate on. This is why we have things like in ProdPad the now next later columns can be renamed.

It’s not a dogmatic approach. It doesn’t say you have to put this on the roadmap in a certain way. You can use it in a very flexible way and take this feedback from your team. Figure out what works for you. If you need to do Q1, Q2, Q3 or some variation of that to get people on board, do that. But take this time to ask questions and get people on board with it.

So this Grab a screenshot of this, if you like, this is a course that you can take. We’ve written this course that outlines what a NowNextLater roadmap is, what are the benefits in a lot more detail than what we’ve covered today, and then practical steps to transition from your timeline roadmap to your NowNextLater roadmap.

So take this course and prepare yourself with. This learning so that when your team is asking questions, you’re prepared. Lesson four is all about convincing your stakeholders, right? Getting those tricky stakeholders on board. We have shared this deck with you as well. So grab a screenshot of this page too.

This deck is basically the same deck that I was just showing you a minute ago. But it has notes in this, in the Speaker section that you can use to talk your team through and get them on board. It’s completely editable, so take out the parts that don’t work for you, add in parts that you think will work for your particular context.

But this is a tool that you can use to get your team on board. Lauren’s just asked as to whether we’re going to be sharing this with the recording. Yes, absolutely. So you’re all going to get a copy of this. Feel free to share it with your teams, share it with your fellow product people, share it around, make use of it.

We want to just help people get away from timeline roadmaps and move them to NowNix later. aNd on that note, I want to invite questions. 

[00:49:44] Megan Saker: That was great, Jenna. Thank you very much. We’ve actually got a lot of 

[00:49:47] Janna Bastow: questions. All right, let’s tackle them. 

[00:49:50] Megan Saker: In fact, Ryan says it feels like we need an after party.

There’s so many questions to come in. So listen, we’ve only got five minutes. We might not get to all these questions. If we don’t, I’ll collect the questions, extract some answers from Jenna’s head and maybe include those in the email afterwards. Okay. So where shall 

[00:50:08] Janna Bastow: we start? Um, there’s so Ryan asked, do we have any good visuals that show how attempting to the team make more at the same time causes them to slow down?

I have seen something like this, so I don’t have one in this deck but I can definitely point you to something that I think might be helpful. Or if not, I can scratch it out. I’ve done it, that same sort of thing on a piece of paper before and showed it to people to make that case. So really what you’re looking for is something to.

Really nail home that point that having people work on multiple things at the same time actually makes them slower. And that is a truism, right? What often happens with the timeline roadmap is that they end up trying to tackle a whole bunch of different things and they don’t actually move faster.

And this was an interesting 

[00:50:59] Megan Saker: question, Janna. How would you respond to the claim that it won’t work for B2B software because enterprise customers require reliable time and feature based roadmaps or they won’t buy 

[00:51:11] Janna Bastow: in? So I’d actually push back on that because most of the time enterprise customers don’t require that, right?

Enterprise customers, just like any other customers, buying the product that you have today. If you’re not able to sell that product as it is today, either the product isn’t good enough, And, shouldn’t be out on the market with a big sales team trying to sell it because it’s not ready. Or you’re selling to the wrong types of customers.

Enterprise customers like to throw their weight around. They like to say, hey, we’re so big that you should go build this one thing. But what you should be doing is turning that around and saying, that’s good feedback. And we’re going to take that on board. But focus on building the thing that’s best for the wider market and is going to get you more.

Of the right types of customers, whether those are enterprise or not. So if you’ve got like a whole bunch of enterprise customers asking for the same thing, you might want to prioritize that, right? You’re moving something up in the roadmap. But each time you take a custom piece of work and you say this enterprise customer wants to buy a product, but it needs this one custom thing that no one else is ever going to use again, that is work that you’re going to spend for that month or several months building that thing that you won’t be able to spend doing.

Discovery work and experimentation led work that’s going to drive the product to the right types of customers in the future. If you’re just constantly building these custom pieces of work that don’t fit with your product roadmap, you’re going to end up with a Frankenstein of a product that can’t really be sold by to anybody and can’t be supported well either.

So it’s really important to actually think about whether these things are worth doing or not, and oftentimes teams who are in the habit of doing that aren’t spending enough time finding the right customers, that ICP were stuck in that agency trap, right? What they’re really doing is they are selling off pieces of their time in order to get small bits of cash or sometimes large bits of cash.

But they’ve got to be and I’ve got a whole talk that I can share on this, the agency trap, you’ve got to make sure that you’re not falling into this agency trap and building stuff just because someone said to jump, right? So you’ve got to find that line. 

[00:53:10] Megan Saker: Janna, we had, A couple of people wanting to know your thoughts on jobs to be done. And that’s sitting as part of the now, next, later. 

[00:53:18] Janna Bastow: Yeah, absolutely. So jobs to be done worked really well with the now, next, later. Basically it aligns with the problems to be solved, right? If you’re saying that there’s a whole bunch of customers who want to have who want to solve for this particular job and your product doesn’t do that now, then the problem to solve is well to.

Allow for people to solve that problem, to do that job. And so that becomes the placeholder on your roadmap. And within there, you might have a bunch of different experiments or things that you can do to help them get to that point to be able to solve that particular job. So jobs to be done is a really good way of thinking about things.

Cause it aligns your customer problems with your business problems. 

[00:53:57] Megan Saker: And this, we’ve got Kayla and Catherine are both experiencing the same problem. How do you set limits on what classifies as now? I have stakeholders that try to push a lot of items into the now when we simply don’t have the resources to tackle every item in the now 

[00:54:12] Janna Bastow: column.

Yeah. Everything is now, nothing is now, right? Exactly. There’s a couple of things you can do. Treat it very much like a Kanban board with work in progress limits. In ProdPad, you can see how many initiatives and how many ideas you have in each column. And if you have only one team working on stuff, you probably shouldn’t have 10 different, um, now things.

Cause are you actually working on that many right now? Or actually, are they just trying to make them look like they’re happening closer by not putting them in the next. So use that forcing function. What are you actually working on right now? What is in active discovery and active delivery? That’s keeping your team busy right now.

Everything else put into the next and prioritize in there. The other thing is trying not to go too granular. Some people break their problems into really granular, little tiny problems, and they’ll have 20 different problems. And actually, if you took a step back, take a step back, you’d realize this is one problem area, and this is another problem area, group them together and tackle them.

And, as they move into your now column, you can break them down into more detail. But try not to have. hugely granular roadmap that becomes a pain in the butt to read. Ideally, your roadmap shouldn’t be any more than what fits on a screen or two, maybe a scroll but not a big scroll. You want something that if you printed it out, it fits within a printed page or two.

So you can hand it to somebody and they can read it. You don’t want an overwhelming roadmap with all the things. It’s not a replacement for your backlog. Otherwise it doesn’t actually tell people what your strategy is.

[00:55:39] Megan Saker: We are now out of time. We still have a whole bunch of questions here that we haven’t answered.

So I think the best thing we’ll do is, like I say, I will collate them all and we will write out the answers and make sure you can all see what was asked and indeed Jenna’s reply to that. Thank you very much, Janna. That was great. Like I say we will email round both the recording and the course and the the slide deck so you can take that away and use that with your stakeholders.

So best of luck making the move to Now Next Later and do let us know how you get on and if you want any more help. 

[00:56:21] Janna Bastow: Yep, absolutely. So everybody’s looking to make this transition. Get in touch. Let us know how you get on with it. Let us know who your tricky stakeholder is, and we’ll be happy to help you through, provide any guidance on that.

We’ve probably written something for it. And as Megan said, that we are going to take your questions and make sure that we we get those answers out for you because this is a an area that is fraught with contention. So let’s help you get through it. Good luck with everything, grab that presentation, and we’ll see you on the flip side when you’ve got your NowNext later.

Good luck everyone! And bye for now.

[00:00:00] Kirsty Kearney-Greig: Thank first of all, thank you everyone for joining us today. 

 I’m Kirsty I’m head of product here at prop. And Liz is our chief commercial officer but comes from a long tail of product and PM experience.

So, knows what it’s like. So our webinar I series is all about providing content, learning and sharing around interesting topics we think you guys will care about. And today Liz and I will be talking you through. How to find the perfect fit between your roadmap and your product backlog.

One of the knowable questions as always this will be recorded and the slides will be made available afterwards on our website where you can also find loads of past recordings of really great content as well. So make sure you check that out. I think that’s it for me on the kind of housekeeping.

So I will pass over to list, introduce health properly and kickstart the webinar. 

[00:00:47] Liz Love: Yeah. Thanks for that Kirsty. So yeah, I say quick quick intro from me. I’ve been in prodpad for about five years now, so I suppose I’ve gone a little bit over to the dark side and more into the commercial side of things, but my history is in product.

I’ve worked in products since about 2006 as product manager, product director, I’ve worked in large corporate environments. I’ve worked in startups, worked in sort of middle size companies worked as the first product manager worked as part of a larger team. And on a day to day basis, I speak to product managers, all over the world and hear all sorts of problems and all sorts of questions.

Now, because of that one of the topics that I’ve wanted to talk about for a while is this one that we’re gonna cover today. When I think back to my days as a product manager I knew I was responsible for a backlog. I knew I was responsible for a roadmap, but I didn’t always understand the difference between the two or know how to explain the difference between the two and how to use them in different scenarios.

So in this webinar, what I’m hoping I can do is explain the difference between those two very important product management concepts. And also think about when to use each of them in sort of day to day life. Now. I suspect if you’re here, you are the kind of person who spends time reading and watching and listening to all these different thought leadership materials and content that’s out there.

And I dunno if you’ve noticed that they lean very heavily on the strategy side of the job. It’s almost a sin to be seen as being a tactical person. If you’re a product manager, you should be strategic. And we can see that when you look at some of the things that you see on, like Twitter and LinkedIn and medium, there is so much content out there about defining product strategy.

Now that’s great. That’s really helpful, but I dunno about you. While I know it’s important to have a good strategy in place. I also know that the life of a product manager is more than that. Now it’s ideal. If you can stay away from product. Project delivery. Yes. But at the same time, on a day to day basis, you are gonna be, in the weeds and looking at tactics and sometimes doing more of that than you’d like to sometimes you become much more tactical than you’d like to be.

Sometimes you really get caught out firefighting and looking at bugs with people or being asked to look at bugs and asked to ask questions and be the product expert. And you probably see. These kinds of things happening in your day to day job all the time, you’ll be answering emails, going to meetings resolving conflicts between people, settling politics, getting buyed from stakeholders, reacting to changes.

Can you just test this? Can you do that? Can you answer this question? A product manager can get pulled from pillar to post. Now some of the work that we do as product managers can be useful when it comes to doing things like spending time, talking to customers to learn react writing user stories looking at competitors and so on, it’s all tactical work it’s work that has to be done.

It’s part of your arsenal of tactics that you need to do to get towards the point of launch. But sometimes, it’s, it feels like you’re doing some unnecessary stuff now. Just wanna kind of pause at this point and talk about the definitions that I like to use around strategy and tactics.

For me, the strategy is the list of problems that you’re wanting to solve. It’s a way of defining what your return on investment is likely to be. And it’s a way of and it’s something that you need to link back to the goals that you have in your business. We don’t always just spend all our time thinking and documenting plans.

We also have to execute on those plans. And some of that still fits much more tactical. So for example, here, I’ve talked about doing problem discovery, validating solutions, measuring success. It’s not coding, it’s not doing the work of delivering a product, but it’s doing the work that’s required to get yourself from strategy to something where you can actually launch.

Now, what I’d like to do at this point is maybe run a bit of a poll with you folks here and see if I can find out from you how much time you spend on strategy versus tactics. Let me just see if I can do that. No, I can’t, I’m gonna relaunch it. There we go. Okay. So hopefully we can see a poll on the screen right now.

And I’d really like to get a feel from the people on the call. And we’ve got sort of 70, 80 people on the call at the moment as to how much time you spend being tactical versus being strategic. And it’s really interesting. I’m watching the answers come in here. And I think we’re kind of settling out actually.

Now we’re just getting a few more. And it’s funny that there’s so much that we hear from day to day in the Twitter world, the LinkedIn world, the medium world about, you should be more strategic. You should be more strategic. And yet what we’re seeing here is what I thought we would see.

And in fact, End it now and see if we can share these results. Can you see those results now? Yeah, it looks like we’ve got, we have got some people saying that they’re spending time, mostly on strategy. We’ve got some people saying 50 50, but look at that 62% of our folks here are saying they’re spending most of their time on tactics.

And I think we’re almost taught that’s not necessarily a good thing. That product managers are too tactical, and maybe I’m gonna help you feel a bit more comfortable with the fact that you’re spending so much time on tactics, because I do think that. Different maybe differently to what we are hearing from, the Twitter world and the LinkedIn world.

And so on that, it’s not always a bad thing to be tactical. Now, this is where I start to change the definition up a little bit and think about. Roadmaps and backlogs. So I think it’s unreasonable to expect a product manager to be purely strategic. And so it’s lovely to see that there’s this mix of people who are sort of strategic and tactical, but there’s definitely a lean towards a leaning towards having strategy in your arsenal.

I don’t think product managers can spend all their time thinking and documenting their plans as much as that’s really useful stuff. When we wanna have those plans, product managers are great at helping things to move along, to get towards the point of launch. And again, I’m not talking about project delivery.

I’m talking about executing on a strategy. Helping stakeholders to understand what’s going on using the roadmap to identify what these problems to solve are and how solving those problems will give us a return on investment linking strategy, back to goals, but more importantly, taking that roadmap and executing on it, doing the problem discovery that’s necessary, validating the solutions that are in the backlog and measuring the success of what’s been done.

As I’ve got I have to have a meme. I’m sorry. I have to have a meme in every one of my presentations. It’s all very well defining a roadmap, but at the end of the day, If you don’t execute on that roadmap, if you it’s just as bad as creating the wrong roadmap, really, unless you are actually taking a problem and solving it and achieving outcomes, then your roadmap is really just a piece of paper or an image on a screen.

It’s not something that’s actually helping you to achieve your goals. And in order to do that, we do need to have tactics as well. I mean, I think we do wanna get the balance right between the two. We do want to have that balance between strategy and tactics. And sometimes that means you do, you might feel you’re doing more tactical stuff than you are strategic.

And sometimes you might feel like you’re doing more strategic than tactical, but finding the right balance between what works for you as a product manager and what the business needs is something that’s really important. Now what I’m hoping I can do as we go through the rest of these slides today is give you a bit of an insight.

And particularly when we come to talk to Kirsty and look how we work at propa or how she works at pro pad and get that balance right. And give you some tips on how to do that. Now, moving on from this, if we start to think about the strategic side and the tactical side, let’s start with the roadmap first.

Okay. Now I suspect some of you may be familiar with pro already. Some of you may be not, but this is what we talk about at ProdPad as a great way, or an ideal way to structure your roadmap. When you think about the roadmap being strategy, think about focusing your roadmap on not on features to build.

But problems to solve and the order in which you plan to solve these problems think about your roadmap and I’m gonna use Jan’s words here. These are Jan’s words, not mine, but your roadmap is a prototype for your strategy. It’s a way of taking the strategy, the plans that you have the direction that you wanna move in, in the ordering, what, in which you wanna move, it’s a way of taking that information and sharing it in a form.

That’s easy for you to understand, but most importantly, for your stakeholders to understand not only that, not, it’s not just about what problems you’re hoping to solve, but about the outcomes that you’re hoping to. Now by sharing your plans in this way, you’ll increase transparency into those plans because they’re just easier to understand.

So it’s easier for people to consume them. And not only that you’ll open the door for people to tell you what they think, because once they understand it, they’re likely to have opinions on it. And then they’re gonna want to tell you those opinions and let’s face it as product managers. We want to know what those opinions are, so that we can start to look for themes and sort of, insights in the stuff that’s coming.

So having a roadmap that looks like this means that you’ll be able to align everybody around a common plan that you are iterating on and improving as you get more and more feedback, it means that you’re gonna increase focus in terms of what, again, what problems you wanna solve, what outcomes you’re trying to achieve.

And it also means that you are gonna ensure everybody’s working on solving the right problem. So, as I say, you may or may not be familiar with propa in the way that we talk about roadmaps, but this is definitely something that’s maybe a little bit different to what you’ve come across in some of your, some of your other investigations into roadmap, but it’s something that we find works well for us.

And I can tell you personally, as an X PM, it worked well for me. Now there’s another way of looking at it. It’s not just about what problems that you want to solve. It’s about putting them down on the page. In a way that you are making it clear to people that there are some things you know about really well, some things that you’re still learning about and some things that you just know nothing about at all.

And it’s about identifying the fact that there are different levels of granularity, depending on how far you are through the process of understanding a problem. Generally, what we like to see when we’re talking to customers about their roadmaps and the way that we work ourselves is that something will start out in that later column as just really high level, really broad, really fuzzy, really, almost aspirational.

This is something we know we want to do. But it’s so far out in time, or it’s so far out in terms of how much we understand that we just don’t know what we’re doing with it yet. And so it’s something that we need to learn more about. And as we learn more about it, we’ll start to break it down into things that are easier to understand and easier to research.

And that can be turned into research projects, discovery projects in their own li in their own rights. And then they kind of end up in that next column where we are actively doing discovery, where we know these are things we wanna learn more about by the time you have learned enough about them, that they become something that you can execute on.

They’re landing this now column. They turn into things that are really specific that are well specified, less flexible because you’ve done the work you need to do to understand them. And they tend to be. Defined enough that you can hand them over to your development team and have them start working on these things.

So we are showing here that there’s a whole load of work that needs to be done before you develop. And we’re highlighting the fact that discovery’s important. And again, with this now next later, or this sort of lean structure, it means that we’re able to show direction and start conversations without necessarily getting caught upon on, delivery dates and all the rest of that stuff that we’ll love to hate to talk about.

Now in terms of how you might lay that out. Think about on your roadmap, having multiple initiatives that are really clearly linked back to the objectives that you are trying to achieve, or the outcomes you’re trying to achieve. Example here, we’re trying to get user growth. The most important thing for our product is to get user growth.

It could be that you’re trying to reduce churn, or you’re trying to increase in a particular market segment or whatever it might be that you have an overall outcome you’re trying to achieve. And we can see that there is a problem that we can solve for our market. That’s gonna help us to achieve that outcome.

So I’m not getting into features at this point. I’m not getting into the specific specifics of what’s gonna be done, but I’m focusing on outcomes and problems to solve very much an outcome oriented approach. Very much showing away from that feature factory approach and very much opening the door for questions about what we want to.

Very strategic. In fact, you might say, I think it’s really a good idea to think about your roadmap. Not as a commitment, not as a list of features to build, because that implies that everything. And if we knew everything, we wouldn’t need product managers, let’s face it. Your roadmap is a communication tool.

It’s a way of starting conversations. It’s a way of making sure that you have all the facts before you go ahead and commit to something and commit to the kind of stuff that you would put into a release plan. So thinking about all of these, our roadmap is very strategic. It’s very much focused on problems to solve.

a, It’s a communication piece. It’s something that you are using to have conversations with people. But when we look at the tactical side of things, this is where we have our backlog. Now it’s different to the roadmap. Our backlog is a list of potential things that we might wanna execute where your roadmap focuses on the problems to solve and the potential value of solving them.

Your backlog is a list of all the things you could do, but like any list it’s kind of really amorphous, it’s made up of big things, little things. I tend to think about rocks and pebbles and sand, all different sizes, all different values. Some of it’s gonna be really well defined. Some of it’s gonna be really fuzzy.

Some of it’ll be rough concepts. Some of it might just be experiments that you wanna run to learn more stuff, but it’s just kind of this big lump amorphous lump of stuff. I found this Oxford English dictionary. Definition of backlog an accumulation of uncompleted work or matters needing to be dealt with.

That sounds like scary, to be honest with you. It’s it’s got the words that are similar words are things like log jam, pile, heat, mounting, excess, again, scary stuff that you think, oh, I’m never gonna get through this backlog. It’s the stuff of nightmares for product managers.

What we need to be able to do is filter that backlog. We need to be able to find out what’s worth doing now. We all know as product managers, that prioritization is a major part of our. And it’s really difficult. It’s really hard. There are frameworks out there to help us. We think we’ve got ice, we’ve got rice, we’ve got MoCo, we’ve got weighted.

Shortt short, shortest job. First, all these acronyms. So many of them, it’s all confusing. Just learning them, let alone doing the prioritization itself. Now all of them require you to make a comparison of all of your potential ideas to each other and score them and keep those scores up to date. I mean, it’s a crazy amount of work.

We know product managers don’t have enough time to do everything they need to do. And yet we are supposed to check every single idea in our backlog and work out whether it’s more important than the one next to it. It’s like, yeah, not the best plan. I tend to think about that backlog in terms of what’s relevant for my strategy.

And what’s not think about where the idea is in the process. Of being understood. Like there’s no point trying to prioritize ideas where you’ve not even reviewed it yet or where you haven’t done enough discovery to understand it. There’s no point asking development to do estimates on ideas to help you with your, return on investment stuff or your waited short job first or all that stuff.

There’s no part asking development to do that when we don’t really know if the idea’s gonna help us achieve our goals yet, or if it’s not well specked out enough for them to be able to do it. And this is where we can get more tactical with our backlog. We can start to break the back the backlog into stages and think about that kind of build, measure, learn cycle.

Or I sometimes think it would be better if it was learn, build, measure but there you go, you know where I’m coming from with this, I can see Kirsty nodding. Yeah. She agrees. So this is where I’d like to take that big backlog that we’ve got and turn it into. Well, you’ll be able to see from the space here, there’s three, three pieces.

I like, so first of all, look at our discovery backlog. Now our discovery backlog is all the stuff that is just really amorphous various levels of detail, really hard to prioritize really just too big to actually get through. But it’s the kind of stuff where you want to look through and identify the things that are gonna be linked to your roadmap.

I would say, start take anything that you think is in your discovery backlog. The first thing to do is see if any of it is relevant to the problems on your roadmap and make sure that it’s, you almost link them to the initiatives that you have. And if it’s not linked to an initiative, it’s not, if it’s not something that’s gonna help you achieve something on your roadmap, don’t even bother spending time on it because it’s almost just a waste of time.

The next stage after you’ve taken the ideas that are linked to your backlog and done that discovery work that you need to do is to think about turning them or adding them to your development backlog. Now, this is the stuff that you’re gonna be keeping, honestly, in JIRA or Trello or any of those kinds of places.

This is where you’re taking your ideas. You’ve done discovery around and you’ve given them to your development team, but you need to give them stuff that’s useful to them. I’ve been a product manager, who’s handed over an idea to a developer. Who’s like, honestly laughed at me because he’s gonna, I can’t develop this.

There’s no in not enough information in here for me to be able to do it. Developers need and justifiably. Yeah, absolutely. Should have a backlog that is tidy is well organized is detailed specs is well prioritized and is achievable for them in the short term. So don’t give them what is effectively a discovery backlog, which is just this amorphous list of stuff.

Only give your developers the ideas that you have looked at done discovery around, tidy up written specs out and are, really the next few sprints worth of work. Now I kind of want to introduce a third backlog and that’s the outcome backlog. Now these are ideas. Or epics or tickets or whatever you wanna call them that are code complete.

And you think, well, why on earth? Would you put code complete ideas into a backlog? These are things which have been done and we’ve invested time, effort, money, resources into these. We’ve probably started building up to a launch on these. So our stakeholders around the product team are working on these.

We’re creating websites sales artifacts, marketing materials, all sorts of stuff around these things. We need to make sure that we spent the time wisely. And we need to be able to learn from what’s happened with the things that we’ve spent our time and money on. So these are things that are code complete that are released in our product, or maybe in beta, so that we’re just learning about them before we go for that wider release.

But we are measuring to see if they really did what they should have done. Now, if we did our work right back at the discovery phase and ruled things out that weren’t going to meet the needs that we had, hopefully they won’t get that far, but if they have got all the way through to the outcome stage, let’s measure them and let’s make sure that they really did work.

Now, we’ve talked a little bit about the backlog here. And now I am curious as to how you would would organize your own backlog. And I, and so I have another poll for you. What I’d like to know is how do you organize your backlog and how do you split your out, or if you just got this big one messy list of stuff that is just all sorts of stuff all over the place, you never know what’s gonna happen with it.

Most of you probably are splitting between discovery and development, which is brilliant. And I think we’re gonna end that just there and share those results. Hopefully you can see those results on your. So it looks like, yeah, we’ve got quite a few folks on the call. Who’ve got one big messy list. I’m really hopeful that means that you can that you can take some of the stuff that I’ve talked about today and, that will help you to manage that list.

 I’m sure you development teams are a lot happier that you don’t just give them a massive stuff in JIRA to tackle. We did have a couple of people spitting out into outcome backlogs. That’s brilliant to say. I’d love to see more of that.

 I’m now gonna be passing things over to Kirsty’s her turn to chat. Kirsty’s ahead of product at ProdPad. So as much as I’m sitting, telling you all of this wonderful stuff that I’ve learned over the years, the person in our team, or one of the people in our team, who’s really putting this into practice at the moment is you Kirsty. 

[00:22:49] Kirsty Kearney-Greig: This will be based on how we work at ProdPad and based on our cadence of release and how we do product and development. But hopefully some of it can be useful to you guys that have obviously different cadences and stuff, but yeah. 

[00:23:02] Liz Love: So, from when we were chatting, over the last few weeks, and when we start to put some of these slides together, what I discovered from you was really this kind of cadence based approach, which is very tactical, but helps you to execute on the strategy that you have and even to build the strategy that you’ve got And we start when we talked about it, you said you split this out really between sort of yearly stuff or yearly or quarterly stuff that you do, monthly stuff that you do every week or two and daily stuff.

And really, as you become more frequent in the work that you’re doing, you become more tactical. And from what I could say, there were certainly some things that you did yearly or quarterly that were very much more strategic. Do you wanna talk a little bit about those? 

[00:23:43] Kirsty Kearney-Greig: At ProdPad we worked to the, OKR model say we set annual a OKRs which are companywide, but we also set quarterly, a OKRs as well that are more team or product specific.

So one of the things that I do on a kind of quarterly basis as well as slightly more frequently is kind of. The roadmap of Ji, so to speak. So I think Liz put it really well earlier and that the roadmap is a kind of communication and a prototype for your strategy. And that’s very much how we utilize it here.

So once we’ve set our quarterly objectives we will have a big session as a team to have a look at what we’ve got on the roadmap and any new initiatives or ideas that we think need adding to help us move the needle on those things and rejig the roadmap accordingly to make sure we’ve got the things that are gonna best help us achieve those objectives and key results.

So the big roadmap prioritization happens on a quarterly basis. But it’s something that is monitored and updated on a more regular cadence. 

 Feel free to go have a look at it prodpad.com/our roadmap. So this is not only a communication tool for. The internal team to see what we’re up to and what types of problems we’re looking to solve, but for you guys that are our customers get to see it as well.

Which is quite insightful. I think for many of you, when you see what we’re kind of working on, what’s coming up, but also for potential new customers as well, to the types of problems we’re looking to solve. And if that aligns with the problems they have, when they’re looking for a tool like prepared as well.

So, find having a public version actually super useful, cause we get active feedback on it from people which is really nice as well and helps feed into what’s important. And what’s not as well. 

[00:25:25] Liz Love: And then we also, I mean, talking about working in that strategic way you are looking as well on a monthly basis, would you say at the success and how well things are working?

Yeah, definitely. 

[00:25:37] Kirsty Kearney-Greig: So for me, this is one of the most important pieces of Of being in product. And unfortunately it’s often a thing that gets left behind a lot of the time due to time pressures. But for every idea or initiative that we are looking to undertake, we always will set out target outcomes for what we’re looking to achieve by delivering that piece of work.

No matter if it’s a really small quick update to a button CTA, for example, versus a whole brand new feature. So once that’s live these kind of these ideas move into what Liz outlines our outcome backlog where they sit and move from dev back to us in product. We generally give things a kind of four week run in the wild.

And then we’ll check back in. And crucially share that back with the team as well. I think it’s really important for the team to understand the work they’ve shipped and the impact that’s had. Not just in the product and dev team, but in marketing and sales and the wider team as well.

And if things haven’t hit the target outcomes, that’s when they’ll loop back into potentially our discovery or our development backlog for the next iteration, it’s too often in the world that things are shipped and never touched again. So I think it’s really important to be checking back in seeing what you’ve moved and then kind of iterating 

[00:26:49] Liz Love: yeah, absolutely. So moving on from sort of what’s monthly, the stuff that you do every sort of week or two. Yeah. So we’ve got here. Things like prioritizing the dev backlog, reviewing new stuff and doing customer interviews. So. When you say you’re prioritizing the dev backlog, what are you really doing with that?

[00:27:06] Kirsty Kearney-Greig: Yeah. So as I said, this is obviously the cadence of this. It relates to our in dev cadence. So we work in two weekly sprints. So on a kind of two weekly basis, I’m. Prepping what we wanna put in the next sprint for dev. So it’s a matter of kind of looking what’s left over from the last cuz it’s very rare.

They finish everything as much as hard as they try. And then looking at all the things that are ready to roll from our side, from product side, that finish discovery validation, and we have good confidence that are gonna move the needle on things and pushing that over to dev. This is where the workflow comes into its own.

Within ProdPad, it’s a critical tool for me that allows me to do my job every day. So I have columns set out as you can see here. So I have a column ready to prioritize where basically anything sits. And then when it’s ready to roll, I can push it over to dev. We use Trello as you can probably see from the little leg there, luckily rather than JIRA.

So once we’ve pushed it to dev it syncs with Trello and that’s when it’s kind of in the hands of dev and they kind of move it through their side and then it obviously reflects back in ProdPad so I can keep an eye on what’s going on. But yeah, so it’s a mixture of new features. Existing work that’s carried over as well as obviously any new high prior bugs coming.

We are prioritizing around on a kind of two weekly basis. 

[00:28:23] Liz Love: Okay. So, you’ve kind of taken the broad brushstroke backlogs and you’ve start to break them down into these smaller ones. Yep. So that you’re almost pushing things through that workflow and you can tell for any one of these, what needs to happen with it next.

[00:28:35] Kirsty Kearney-Greig: Exactly. Yeah. And I think a lot of the things we’re talking about here and the cadences that I’ve put into place help me keep on top of all of this stuff. And allow me to have the time to do the deep work that often us product managers don’t have time to do, because we do get stuck in the firefighting and tactical all the time.

So these are some of the kind of mechanisms I’ve developed and timeframes to do things which still give me that space to, to do the discovery and the research and the strategy work that I also need to be doing on a day to day basis. 

[00:29:07] Liz Love: And you’ve also talked about triaging new ideas. And I can see here again, we’ve got a snapshot from our own pad.

Of course it’s all blurred. But this is some of the newer ideas we’ve got and the things that have been reviewed and ready to go through into that kind of discovery cycle. Yeah. What sort of things do you do when you’re doing tri and what are you looking for? 

[00:29:25] Kirsty Kearney-Greig: Triaging new ideas on a regular cadence, again, I think is super important for engagement with the rest of the team, not just for their ideas, but actually with ProdPad as a tool as well.

Because I think ProdPad works best when you’ve got the whole team invested in contributing to it. So I never want the team to feel like their ideas are just being like chucked into a black hole and no one’s ever looking at them and that often can be the case in a lot of places. So I make sure I mean, obviously there’s some weeks where I just don’t get time to do it, but I try my best to on a weekly basis come in and.

Review, any new ideas. The critical thing I’m looking at there when new ideas come in is whether it’s gonna help us meet our objectives and outcomes we’ve set for this quarter or the next couple of quarters. If it doesn’t, then I will archive and snneeze it because I like to keep our backlog.

Quite trim for a number of reasons, and I’m sure that’ll be a discussion we get into in a bit, but the really important thing there is, I always add a note to the idea creator as to why I’m not putting it through, into our backlog. So people understand the decision making and the rationale behind how we’re triaging.

So they’re encouraged to continue adding their great ideas. Cause often these ideas are coming from your team and they’ll have loads of great ones and you wanna encourage that as much as possible, but at the same time you can’t say yes to everything because you’d obviously never get anything done.

So, yeah, the biggest thing is it gonna help us meet the needle and the things that we care about essentially. And obviously there’s not enough information there for me to make that decision. Then they’ll go into a little mini discovery while chat to the person that’s added it. See if there’s any information we need to add and then I’ll make that decision basically.

[00:31:07] Liz Love: It’s interesting. So in this snapshot here, which is like a filtered version of all the ideas we have, we can see the sort of 70 there that have been reviewed at the moment. And when we look through some of the other screenshots, you’ll notice some the numbers are definitely lower. The further, over to the right, we get. 

[00:31:22] Kirsty Kearney-Greig: That’s the idea. So that it is, I mean, 70, I think is pretty trim for a backlog anyway, 

 As you, as we move through the discovery process you’ll notice from, is screenshots. The numbers reduce as they go through cuz we’re learning and throwing things out where we don’t think they’re gonna work or or otherwise 

[00:31:39] Liz Love: So it’s not quite such a scary backlog as you would’ve otherwise seen. Yeah. And also regular time on interviews. Yeah. 

[00:31:47] Kirsty Kearney-Greig: So again this actually is a big part of what I love to do. And my role here, I’m very much in the camp with our friend Thereza on continuous discovery. And I think it’s one of the things, again, that unfortunately, a lot of people just don’t find the time for.

But I. Personally, make sure I block have blocks in my calendar every week, which are dedicated to customer interview time and make sure that’s there for me to chat to potential customers, current customers, also customers that are leaving us as well. There’s so much learning and insight that we can take from those people.

If you’re just relying on those are actively submitting feedback. You’re only getting a really small proportion of your user base input into the product. So it’s really important to chat to those that wouldn’t necessarily actively come forward with feedback as well. So you’ve got a really nice threat of insight coming in.

That’s gonna help you improve and build the product. 

[00:32:42] Liz Love: And presumably then you’re pulling you using ProdPad itself to manage that. 

[00:32:46] Kirsty Kearney-Greig: Obviously the war notes will take out outside. But then we basically pull all the insight as feedback into ProdPad and that helps us build evidence for ideas, 

[00:32:55] Liz Love: And yeah, she said using feedback to validate those ideas. So is that something that you’d like you linking with ideas from your backlog? Are you linking the feedback? 

[00:33:06] Kirsty Kearney-Greig: Prioritization points, I guess, for when we are looking at ideas is how much evidence have we got of it as a problem?

Obviously quantity of feedback is one element in that, but actually the another really critical point for me is the frequency of that feedback. This is actually a feature we launched in IPRO pad at the end of last year actually, which I found so useful. Whereas I can see. How frequently that feedback’s come in.

So it may be that we have an idea with a hundred pieces of feedback come in. Back actually, when I look into it for the last six months we’ve not had anything. So that then kind of encourages me to ask why, and we think about the prioritization of that idea. So at that point, I’d do a bit of a dive into it and see if it’s still a problem for people.

And if not, then you can probably deprioritize. I mean, if there’s a hundred people have all churned, which is why you’re no longer getting feedback about it, that still means it’s a priority, right? Cuz it was a big enough concern that they probably aren’t using the product anymore. But for sometimes your customer base changes on a regular cadence depending obviously on the product.

So you need to be making sure that you’re not tied to really old ideas just because once in their life they receive the loads and laser of feedback. When actually you got quite a different user base now and their problems are different. So, Quantity, but also frequency of feedback coming in around certain problems, I think is really critical in the prioritization process.

[00:34:27] Liz Love: And then I think we’re starting to get a little bit more tactical now. Like we’ve started thinking about problems and being quite strategic and doing that. Not changing that too frequently, quarterly or so. We’ve looked at monthly stuff, weekly stuff on a really tactical day to day basis.

You’re really moving these ideas through Val discovery and validation and seeing that as the tactics you use to get things through today, is that right? 

[00:34:52] Kirsty Kearney-Greig: Yeah, exactly. This is where the workflow again is where we as a product team live specifically in those, I guess, four columns there that you can see as you can see the numbers here are much smaller than the reviewed column.

So we have the work split between us as a team, probably a couple of ideas at a time happening. And part of my job is to be going in seeing where things are at. Obviously there’s always questions on each of these for me to answer looking at recent designs, mockups, prototypes research outcomes, seeing what we’re learning and then deciding whether that idea has kind of proved its worth basically, and either validated or invalidated.

Which we hope to do as much as we validate other, otherwise the don’t think we’re asking the hard enough questions the different experiments that we’re running to see if we can move the needle on any of the metrics we care 

[00:35:42] Liz Love: about. Got you. No, that makes sense. So, so we’ve really taken that, that big backlog of stuff from broken it right down into step by step and use that to organize the work that we’re doing.

Is that right? 

[00:35:55] Kirsty Kearney-Greig: Yeah, exactly. And I think part of that is, as I say, having a trim enough backlog to begin with I think it’s really important to empower. My team to decide what to work on. Like if you’ve got a trim enough backlog that, as a head of product is gonna help you hit all your target outcomes or things you think will help you target your, hit your target outcomes, then it’s up to the team to take and explore and discover on those things.

So by having a trim backlog they can go in and just pick things up and start running with it basically. And then seeing what happens if you’ve got a backlog of hundreds, 500,000 different things, that’s where you are really gonna kind of, struggle to prioritize what to do next, basically.

So that initial triage is really important for us. 

[00:36:39] Liz Love: So I think it’s probably a good time to sum up. We wanna make sure we’ve got a few minutes at the end for any questions that are still hanging around. I think there’s a few landing in that Q and a bucket that might be worth looking at think about roadmap as the piece that you’re working on.

That’s very strategic. It’s the thing that you are using to learn about strategy and to communicate strategy, start the conversations, communicate direction, but you know, don’t believe. Those rumors, you hear that product managers have to be just strategic. They can’t be tactical. There’s different kinds of being tactical.

And as a product manager, your backlog is something that’s pretty tactical. But you can get through it and manage it and give yourself enough time to do the right things you need to do by breaking that backlog up into those mini backlogs. First of all, those three strikes, let’s just think this is what we’ve gotta do discovery on.

This is what the dev team are working on. That we might got a release plan around, and this is the stuff that we’ve delivered that we’re going back and checking and learning about. But even those three buckets, particularly the discovery part, break that down into individual sections that represent the process that you have.

And. Having that regular cadence of working on those different mini backlogs in different ways will mean that everything’s always moving forward. Those tiny little steps, you’re not just suddenly looking at something and thinking, oh, this is a massive elephant that I’ve gotta try and con try and build.

Think about, well, how might I start with the toe or how might I start with the tail? Or what do I do about getting it to just right. You’re breaking it up into smaller things and constantly moving it forward. I can see Kirsty laughing at because I’ve made an elephant analogy. And I dunno why it did bring jump to mind.

[00:38:17] Kirsty Kearney-Greig: I think one of the important things as well is like, I think a lot of the time as product people where consistently, as you alluded to at the beginning, Liz pulled from pillar to post cause people have questions, et cetera. I’ve actually found like doing these regular cadences of activity means that our work is up to date and really visible for the whole team in

So actually means you have less of that because they have a place to go to answer those questions before they have to come to you, they go there and still can’t answer their questions. Then that’s something I need to work on. But definitely by doing these regular cadences and making sure as much as possible that our work is visible and up to date with where we’re at really helps the rest of the team know where things are as well.

So if sales have a call with a customer that’s talking about a specific problem they can look at and say, oh cool. Yeah, we’ve actually, that’s about to hit development for example which really helps them do their jobs better as well. 

[00:39:06] Liz Love: Yeah. And I can echo that obviously on a product person at heart, but working on the commercial side of the business now I find it so useful to, to really know what’s going on.

And it means that I’m talking to customers about what’s happening with the product that I know product have blessed. The product team have blessed rather than being in the dark and feeling like I need to make it up myself. So it just it just greases all those wheels and everything just works that little bit better.

Yeah. Nice. So that’s all we have today. We have got a few minutes left. I dunno if there are any questions from folks but a few. 

So I can see one here. How is the customer interview conducted? Is it in person via email or is it via chat 

[00:39:50] Kirsty Kearney-Greig: It really depends. We have depend. It depends how big the piece of work is versus so we kind of have a bit of a matrix actually. That we use that we define how much time we would spend on research versus the size of the piece we’re looking to do discovery on.

So sometimes we will jump on, obviously in person interviews right now of the last two and a half years, haven’t really been possible, but we’ll be doing zoom calls like this or meet or any other platform. A lot of the time when we’re doing bigger pieces of research, where we do kind of anything from half an hour to one hour custom interviews with people where we have a bunch of topics we discuss and kind of talk around.

But we can also do stuff via email as well. Or in chat, if you want to. Normally those things are more like survey based then chat per se, but support obviously chatting to customers. And feed that stuff back in, but from a product user perspective, it’s normally kind of video calls or kind of survey based for kind of larger numbers of customer.

[00:40:49] Liz Love: Okay. That’s interesting. There’s so many questions here and it’s interesting. Can you give a couple examples of target outcomes besides dollar outcomes that you think have been important or you think are important?

So what are some ways of measuring success recently that you’ve looked at 

[00:41:05] Kirsty Kearney-Greig: Obviously it’s purely dependent on what your product is and does let’s say happy to have a chat about that if you went separately, but I think. One of the big things always is conversion, obviously conversion leads to dollars.

So that’s a really interesting one. We look at specific groups of interactions, a lot that we know leads to good adoption. So I think a lot of the time people can get really caught up on like weekly active users or daily active users, which obviously are good indications of if people are using your product, but often you’ll have like specific interactions in your product that, leads to good behavior or good adoption practices or good conversion.

And I say having outcomes around those really useful, cause it really targets the team on specific things they can do to improve. And all of those things have long tail to lead to the end dollar, obviously. But if you’re just focusing on money, It’s a very broad topic. So I’d say get a little bit more granular with the things that you know, can lead to dollars.

And there’s loads of great tools you can use to do that kind of investigation as well. 

[00:42:09] Liz Love: There’s a question here from Tim and I might take this one. Isn’t the wording backlog in outcome backlog, a little misleading? What would be the activities to be done to work on that backlog now? 

[00:42:21] Kirsty Kearney-Greig: It depends on if you look at Liz’s definition of backlog, I can’t remember what it was a list of.

Work that needs to be done. 

Then it is a backlog, right? Like I’ve got a bunch of ideas or list of ideas they’re sitting there that have work to be done on for me to figure out if they’ve here our target outcomes. So I think backlog works for it. So 

[00:42:42] Liz Love: going and checking things like product analytics.

You are maybe looking at what your customers have fed back to you about the particular. So maybe we’ve released a feature and it’s sat in that outcome backlog because you’re waiting to see what feedback you get from users that you’ve gotta go and investigate and learn about to see if it was successful.

[00:43:00] Kirsty Kearney-Greig: So it’s a mix for me, looking at qualitative feedback, that’s come in around that feature going in and checking quantitative metrics as well, watching any flows. We have people using the feature as well. And amalgamating all of that into some kind of. Report as to whether it, we hit the outcomes we did.

[00:43:19] Liz Love: So yeah, absolutely. So this is an interesting one and now I know we have a blog on this, so, it’s come from Brody. I’m gonna make sure that I forward this onto Brody after presuming that we’ve got email address. If not, I will tell you, just go to the pro pad blog and look for a blog about messy backlog.

Roddy says, how would you go about inheriting a giant backlog? Think about 2000 epics bug stories as part of a new role. I’ve done this by the way. It’s, I’ve done this as well. So yeah, I don’t think it’s right to just archive the lot and start fresh. Why not. But it’s unachievable to review work in progress as well as filter that giant messy list of a backlog.

So I know that you’ve well, I know even when you started with us and we were pretty good, but you still had a good clean out didn’t you? 

[00:44:04] Kirsty Kearney-Greig: I had a really good clean out. Yeah. I think I’d ask the question. Why not to archive a lot and start fresh. If you look through and think that a lot of it is just old and not applicable anymore, I kind of have a rule of thumb.

Like if it’s important, it comes back archiving doesn’t mean deleting archiving means moving to another kind of holding place, which you can bring back to life when you wish. One of the things I looked at was like how long those things have been sitting there a bit ties back to the kind of frequency thing I was saying earlier say, yeah, kind of a rule of thumb.

If it’s been sitting there for it’s up to you to determine your timeframe for over a year, No, one’s cared about it enough in the last year to do anything about it. So, so I’d probably archive it and see if it comes back around again. Obviously, unless you’re still getting lots of regular feedback about it and it’s just that it’s been missed and the team haven’t prioritized it well enough.

So I’d kind of look at those two elements, like the age of the idea or the story or the bug versus the number of feedbacks you are getting about it. And then obviously alongside that, whether it’s something that will hit your OKRs, but if you hit negative, one of those, I’d just get rid of it. To be honest, not get rid of it entirely, archive it until someone cares about it, enough for it to come back, because otherwise you’re never gonna make progress because you’re always gonna have new stuff being added to it and see in 2000 we’ll become 2,500 and that will become 3000 and you’ll have this ever list.

And that stuff that you probably should have got rid of is still gonna be there getting older and nothing happening 

[00:45:35] Liz Love: So I’ve got a question from Adele. You mentioned three backlogs. I might take this one book. Maybe we do it between us. Do you have any recommendations on how to handle development focused activities like technical tasks that don’t directly relate to the initiatives?

Do they belong in the development backlog or somewhere else? 

I do have opinions on this and that’s that they really do belong in the development backlog and they belong in JIRA. Again, this is something we’ve got a blog on the an hour blog around about again, it’s the messy backlog side of things like bugs don’t belong in, in your product management or your, in your discovery backlog.

Technical tickets are almost. There are sort of there’s things I would put in as tickets, I would put them in J or tr whereas almost subtasks, we’re trying to achieve an outcome here. This outcome, we have defined a set of steps for how we might achieve it. We’ve defined it well enough for development to pick it up.

But what they do with it from that point onwards is sort of it’s part of the execution process. So definitely I’d make sure they belong in, in the development backlog, technical tickets, spikes, all that kind of stuff, that’s where they belong. 

[00:46:43] Kirsty Kearney-Greig: I think Liz said earlier that one of the things around triaging ideas, like if they, if it doesn’t link to an initiative, shouldn’t be on the roadmap.

I have a slight different opinion on that. So I do think there can be time for like smaller pieces that can be unprepared or whatever tool you’re using that you are moving through discovery that aren’t linked to your roadmap. And generally they’re smaller little pieces that you are kind of.

Pre like experiment to test something that’s sitting in later or candidates that you wanna get a good feel on and that kind of stuff you can move through individually. But Mo I’d say most of the development focused activities. Yeah. For sure. Just should be in your tool of choice. There’s no point clouding unless they need discovery on as well.

 There’s some things we do that need like dev discovery. Those, we then may have I input pad for kind of visibility, cuz it’s a kind of tag team between dev and design. But for purely development focus tasks that lives for us in Trello or the JIRA. 

[00:47:39] Liz Love: Now I’ve got we, we right on the end of time here I’m gonna kind of cheat a little bit.

We’ve got two questions that I did wanna hit, but not in massive detail. One of them which is a webinar in itself is how do you overcome the request for dates on the roadmap? yeah, we haven’t got time to get into it right now. However, we just literally published a couple of days ago, a blog on five ways to explain to your stakeholders why timeline driven roadmaps are a bad idea.

So please check out that blog. And maybe I’ll speak to our folks and see if we can include that in some, the materials we send out after this webinar. And on a similar note this Adele has said, do you have any tips for encouraging sales and marketing departments to get involved in the OKR creation process?

And it’s kind of similar it’s. One of the big keys for me in helping other people understand about product and the product process is exposing them to the value of doing so. Like, if you get involved in this, if you collaborate with us, you are gonna see what’s going on. You’ll find it easier to talk to your customers.

You’ll have the outcomes that you need in order to be able to sell more. But I need you to be involved in this process so that I understand the kind of things that are important. So there’s definitely no shortcuts on any of this stuff. It is about engaging. Your folks around you and getting them to see what the value is of working with product and understanding that they have needs, and almost see doing research with your colleagues to understand what they need from product to be successful.

Having that two way street is certainly something that myself and Kirsty have got me on the commercial side, Kirsty on the product side, we speak, so frequently I’m surprised she still speaks me to be honest sometimes. But I have such a clear understanding of what’s going on. I know it’s in my interest to be involved with product.

So I definitely recommend just that, that collaboration and having your ears open to listen to what those folks need from you as well as what you need from. 

[00:49:30] Kirsty Kearney-Greig: For sure. And like, we have a really open process here. Like, so whenever we are kicking off discovery on a new problem to be solved, we bring in as many people as relevant and can to, to that.

So we’ll pull in dev QA customer success, et cetera, because we get opinions from all different areas of the business in terms of like how we potentially solve that. So they’re invested really early on as well, which I think really helps as well. 

 But yes, essentially we do keep them up to date on what’s going on in involve them in testing throughout the process for things that will hopefully solve the problem that they have as well.

[00:50:03] Liz Love: Well, thank you everybody for joining us, it was really good to see such loads of engagement, loads of questions, hopefully lots of stuff that you can take away and see is actionable to make things easier for yourself.

We know that being a product manager’s hard. Come to us if you’ve got questions and I’m sure that you’ll hear from us again soon. Thanks 

Watch more of our Product Expert webinars