Product Management Webinar: Roadmaps and Backlogs

[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