{"type":"rich","version":"1.0","provider_name":"Transistor","provider_url":"https://transistor.fm","author_name":"The Product Engineering Podcast","title":"Output Metrics vs Outcome Metrics","html":"<iframe width=\"100%\" height=\"180\" frameborder=\"no\" scrolling=\"no\" seamless src=\"https://share.transistor.fm/e/4e9ea5be\"></iframe>","width":"100%","height":180,"duration":1021,"description":"Engineering teams have access to more delivery data than ever. Jira can measure cycle time and velocity. GitHub can track pull requests and code changes. Deployment tools can show how often software reaches production and how reliably those releases perform.\nThese metrics are useful, but they only tell us how efficiently a team produces software. They do not tell us whether that software made the product better.\nIn this episode of The Product Engineering Podcast, James explores the difference between output and outcome metrics, and why engineering leaders need both.\nThe episode begins with the McNamara fallacy: the tendency to focus on what is easy to measure while overlooking information that may be more important. Engineering organisations can fall into the same trap when they treat delivery activity as the primary measure of success.\nJames explains why output metrics work well for predictable work such as migrations and platform upgrades, where the intended destination is already understood. Product development is different. Teams are often working with uncertain assumptions about customers, behaviour and business impact. Efficient delivery cannot compensate for building the wrong thing.\nThe episode also covers:\nThe difference between output and outcome metrics\nWhy delivery metrics are easier to measure and attribute\nWhen metrics such as cycle time, deployment frequency and story points are useful\nWhy product engineering cannot be managed like a manufacturing line\nHow feature factories emerge when teams are rewarded mainly for shipping\nThe growing importance of outcome accountability as AI makes implementation faster\nWhy teams should decide how they will measure success before delivery begins\nThe difference between leading and lagging indicators\nHow outcome measurements can guide iteration and product decisions\nJames shares an example involving two engineering teams. One completed a predictable React migration, while the other delivered a navigation redesign...","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}