{"type":"rich","version":"1.0","provider_name":"Transistor","provider_url":"https://transistor.fm","author_name":"The Product Engineering Podcast","title":"The Product Equivalent Of Technical Debt","html":"<iframe width=\"100%\" height=\"180\" frameborder=\"no\" scrolling=\"no\" seamless src=\"https://share.transistor.fm/e/505129f8\"></iframe>","width":"100%","height":180,"duration":698,"description":"Software teams are used to talking about technical debt, but products can accumulate another kind of debt too.\nOutcome debt builds up when features are shipped without confirming whether they achieved the result they were intended to produce. Over time, products become filled with decisions, assumptions and features that may once have made sense, but are no longer delivering enough value.\nIn this episode, James explains how outcome debt compares with technical debt, why it does not necessarily mean that anyone made a bad decision, and how changes in customer behaviour, technology and the wider market can cause previously successful features to lose their effectiveness.\nThe episode also explores how outcome measurement helps teams identify outcome debt, why sunk costs make weak features difficult to remove, and how teams can address technical debt and outcome debt together.\nIn this episode\nWhat outcome debt is and how it accumulates\nThe similarities between outcome debt and technical debt\nWhy good product decisions can become outdated\nHow changing customer behaviour creates outcome debt\nWhy measuring outcomes reveals problems that delivery metrics miss\nThe role of sunk-cost thinking in product decisions\nHow to reassess older features using current evidence\nCombining product improvements with technical refactoring\nHow leaders can create space to address outcome debt without assigning blame\nWhy established products must continually revisit earlier decisions\nOutcome debt is not evidence that a team failed. It is a natural consequence of building products in a changing environment. The important question is whether teams regularly return to previous decisions, measure their continued impact and improve or remove the features that no longer serve the product.\nThe Product Engineering Podcast explores how software teams can move beyond shipping features and take greater responsibility for measurable product outcomes.","thumbnail_url":"https://img.transistorcdn.com/tOpN0tMoB9dtDg__O2XafuXKrZuomc_ze_mLWYIpO7A/rs:fill:0:0:1/w:400/h:400/q:60/mb:500000/aHR0cHM6Ly9pbWct/dXBsb2FkLXByb2R1/Y3Rpb24udHJhbnNp/c3Rvci5mbS83Mjc4/NGQwOThhMzkyZGVm/ZmFjYmQ3N2NkMDcz/YWNlYS5wbmc.webp","thumbnail_width":300,"thumbnail_height":300}