# How to Make Hard Product Decisions Without Creating Long Term Debt

## Метаданные

- **Канал:** ProdPad
- **YouTube:** https://www.youtube.com/watch?v=VW2NClEYSfA
- **Дата:** 26.02.2026
- **Длительность:** 46:45
- **Просмотры:** 54

## Описание

Every product team makes trade-offs. Some are deliberate. Many are rushed. And a surprising number quietly turn into long-term debt that slows teams down for years.

Watch Janna Bastow unpack how everyday product decisions such as “just this once” compromises, the short-term wins, the well-intentioned shortcuts, compound into product, process, organizational, and of course, tech debt.
Because here’s the uncomfortable truth: most product debt isn’t created by bad teams or bad intentions. It’s created by pressure, ambiguity, and decisions made without a clear view of the consequences.

Watch and learn how to spot these patterns early, make better trade-offs under pressure, and build decision habits that keep your product and your team healthy over time.

## Содержание

### [0:00](https://www.youtube.com/watch?v=VW2NClEYSfA) Segment 1 (00:00 - 05: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 want to make sure that we're 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 chat's working, Matt, as well. Really appreciate that. All right, so systems are go. Zoom is forgiven. And we're going to 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 want to connect with fellow product people. We're going to be using the chat today to discuss with uh each other and to discuss what we're talking about here. And if you got any questions, specifically ones that you want me to answer, drop those into the Q&A section, and that way I'll be able to see those, other people to 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 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 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 going to kick off in just a moment. I'll give people just a second to drop their hells, 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 ProPad. What we do is we run a series of webinars. This is just one of 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 going to 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 going to dive into. So, we're going to be jumping into this in as we go. As we do this today, feel free to use the chat, use the Q&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 around with your colleagues. We've also got some polls that we're going to 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. All right. 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 well. Hello to all your AI assistants. Feel free to take notes or of course we'll send this recording to you afterwards. All right, so let's kick off. And before we do, I just want to tell you a little bit about what we've built here at Progpad. So, I know there's a bunch of people in here who are already ProductPad users. Thank you so much for your support. For those of you who don't know, ProPad 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 road map that we could share with different stakeholders without having to redo the deck time and time again. And so ProPad 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 for free. We've also got a sandbox which is preloaded with example data like you can see now next later road maps and OKRs and ideas and feedback all 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 with me as I do

### [5:00](https://www.youtube.com/watch?v=VW2NClEYSfA&t=300s) Segment 2 (05:00 - 10:00)

this. I want to 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 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 going to have a few more of these that are a little bit more high stakes. We're going to let those answers roll in for just a second and see what we've got. There's a battle between Well, I'm not going to say yet, but we'll show off in just a second. But there's a battle between two leaders right now. All right. So, I think we've got everyone's answers in. Couple more clicks. All right. Excellent. So, what have we got? I'm going to 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 going to be talking about reversible decision. So, this is a reversible decision, but I recommend sticking around cuz we're going to talk more about that. Love that Slack messages almost won as well. You know that's a 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 going to hand you some 2x two matrix and then send you on your way. What I'm want to 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 overdocument 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 WSFJF, 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 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 want to 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 are contextual. 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 axis. Right? They're possibly all just as urgent as important. And so in pretending that you can just makes people feel stupid for not being able to rank stuff, not be able to see it clearly. So throw out that notion of urgent versus important. And you know this thing saying get clarity before action sounds great, but the thing is you rarely know where the information is. You know, waiting for perfect clarity is often waiting forever. You're 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 has to stand behind the decision, right? So, we're not going to 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 want to hear from you first. So, let's go back and try the second poll here. Now that we know polls are working. All right, 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? Unclear ownership? We would love to see what is plaguing your teams. What's stalling your decisions on your teams? And again, the answers are torn here. This is very interesting. All right, 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? One, 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 is loudest or, you know, by the deadline just because it has to be done. And 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 win. You know, every additional person in the room has the chance of that decision being made

### [10:00](https://www.youtube.com/watch?v=VW2NClEYSfA&t=600s) Segment 3 (10:00 - 15: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. All right. Oh, there we go. I'll stop that poll. All right. So building a product is a multi-dimensional problem. 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 debt. And I want to be clear like debt is not 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 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, right? 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 got to 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 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 going to come back to fix it. There's this shared understanding of what's at stake and how the debt's going to 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 going to deal with it later. " Unintentional debt. I just realized I didn't share those results. Unintentional debt usually comes from beyond the team's control. It comes from deadlines, from pressure. It comes from decisions that were never explicitly framed as trade-offs. And 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 road map, 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 tradeoffs anymore. You're making lastminute 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 getting skipped and isn't built and ends up stacking up as tech down the 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. And the plan is always to come back and fix it, right? But everyone knows that V2 is the biggest lie that your road map 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 decision matters. You know 100

### [15:00](https://www.youtube.com/watch?v=VW2NClEYSfA&t=900s) Segment 4 (15:00 - 20:00)

decisions at 50% good versus 30 decisions 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 want to see any of you playing fast and loose with stuff like ethics or safety, right? So, we know that decisions create debt, but most people only talk about one kind. I want to widen the lens. Before I walk you through the full taxonomy, though, I want to know where you're feeling it the most. Let's pull up poll three here. All right, you got poll three here. I'm going to 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 debt might be a new one. It's the root cause of much else. I think culture debt as well. I'm not sure I put culture dead in there. We'll talk about that. All right. 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. All right. So, I'm going to end this and I'm going to 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 bet good money, some of what you're calling tech debt actually might be downstream from some of these other types. So, I'm going to be getting into that in more detail. But, I think it's important to have a shared vocabulary around the different types of debt that could be plaguing your company. So tech debt is just one type of uh 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 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 often times that later never comes. You know, one of the rubrics we have here at ProPad is to build as if you're the one, we say this to 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 that we can stand on, that our platform can stand on. You know, sometimes means a little bit extra time in 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 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 is 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 your product as a patchwork of past learning that doesn't really delight anybody. Uh, 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 and discovery dev 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. You know, not quite

### [20:00](https://www.youtube.com/watch?v=VW2NClEYSfA&t=1200s) Segment 5 (20:00 - 25:00)

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, the 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 road map 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 going to do. Every item on your road map that doesn't have clear 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 MVP out now and then go back and rework it later, right? that conversation needs to be had between 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 a compounding vicious cycle and it starts with individual decisions that felt perfectly reasonable at the time. And so, you might be thinking, all right, some debt is intentional. We know that we're taking it on. That's fine. You'd be right. But I want to know what the reality actually looks like for this group. So, time for poll number four. Let me get that up. Get your clicking fingers ready. All right. So, quick gut check for you. When your team takes on debt, how often is it actually deliberate? Like someone said out loud, "We're accepting the trade-off and here's the plan. " All right, seeing answers coming in already. That's great. This is going to 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 one here and followed by rarely just accumulates. You know, with that whole sometimes, you know, depending on the type and who's involved is really telling. It usually means that your team has like pockets of good practice, but no consistent system for it. Some people name trade-offs. Some people are comfortable doing so because it is an uncomfortable conversation and others just prefer to ship and move on. So the debt from the second group kind of undermines the work from the previous group because there's no consistency or shared way of working. All right, let's take a deep breath. I'm going to take a sip of water because this is the diagnosis. But next we're going to talk about what not to do. And again, this isn't about eliminating debt because you can. It's about making it visible and intentional and manageable. All right. So, the single most effective way to reduce decision debt is to decide the big things up front. Right? If your team has a clear vision, they don't need to relitigate 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, you know, things like we always talk to users before committing or we don't promise dates on uncommitted

### [25:00](https://www.youtube.com/watch?v=VW2NClEYSfA&t=1500s) Segment 6 (25:00 - 30:00)

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 break the tie. So you're minimizing the number of decisions that need to be made in the first place, which is magic because 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. Like 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 got to 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 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're making hundreds of decisions. It's just tracking that memory. So unless you're writing them down, you're not going to 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. 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 if this goes 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 broadpad 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 going to jump into poll number five here I want to ask what's currently missing from your decision-making system. And this is the last poll. There's two questions in here. I've talked about vision and principles, explicit trade-offs, decision logging. I want to know what your team is missing. What's the biggest gap for you right now? And 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 here. A 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. All right. So, we basically have almost an even split between uh 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 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, 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 road map can come in to help. Your road map 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 cone of uncertainty, you know, where it's like now is what we're confident and 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 going to 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 road map it's basically like a list of outstanding decisions to be made. And on the flip side in ProPad we have what's

### [30:00](https://www.youtube.com/watch?v=VW2NClEYSfA&t=1800s) Segment 7 (30:00 - 35:00)

called the completed road map. 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 road map until they use ProPad to shape it. So if you want to walk through of how this would work 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 road map as a prototype for your strategy. Like prototypes are meant to be tested and iterated. If your road map never changes, it's not a road map. It's just a wish list with a bunch of deadlines, right? A good road map 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. And so three tips on this, right? At the organizational level, breaking the debt cycle requires three things. So strategic objectives, you know, whether you call these OKRs or KPIs or rocks or whatever anybody's calling them these days, I 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 going to come back and bite us without being labeled as slow or an obstruction to the team. Uh, a couple last tactical things to close on. 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 road map 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 figure out what 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 you have a way of measuring and taking action on it. So, we're going to leave you with this today. If I'm 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 any how many story points you burn, but whether your team has the clarity, the confidence, the vocabulary to make trade-offs consciously and to learn from them quickly. So, that's it. That's the talk. We're going to jump into Q&A in a second, but I did want to let you know before you jump off that we have another webinar already booked. It's going to be with Dream Changel. She's the author of Product Delight. So, she's going to come and talk to us and we're going to bring our questions for that. In the meantime, let's jump into Q&A for this. I'm going to pull up our questions and see what we've got in here. Folks, I see no open questions. I'm going to check the chat and see if you put them in there. If not, I want to see what has left you wondering, thinking, and considering at 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 that was identified. There were other things that people thought they could do to solve problems. Manish has asked a question. Thanks Manish. Says, "Which debt do you give

### [35:00](https://www.youtube.com/watch?v=VW2NClEYSfA&t=2100s) Segment 8 (35:00 - 40:00)

priority to if the product has not matured quickly enough? " I mean, I guess there's a couple ways of thinking about that cuz wondering 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 hasn't matured quickly enough, I would ensure that you are tackling discovery debt, right? Because oftent times 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 that much more of the problem for your customers. So the first features are huge for you. The last hundred features or the next hundred features probably are less impactful. And so I think a lot of teams start off with just building a whole bunch of stuff and 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. Previously, they didn't have to make a choice. The answer is build both. Um, hopefully that 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 happen 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 time clock. There's something 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 got to 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 going to 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 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, Andre, I really appreciate that. One of the problems that people have with a decision log is that it becomes this unwieldy spreadsheet 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 it into broadpad 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 of 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. Um, 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 product over the years that I can't remember. And I was actually able to ask our co-pilot AI tool that's connected to all this stuff in ProPad. So, it's connected to our decision log. And it 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, Jana 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 5 years ago, but had been logged as part of our day-to-day work in ProPad, 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 were 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 going to be using dayto-day. Hopefully, that helps. And Andrew, if you want to guide through ProPad, let me know and I'll hook you up. All right. Oh, I can see lots of questions in the chat here. Let me try to get them before they disappear up there. All right. So, Isaia, sorry if I've messed up your name there. Do you do debt review like retros after big

### [40:00](https://www.youtube.com/watch?v=VW2NClEYSfA&t=2400s) Segment 9 (40:00 - 45:00)

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 ProPad is that because we break things into small pieces, our retros are kind of ongoing anyways. So, um, 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 uh, 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, 3 months after launching this, we should be able to check that this has done the thing, and if it has, then this is the decision to be made, and if it hasn't, made. Things like, you know, are we going to double down and improve on this feature, or are we going to pull it out because it didn't work, right? 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. Seeing if there's other questions in here. Probably not been monetized in time. I'm not sure that's a question I'm going to ask this. All right. 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 their 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. " And then you have them use the 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 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 bugs. Um, 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 often times you'll find that there are areas where yeah, the service gets the job done, but only because you've got so and so over there who, you know, manually does this 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 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 do 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're 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 a 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 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. 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 three 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. All right. There was one other question in the Q&A. Matt 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 growth? " Really good question. So

### [45:00](https://www.youtube.com/watch?v=VW2NClEYSfA&t=2700s) Segment 10 (45:00 - 46:00)

again, this comes down to having that conversation around what's acceptable and what those bigger steps are. And this is where the road map helps you lay that out. So you're not just deciding as to what's going to go out for this next release. Because if you 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 going to 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 got to 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 going to validate whether the thing that we're doing next is actually the right thing to do next. And if it isn't next, we'll find that out by doing the thing in the now um really quickly. So, there's different conversations that need to happen depending on what's actually going on in your road map. you know what the context is of where you are now and what steps you need to get to going forwards. All right, so I think we've tackled all those questions. I want to say a huge thank you to everybody who's dropped in who jumped in on those polls and the chat and in the Q&A. Um really good to have you all here. And as I said, we're going to be back here same time next time. We're going to be doing Wednesday, March 17th, talking about the science of product delight with Nezarin Changwell, the author of Product Delight. All right, 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.

---
*Источник: https://ekstraktznaniy.ru/video/47616*