[On-demand]Product Management Webinar: How to Make Hard Product Decisions

Janna Bastow [00:00:00] Hello everybody. Welcome. Come on in. Hi everybody. Come on in. Get settled in, find your way over to the chat and say hello. Sorry we’re starting a few minutes late. I got in a fight with Zoom as you know, that we all often do. But I think I’ve got it all set up. Jump into the chat, let me know that the chat is working for you.

Let me know that you can see my screen. Everything look good. I wanna make sure that where all systems go before we kick off and we’re going to be kicking off in just a few minutes. Hi, Jacob. Thank you for letting us know that the the chat’s working, Matt as well. Really appreciate that.

Alright, so systems are go we zoom is forgiven and we’re gonna kick off in just a moment once everybody gets settled in. But for those you’ve been here before you know the drill, let us know where you’re calling in from. Anybody new here, say hello. Feel free to drop your LinkedIn into the chat if you wanna connect with fellow product people.

We’re gonna be using the chat today to to just. Discuss with each other and to discuss what we’re talking about here. And if you’ve got any questions, specifically ones that you want me to answer [00:01:00] drop those into the Q and A section, and that way I’ll be able to see those other people will vote them up, and that way we can make sure that we’re handling the most popular questions as they come through.

I will try to keep an eye on the chat though. I always appreciate seeing how everyone’s chatting about fighting against, ranting about all the stuff that that we’re talking about here in today’s webinar. And I can see people coming in from all over the place. Somebody from Cleveland, somebody from Oklahoma somebody from Pennsylvania.

And then of course we’ve got the London Massive, we’ve got some people coming in from London. I’m in the UK just south of London. I’m in Brighton. So I know that there’s usually some locals here as well as people from all over the world. So great to see everybody and good to have you all here.

We’re gonna kick off in just a moment. I’ll give people just a second to to drop their hellos. Let us know that the chat’s all working for everybody. And we’ll kick off in just a minute.

All right. So welcome everybody. Welcome to our webinar here that we run here at ProdPad. What we do is we run a series of webinars. This is just one of [00:02:00] them. You can see the entire backlog of them if you go to our website. And we always have a mixture of either experts coming on board or individual presentations.

So today we’re gonna be talking about that tension between making hard product decisions without creating debt, and I mean tech debt, as well as other types of debt that we’re gonna dive into. So we’re gonna be jumping into this in as we go. As we do this today. Feel free to use the chat, use the Q and A panel ask your questions.

This is going to be recorded, so all of this you’ll be able to take home. We’ll send it over to you and you can share it round with your colleagues. We’ve also got some polls that we’re gonna be running today. And so get your fingers ready. We’re going to jump in on those. And yeah, you can have a chance to ask questions.

So drop those questions in as we go and we will definitely tackle those as we get to the end. Alright, so just having a look at the chat, see if anything’s coming in. I can see people from all over the world. This is great. Everyone’s AI assistance is here as [00:03:00] well. Hello to all your AI assistants. Feel free to take notes or of course we’ll send this recording to you afterwards.

So let’s kick off. And before we do, I just wanna tell you a little bit about what we’ve built here at ProdPad. So I know there’s a bunch of people in here who are already ProdPad users. Thank you so much for your support. For those of you who don’t know, ProdPad is a tool that me and my co-founder Simon built when we were product managers ourselves.

We just needed a tool to help us do our own job, and now it’s being used by thousands of product teams around the world. And we needed something to help us keep track of all the experiments and ideas and feedback, and to make a roadmap that we could share with different stakeholders without, without having to redo the deck time and time again.

And so ProdPad gives you a sense of organization and control, as well as transparency into the product management process. And helps you basically make sure that you’re building the right stuff, you’re sending the right things over to development. You can try it for free. We’ve also got a sandbox, which is preloaded with example data like you can see now, next later roadmaps and OKRs and ideas and feedback, all [00:04:00] sort of in one place that you can play with, explore, and try it out for yourself.

So jump in, try it out. Let us know what you think. We’re all product people here, so we’d love to get your take. Right. So let’s jump in. So. Our jobs as product people. It basically boils down to a professional decision maker. Like you’re surrounded by thousands of inputs, you know, customer feedback, user behavior customer business goals existing tech constraints, the competitive space, the competitive landscape your team capabilities, like all of these are different inputs, and your job is to make the calls that lead to building

one thing over any other number of other things.

And that’s the gig, right? We’ve got to, you know, make all these decisions. So, speaking of decisions, I got one thing for you right now. Let me just pull up this first poll. Bear [00:05:00] with me as I do this. I wanna make sure first of all, that polls are working and I’ve got a question for you. What’s the most important decision that you’ve made today?

Go on, click one. If none of those match, drop into the chat. Wrong answers only. And there we go. I can see answers coming in. Good. The polls work. We’re gonna have a few more of these that are a little bit more high stakes but we’re gonna let those answers roll in for just a second and see what we’ve got.

Ooh, there’s a battle between well, I’m not gonna say yet, but we’ll show off in just a second. But there’s a battle between two leaders right now. Alright. So I think we’ve got everyone’s answers in. A couple more clicks. All right. Excellent. So what have we got? I’m gonna share these results with you and you should be able to see that.

Joining this webinar has won this one out. So, excellent decision. We’re gonna be talking about reversible decisions. So this is a reversible decision, but I recommend sticking around because we’re gonna talk more about that. Love that slack messages. Almost one as well.

You know, that’s a [00:06:00] form of prioritization, deciding which one to you know, which messages to ignore which ones to actually tackle. All right, so very importantly, this is not a prioritization talk. You know, I’m not gonna hand you some two by two matrix and then send you on your way. What I wanna talk about is what happens inside product teams when decisions are made under pressure and why those decisions quietly stack up into something much more expensive than anyone ever intended.

I mean. What I’ve seen over and over in the 10 plus years of working with product teams is teams argue because they’re unsure. They stall because they want certainty. They over document because they’re afraid to be wrong. So prioritization frameworks don’t fail because they’re bad. They fail because they get this pretend confidence coming from the math.

You know, you can score everything with RICE or WSJF, but. You still won’t necessarily know what to do next because the real problem was never with the ranking or with the scoring, it’s that nobody felt confident enough to [00:07:00] commit or to know that they’re committing to the right things. So some bad advice that I’ve heard over the years that I’ve now realized is bad advice.

So I wanna give you permission to throw this out. The first one is when people say just, you know, sort everything into urgent versus important, and remember that urgency and importance, architectural, they, they change depending on who you are and what part of the business you sit in. You know, comparing across domains is where, this way of working completely collapses, right?

You can’t objectively rank whether a customer retention problem and a technical scaling problem and a competitive positioning problem on the same access, right? They’re, possibly all just as urgent and important. And so in pretending that you can just makes people feel stupid for not being able to rank stuff, not being able to see it clearly.

So throw out that notion of urgent versus important and this thing saying get clarity before action. It sounds great. But the thing is you rarely know where the information is. You know, waiting [00:08:00] for perfect clarity is often waiting forever. You are in this role as a product person because you can make decisions without perfect data.

That’s the value of having a person in this decision, in this role. You know, like even if AI crunches all the data for you, someone has to still to stand behind the decision, right? So we’re not gonna get replaced as decision makers anytime soon. That accountability doesn’t disappear for one.

And so I’ve told you that prioritization frameworks don’t work and that waiting for clarity is a trap. You might be wondering what actually is blocking your team. I have a theory, but I wanna hear from you first. So let’s go back and try the second poll here. Now that we know polls are working.

Alright, this one’s real, so no wrong answers. What’s the reason that decisions stall on your team? Is it too many stakeholders? Is it not enough data? Not enough evidence. Is it fear of making the wrong call? [00:09:00] Unclear ownership. Would love to see what is plaguing your teams. What’s stalling your decisions on your teams?

Again, the answers are torn here. This is very interesting.

Alright, I’ll give you just another few seconds to get your answers in there. Okay. We ready to share this? All right, let’s have a look. What do we think won?, It was unclear ownership. This is an absolute classic, you know, if nobody knows whose call it is, then nobody makes the call. And then the decision gets made by default, by whoever’s loudest or you know, by the deadline.

Just ’cause it has to be done. That’s one of the sneakiest way that unintentional debt gets created. And it looks like too many stakeholders where nobody commits is a really popular one. I actually thought this was the one that was going to to win. You know, every additional person in the room has the chance of that decision being made, [00:10:00] right?

It’s not a people problem, it’s a structural one. If everyone has veto power, then nobody has decision power. So, yeah, really interesting to see these two coming out in front. Unclear ownership and too many stakeholders. It just goes to show how much of product management is still a people problem.

Right. And Tom pointed out in the chat, those two answers feel very connected, very related, and yeah, I agree with that. Alright oh, there we go. I’ll stop that poll. Alright. So, building a product is a multidimensional problem. It, it can’t be done without making trade-offs the same way. You can’t get through life without making trade-offs.

You know, every time you say yes to something, you’re saying no to something else, even if you don’t say it out loud. And every trade-off that you make has a cost. And sometimes that cost is obvious and immediate, and sometimes it’s quiet and cumulative. You know, that cumulative cost is, is debt. And I wanna be clear, like debt is not [00:11:00] inherently bad.

Most of us can’t get through life without going into some sort of debt, right? Like think about this. A mortgage, your education, a car. You know, you could, you could try to save up the cash to get these things ahead of time, but you’d probably be dead before you saved enough, right? This is what, why debt can be an enabler.

And the same with products. You could try to build the perfect product, allowing no debt, no tech debt, nothing before it goes out the door, but you’d be obsolete before it was even launched, right? So debt enables you to move. The question is whether you’re taking it on deliberately or accidentally. So you might be familiar with that iron triangle of time, cost, scope, and quality, right?

For one of these to give, we’ve gotta be willing to give on another front, and so we rarely have, you know, magically spare budget or all the time in the world. So time and cost is often flexed. It’s exchanged for scope and quality, and this is exactly what we’re doing when we run experiments using quick [00:12:00] prototypes and MVPs, you know, we’re trading off perfect quality.

Or full scope in order to gain back time and cost. And that’s healthy debt, right? It’s the right move in many cases, but it’s not sustainable forever. You know, that whole good, fast, cheap pick two sort of thing. It exists for a reason. Like financial debt, like some product debt is also intentional and enabling your team agrees to take a shortcut, knowing that they’re gonna come back to fix it.

There’s this shared understanding of what’s at stake and how the debt’s gonna be measured and managed, and that’s fine. The dangerous kind is unintentional, right? This comes from not having those conversations, from skipping the bit where the team says things like, “we all understand this is a trade off and here’s how we’re gonna deal with it later.”

Unintentional debt. I just realized I didn’t share this results. Unintentional debt usually comes from beyond the team’s control. It comes from deadlines, from pressure. It comes [00:13:00] from decisions that were never explicitly framed as trade-offs.

I blame deadlines. Now, I know sometimes deadlines are necessary, and I’m not saying we should never work to them, but the timeline roadmap is basically a tech debt collection pot, right? Your bosses and your customers love the certainty that it gives them, but it often sets your team up for failure because that timeline

sits at the top, always marching forward no matter what you put on the roadmap. Everything always includes a deadline. And so you might have heard of Parkinson’s Law. Parkinson’s Law is the one that says that work expands to fill the time allotted. And so you end up with these deadline crunch and suddenly you’re not making

informed trade-offs anymore. You’re making last minute adjustments and the real damage is done beneath the surface where the product manager often doesn’t even realize. You know, it’s those bits of code that could have been more elegant, end up [00:14:00] getting skipped and isn’t built and ends up stacking up as tech debt down line.

Comments and documentation are left by the wayside, right? All the stuff that finishes it off just ends up not being done. And so the release might get out on time and it might look fine, but underneath it’s just that little bit subpar. The plan is always to come back and fix it, right? But everyone knows that V 2 is the biggest lie that your roadmap ever told.

You know, the backlog of, we’ll get back to this. Those items, they just grow and pile up quietly. And it never gets prioritized over new work because new work has stakeholders championing it and debt does not.

But here’s the good news. Most product decisions are reversible, right? They just feel scarier than they are. The cost of reversal matters more than being right, and this is why, you know, buy should usually beat build, even though build is such a seductive direction, and this is why speed of [00:15:00] decision matters.

You know, a hundred decisions at 50% good versus 30 decisions at at 70%. Good. You know, the fast team learns more and corrects faster. Now really important caveat, this only applies to reversible decisions, this whole fast and loose. I don’t wanna see any of you playing fast and loose with stuff like epics or safety, right?

So we know that decisions create debt, but most people only talk about one kind. I wanna widen the lens. Before I walk you through the full taxonomy though, I wanna know where you’re feeling it the most. Let’s pull up poll 3 here. All right, you got poll 3 here. I’m gonna be talking through six types of product debt.

Which of these are you feeling the most right now? You may not even be familiar with some of these, so I’d love to get your take on that. There’s a tech debt discovery debt. So more of the UX problems and the patch together experiences process debt.

Discovery [00:16:00] debt, might be a new one. It’s the, the root cause of much else, I think. Culture debt as well.

I’m not sure I put culture debt in there. We’ll talk about that. Alright, so I can see there’s actually a really interesting split coming through here.

Interesting to see what is causing the sources of your debt. Alright, so I’m gonna end this and I’m gonna share it.

Okay. So you should be able to see this now. Tech debt was a clear winner, not surprising. It’s the one that we have the best vocabulary for. And I, I bet good money, some of what you’re calling tech debt actually might be downstream from some of these other types. So I’m gonna be getting into that in more detail.

But I think it’s important to have a shared vocabulary around the [00:17:00] different types of debt that could be plaguing your company. So tech debt is just one type of debt. Most conversations around debt sort of stop here. So let’s talk through some of the other types. I’ve already alluded to those in the in the poll.

So, tech debt, as I think everybody here knows, is the cost of reworking existing parts of your product that were built in, you know, a hasty or subpar way instead of the ideal and full solution. And it might be intentionally built that way versus unintentionally built that way. It’s a reality of your product’s life.

The decision that creates it often goes like, you know, let’s ship this version now and refactor later. And sometimes that’s strategic, but oftentimes that later never comes. You know, one of the rubrics we have here at ProdPad is to build as if you are the one, we say this to the developers, build as if you’re the one who’s going to be training up a junior dev in a couple years time, how to use your code.

And that helps ensure that the stuff that’s going out is actually something [00:18:00] that we can stand on, that our platform can stand on. You know, sometimes means a little bit extra time and delivery, but the savings and not having to refactor everything all the time is pretty immense. So, design debt, this is the limitations that are built into your product that aren’t bugs, but you know, where the design doesn’t match the user needs.

So, you know, this is the ones that that sort of hide behind the calls of, it’s not a bug, it’s a feature. It was built that way. Companies are more likely to have a plan for paying down tech debt, things like, you know, bug crush weeks and refactor sprints. But there’s often, you know, there’s a lack of vocabulary around design debt and it’s often falling between the cracks.

You know you’ll say, yeah, sure the MVP was good enough. Let’s move on to the next thing. And it sort of does the job, but it doesn’t really solve the problem for the user. And so each experiment and prototype that goes out as is, that doesn’t get cleaned up, leaves you product as a patchwork of past learning.

That doesn’t really delight anybody.[00:19:00] 

And so when tech and design debt stack up your processes start compensating. So if the app is too hard to use, there’s too many bugs in it, then support ends up bearing the burden. If the tech isn’t up to scratch, you end up with, I don’t know, shaky automations and manual workarounds rather than a solid infrastructure.

Your team will be saying stuff like, well, yeah, we can just add a step to the workflow for now. We don’t need to automate this. And of course again, this might be the right decision for the short term, but these unscalable processes, you know, they might be appropriate when you’re a small, early stage in learning and getting things done fast.

But left unattended, they become pretty costly. Discovery debt is what happens when you skip that learning step, right? Every feature you build without validating the problem is a bet, and sometimes you win, but the features that you build without talking to users, without testing assumptions.

Without understanding the problem space. These are the ones that sit in your product forever, [00:20:00] you know, not quite right, not quite wrong. They’re just there. They create design debt and process debt downstream. And it often stems from conversations like, ah, we don’t have time for research. You know, stakeholder wants it by next quarter.

Or just build the thing that one customer told us to do or that stakeholder told us to do. Discovery debt compounds the fastest because every subsequent decision is built on assumptions that weren’t ever tested. And here’s one that I think about a lot. Roadmap debt is it’s what accumulates when you defer hard conversations around your strategic level, right?

When there are three things that should be number one priority, but no one’s willing to say which one wins. When your roadmap is absorbing everything without anything actually getting removed. You know, next quarter becomes the default answer. Right. The decisions that lead to this often stem from just avoiding those uncomfortable conversations about what we’re not gonna do.

Every item on your roadmap that doesn’t have clear [00:21:00] conviction behind it is roadmap debt. It takes up space, it creates false expectations, and it distorts every conversation, every prioritization, exercise that follows.

And when all these other forms of debt go unchecked, they spill into culture debt. This is the cognitive dissonance your team feels when they know they’re being dragged down by debt and short-term thinking. But the incentive structure rewards them for shipping more, not shipping well. You know, the decisions that create it stem from incentivizing output over outcomes or measuring teams as cost centers or, pitting divisions against each other with competing metrics. So a developer advocating for quality and a business person pushing for speed, aren’t necessarily fighting because of personal tensions. They’re disagreeing because the system is asking them both to work counter to each other’s incentives.

And what’s missing is a shared vocabulary and trust where they can talk about these trade-offs honestly. You know, maybe the answer is to get an [00:22:00] MVP out now, and then go back and rework it later right? That conversation needs to be had between different, different people in the team so they understand, you know, why we’re spending time in certain areas versus other ones.

And the thing about all these types of debt is that they don’t exist in isolation. You know, tech debt creates design debt and design debt creates process debt and process debt creates culture, debt and skipping discovery creates all of the above. Every time your team is stuck dealing with some sort of existing debt, they have less capacity for the work that would prevent future debt.

So it’s compounding vicious cycle and it starts with individual decisions that felt perfectly reasonable at the time. And so you might be thinking, alright some debt is intentional. We know we that we’re taking it all. And that’s fine. You’d be right. But I wanna know what the reality actually looks like for this group.

So, time for, poll number 4. Let me get that up. Get your clicking fingers ready. Alright, so quick gut check for you. When your team takes on [00:23:00] debt, how often is it actually deliberate? Like someone said out loud, we’re accepting the trade off and here’s the plan.

Seeing it coming in already. That’s great.

This is gonna give us a good starting point about how often we’re having these conversations. Cool. All right. We’ve got a bunch of answers in now. That’s great. Shall we end it here and share those results? All right, so you know, that whole so sometimes won here and followed by rarely just accumulates, you know, with that whole, sometimes, you know, depending on the, the type and who’s involved is really telling.

It usually means that your team has like pockets of good practice, but no consist system for it. Some people name trade-offs, some people are comfortable doing so because it is an uncomfortable conversation. [00:24:00] Others just prefer to ship and move on. So the debt from the second group kind of undermines the work from the previous group ’cause there’s no consistency or shared way of working.

Alright, let’s take a deep breath. I’m gonna take a sip of water ’cause this is the diagnosis, but next we’re gonna talk about what not to do. And again, this isn’t about eliminating debt ’cause you can’t, it’s about making it visible and intentional and manageable.

So the single most effective way to reduce decision debt is to decide the big things upfront, right? If your team has a clear vision, they don’t need to re-litigate things like, why are we building this every sprint? If your objectives are outcome-based as opposed to feature-based, people can make local decisions that align with the bigger picture without having to question it or go back.

And if you have shared principles. Things like we always talk to users before committing, or we don’t promise dates on [00:25:00] uncommitted work, or we pay down a bit of debt every sprint. Then, you know, like 80% of the decisions just sort of resolve themselves because they’ve got these underlying principles that that break the tie.

So you’re minimizing the number of decisions that need to be made in the first place, which is magic. ’cause then people can just get on with it when you are making a trade off and you will constantly, it’s important to just name it out loud. Just say, put down on paper, we’re choosing to ship this without the edge case handling because we want to learn whether users even want this feature.

You know, the debt that we’re accepting is that if it takes off, we’ll come back and build the robust version within the next quarter, right? Like, that’s the practice. You just gotta say the quiet part out loud, write it down. Make sure the people who will inherit the debt knows that this debt exists.

You know, oftentimes you’re writing stuff down, not just for you, but it’s for the people who come after you who are looking at these decisions that were made and trying to figure out why things were made. And sometimes [00:26:00] that person who comes after you is you, but in like two years time, you’re trying to remember something.

So I recommend keeping a decision log. So it’s, you are making hundreds of decisions. It’s just. Tracking that memory. So unless you’re writing them down, you’re not gonna remember why or what was at stake, or what you were meant to learn from it. And basically lots of decisions with no learning is just noise.

So a decision log captures what needs to be decided, what’s at stake, what information you need how you know if you got it right. What you’ll learn either way. And one of my favorite questions to ask about any sort of decision is the zoom out lens, right? So if a decision seems really big and impossible, what will you think about this decision in six months?

If it goes in either direction in a couple years time? It helps to show how reversible or how important decisions are. If this is something you go, actually in two years time this goes [00:27:00] right, we’ll be here. Or actually, in two years time, it probably won’t even matter, right? It just changes the quality of the conversation around your decisions.

Now with ProdPad, it’s a place to actually capture your decisions. But I’ve put out a decision log template that you can copy just to get into the practice of this yourself. So I’ll share this with you afterwards. I’m gonna jump into poll number five here.

I wanna ask what’s currently missing from your decision making system? This is the last poll. There’s two questions in here. I’ve talked about vision and principles explicit trade-offs, decision logging. I wanna know what your team is missing. What’s the biggest gap for you right now?

I’ve shared the poll. Let me know what you think is the biggest hole, the biggest gap for your team.

All right. Seeing some answers come in [00:28:00] here. Little good. Split across the board.

And there’s one that’s standing out to me. That’s not coming through yet. So I’m going to end this poll in just a second and I’ll share those results with you and see what we think. Alright, so we basically have almost an even split between a clear product vision a decision log or trade off record being missing and not having regular debt reviews like retros, but for debt.

Decision ownership came through as not the area to improve, which is interesting because the previous poll was all about stakeholder problems, having too many people and not enough ownership. Interesting. I wonder why that is. I’d love to hear any thoughts in the the chat if you’ve got any on that.

In the meantime, there’s also an offer to get the decision template sent over to you. So [00:29:00] anybody who asked for that, we’ll send that out afterwards with the presentation. Right, so, really interesting results there and looks like there’s a really good split of different problems that are coming up here.

So hopefully this has been a really interesting chat. So, this is where your roadmap can come in to help. Your roadmap should be a living record of all your outstanding decisions. You know, not a list of features and deadlines attached. The Now- Next- Later format was originally modeled on, are you familiar with the, the cone of uncertainty?

You know, where it’s like Now is what we’re confident in, what we’re committed to. Next is what we’re learning about and building conviction around later, and Later is on that horizon. Things that we think matter, but haven’t validated at all yet. It’s less about exactly what’s gonna be done and when, and more about where we’re confident about and where we still need to gain information.

So each column is like a measure of certainty and a roadmap. It’s basically like. A list of outstanding decisions to be made. And on the flip side [00:30:00] in ProdPad we have what’s called the completed roadmap. This is your decision log, right? It’s a record of what you have chosen to do, what you did, why, and what happened with it.

I see a lot of teams who don’t currently maintain any sort of form of a decision log or a completed roadmap until they use ProdPad to shape it. So, if you wanna walk through of how this would work and, and look for your team, then let us show you through, sign up for a demo and we’ll show you through.

Now think of your roadmap as a prototype for your strategy. Like prototypes are meant to be tested and iterated. If your roadmap never changes, it’s not a roadmap, it’s just a wishlist with a bunch of deadlines, right? A good roadmap makes debt visible. It makes these upcoming decisions visible.

It’s where you can see that items have been sitting in next for multiple quarters without moving. It’s where you can see that now is full of unplanned work, right? Those patterns are actually signals. They tell you where decisions are being deferred and where debt is accumulating. [00:31:00] And so three tips on this, right?

At the organizational level, breaking the debt cycle requires three things. So strategic objectives. Whether you call these OKRs or KPIs or rocks or whatever anybody’s calling these days, they don’t care. It’s just making sure that you’ve got strategic objectives that the whole company is aligned on, and not just department level metrics that people that end up pitting teams against each other and then having holistic measures that look at the full cost of decisions, including things like, you know, the support burden of putting out junk code or team stress, or the accumulated tech liability and not just feature velocity.

And safe communication, right? This is where psychological safety comes in. You know, the ability for anybody on the team to say, I think we’re taking on debt here. I think this is gonna come back and bite us without being labeled as slow, or an obstruction to the team. A couple last tactical things to close on.

[00:32:00] First of all, when you’ve got too many decisions on your plate, you’re a professional decision maker. You do not have to make every call yourself. If your team is aligned on vision and objectives and principles, they can make a lot of the decisions without you. So spending your time, building that underlying framework and just making sure it’s clear on what we’re building towards and why, and how we make decisions.

Those principles that can just free up so much stuff. Your job as a product leader is to create the conditions for good decisions, not to be the bottleneck for every single decision out there. And second, this is one of my favorites, is just eat the frog. Anybody heard this term before? You know, sometimes the biggest source of debt

is the decision that you have been avoiding. That hard conversation with the stakeholder, that feature that needs to be killed, that roadmap, that needs to be reset, like just do it. Momentum creates clarity. Action reduces anxiety. Just get it done. Even if you can’t solve the whole thing, just getting into it, breaking it down to smaller pieces helps you to figure out what [00:33:00] the problem’s made of so you can start cracking it or delegating or doing something with it.

All right. So debt is a reality of our lives. You won’t build the best products by avoiding debt altogether, and you won’t build a healthy business or mindset by letting it stack up. But something becomes a little less scary when you talk about it. When you and those around you have a shared vocabulary for it, and when have a way of measuring and taking action on it.

So we’re gonna leave you with this today. If I’m gonna leave you with one thing today, it’s that the quality of your product over the long term is determined by the quality of your decisions in the short term. Not by which framework you use, not by how many story points you burn, but whether your team has the clarity, the confidence, the vocabulary to make trade-offs consciously and to to learn from the quickly.

So that’s it, that’s the talk. We’re gonna jump into Q and A in a second. But I did wanna let you know before you jump off that we have another webinar already booked. It’s gonna be with Nesrine Changuel she’s the author of Product [00:34:00] Delight. So she’s gonna come and talk to us and we’re gonna bring our questions for that.

In the meantime, let’s jump into Q and A for this. I’m gonna pull up our questions and see what we’ve got in here.

Folks, I see no open questions. I’m gonna check the chat and see if you’ve put them in there. If not, I wanna see what what has left you wondering, thinking and considering at the the end of this conversation. In the meantime, huge thank you for jumping in on all those polls and letting us know where you’re at right now.

I’m still quizzing over the contradiction between stakeholder issues being the core of where debt seems to be coming from, but also it being not the biggest thing those identified. There were other things that people thought they could do to solve problems.

Manish has asked a question. Thanks, [00:35:00] Manish. Manish says which debt do you give priority to if the product is not matured quickly enough? I mean, I guess those kinda ways of thinking about that because I wonder what you mean by the product has not matured quickly enough. Is it that the product hasn’t grown enough or is it that, you know, it doesn’t solve a wider, wide enough array of customer problems?

There’s a lot of different ways of taking product maturity. But if we’re talking about like the maturity curve and the product doesn’t matured quickly enough, I would ensure that you are tackling discovery debt. Because oftentimes when you’re building a new product, every new feature

is additive, right? You’ve got a new product, and it has three features. You add one, it’s all of a sudden 25% better, right? You add the next one, it’s 20% better. You continue adding features. And if they’re not actually solving problems, what you tend to find is that you get lots and lots of features, but not a lot of them are actually solving

much more of the problem for your customers. So the first features are huge for you. The last a hundred features or the [00:36:00] next a hundred features probably are less impactful. And so I think a lot of teams start off with just building a whole bunch of stuff. It becomes addictive. They get used to building really quickly, but they don’t really get into the practice of thinking about how to actually run discovery and think about which features need to be taken away or which ones, you know, if they had to choose between two features, which ones to build next ’cause previously they didn’t have to make a choice, the answer would build both.

Hopefully that it helps answer your question. Manish, I can see some other ones coming in here. Matt asked what signal would tell you that debt has moved from acceptable drag to strategic risk? And this is a big one, right? This is where the conversation needs to be happened because the answer, it wouldn’t be a product management talk if there wasn’t an, it depends somewhere in there, right?

But it does depend, right? It depends on what the strategy for the company is, right? In some cases it might be that actually moving as fast as possible because the market’s brand new because you’re trying to out compete something you’ve got, you’re up against a time clock. There’s something [00:37:00] timely.

Getting something out faster allows you to take on that risk of additional. Tech debt or other debt. Other times it might be the complete opposite, right? Like you are building something up against the incumbents and, you know, the world you’re building in is focused on security and regulation and therefore actually taking on less debt is more important.

It just depends. And this is why you’ve gotta have these conversations and this is why I like using that roadmap decision log format, because it gets you to think about, well, what could happen? What are we measuring? How do we know that this is gonna make an impact versus not? How do we know that this is the right answer for us?

These are all things that need to be answered by your team. And just have the conversation. Andrew has said, we’ve tried a decision log in the past but the time to manage it and maintain it led it to become stale. I suppose that means that we don’t see the value in it. So can you share the ROI that you have personally seen in it?

So Andrew, I really appreciate that. One of the problems that people have with the decision log is that it becomes this unwieldy [00:38:00] spreadsheets or unwieldy notion set of pages or something like that. And it’s not part and parcel of the actual product development flow. Like this is why we baked into ProdPad itself, right?

So you use it to collect all the different things that you could do. It’s not your job to do all those things. It’s your job to assess and all the things we could do, which ones should we do? And it helps follow through, not just what happens before development, but very importantly what happens

after development. As in, we did this thing, did it work? Did it not work? What did we learn from it? And it just creates that space so that you are including that information in the same place where that prioritization is happening. Those prioritization decisions have happened. And when you have it all in one space and it’s all interconnected, it makes a massive difference.

So an example of this came up recently where a newer designer on our team said, does anybody remember why we made a decision to do this like this? And, if I’d had to just scrape through my head and go, oh, I wonder what the decision was or who decided that I wouldn’t have known. Right? There’s been decisions being made in the [00:39:00] product over the years that I can’t remember.

And I was actually able to ask our copilot AI tool that’s connected to all this stuff in ProdPad, so it’s connected to our decision log. And I just said to it, what happened here? What have we ever decided about the pricing of this thing? And it came back and it came up with a summary and said, ah, Janna and Simon had this conversation and they decided this for this reason.

I was like, there we go. That’s magic. And this is a conversation that had happened five years ago, but had been logged as part of our day-to-day work in ProdPad, our day-to-day product work. And it was able to be dug up years later. So that was a massive win. And it’s things like that, that we’re able to dig up all the time.

So you can’t just have a decision log if it’s not being used. You need to put it somewhere that your team is actually gonna be using it day to day. Hopefully that helps. And Andrew, if you wanna guide through ProdPad let me know and I’ll hook you up.

Oh, I can see lots of questions in the chat here. Lemme try to get them before they disappear up there. Alright, so Izah, sorry if I’ve messed up your name there. Do you do debt review like [00:40:00] retros after big projects or are they ongoing reviews like backlog reviews? I see them as retros after projects.

Right. So it should be something that’s done as and when needed. I mean, the way that we work here at ProdPad is that because we break things into small pieces, our retros are kind of ongoing anyways. So as long as you’re doing these things regularly, then I think that’s the important part.

But what they’re doing is they’re looking back on decisions that have been made and accepted debt at the time, and whether that’s still accepted, right? So when you’re launching something, when you’re putting something forward to be launched outlining why it’s being done this way and what you’re conceding to, what you’re trading off along the way,

and including some sort of marker to say, “Hey, you know, three months after launching this, we should be able to check that this is done the thing. And if it has, then this is the decision to be made. And if it hasn’t, then this is the decision to be made”. Things like, you know, are [00:41:00] we going to double down and improve on this feature?

Or are we gonna pull it out because it didn’t work? Otherwise what you end up with is a bunch of features that are being made and they don’t necessarily win anybody’s hearts, but they stay in there because no one’s in charge of making the decision to take it out or to improve on it. See if there’s other questions in here. Probably not been monetized in time. I’m not sure that’s a question I’m gonna ask this. Alright. Could discovery be used to answer debt that you don’t know about? Yes. Right. So this is how they sort of feed into each other, right? So spending time in discovery will undoubtedly pick out

debt that you don’t know about. So some of it might be technical debt, like you’re just getting people to try the product and you’re recording how people, you know are making use of particular things to see if it solves the problems. And then you run into bugs and you go, yeah, okay, let’s record those.

Do something with them, right? But it could also be things like asking them about what problems you’re trying to solve and you go, well, I thought our product solved that. Then you have them use the [00:42:00] product and you realize that you’ve got some design debt in there. You know, something that kind of works or it was designed a particular way, but it wasn’t actually designed in a way that the user could actually use it and therefore it doesn’t solve the problem.

And I bet we probably, hell have lots and lots of those because they’re the ones that fall between the cracks. They’re not bugs, but they’re also not, not bugs. And so doing that discovery work will help dig these things up. They’ll also dig up process debt, right? So sometimes

when you’re trying to figure out how something solves a job to be done for an end customer, it’s not just what needs to be done for the end customer, it’s also what your team needs to do as well. There’s jobs to be done in there as well, and so oftentimes you’ll find that there are areas where yet.

The service gets the job done, but only because you’ve got so and so over there who, you know, manually does the step over here, right? Manages some part of the billing or part of the imports or part of supports or whatever. And you’ve got stuff that could be automated but is not yet right, or they’re tied together with [00:43:00] Zapier and duct tape and hope.

As opposed to actually being built in something more robust. And so yeah, just digging into what jobs you’re trying to solve for the wider market can actually help you figure out whether your product is solving those or not, and what part of the product isn’t working for that. Jackie asked if you have discovery debt, meaning we’ve built features that are in place, not fully thought out,

How would you recommend addressing that? So I like to think of them as bug bugs, right? So, you know I think a UX bug is not any different than a technical bug. I mean, you know, they’re both things that can be reproduced you basically saying, Hey, look, my intention as a user is to go through and do this, and it doesn’t work, right?

It’s not as smooth as it could be. I know it’s not like console error flashing up or anything like that. It’s not a broken thing, but it’s certainly not a working thing and therefore it needs to be captured as such and recorded so that the team can do something about it. And this is why these things fall in the cracks.

They sort of go, oh, it’s sort of [00:44:00] there. But it doesn’t really work as well as we thought it would. And those fall between the cracks. So you need to keep your eyes out for those ones and be ready to report them and act on them. And just like bugs, you need to spend time paying down that debt. So you need to make that a strategic piece of your work, which is, we want to make sure that we have a working product, therefore we’re going to spend, is it 20% of your time paying down tech debt?

Is it 3 out of your 10 points every sprint? Is it a bug crush week, every four weeks, whatever it is, right? There’s different ways of doing so, but you should be putting in stuff that’s not just tech bugs, but also UX bugs. Does anybody else use the term UX bugs? I’m not sure if we made that one up or if I’ve picked that up.

Some other smart product person, but we call them UX bugs. Alright. There was one other question in the, Q and A Matt’s asked, how do you decide whether a piece of debt should block future innovation or whether we can safely let it sit in the background while you pursue [00:45:00] growth? Really good question.

So again, this comes down to having that conversation around what’s acceptable and what those bigger steps are, and this is where the roadmap helps you lay that out, so you’re not just deciding as to what’s gonna go out for this next release. Because if we do that, then it’s short-termism, it’s well, we get something out and then we can say it’s done and we move on to the next thing.

But it’s actually about saying, well, we’re here now. We’re next gonna be working on this sort of thing. And then after that we’re trying to get to this sort of area so we can’t make it so that this doesn’t work, right? We can’t make a cheap, cheerful version. We’ve gotta make a more robust version. Or actually maybe we need to get there really fast to see if this is the right thing to do.

So this thing that we’re doing now is gonna validate whether the thing that we’re doing next is actually the right thing to do next. And if it isn’t the right thing to do next, we’ll find that out by doing the thing in the now, really quickly. So there’s different conversations that need to happen depending on what’s actually going on in your roadmap.

You know what the context is of where you are now and what steps you need to get to going forwards.[00:46:00] 

So I think we’ve tackled all those questions. I wanna say a huge thank you to everybody who’s dropped in who jumped in on those polls and who jumped in on the chat and in the Q and A. Really good to have you all here. And as I said, we’re gonna be back here same time next time. We’re gonna be doing Wednesday, March 17th, talking about the Science of Product Delight with Nesrine Changuel, the author of Product Delight.

Alright, so on that note, thank you so much. Have a good day, morning, evening, afternoon, wherever you are, and we’ll see you next time. Bye for now.