Mike Lyons explains how product owners can make intentional, value-based trade-offs rather than chasing perfect solutions. He gives four practical principles (identify competing values, be transparent about trade-offs, adapt as the organization matures, and involve diverse perspectives) and shares the WSJF prioritization technique (cost of delay / job size) with a stepwise scoring method and an accompanying spreadsheet resource.
As a product owner, you should expect to face difficult trade off decisions pretty much every day. Should you fix that bug or should you add a new feature? Maybe pay down technical debt or rush to market? Improve security or enhance performance? We want to make decisions based on value. It's not about necessarily finding the perfect solution. It's about making intentional trade offs that are aligned with our core value proposition. So how do you develop the skills to make these difficult trade off decisions effectively? Well, first, identify the competing values in each decision. Every choice means prioritizing one value over another. Speed versus quality, new features versus stability, short term gains versus long term sustainability. Make these trade offs explicit rather than pretending you can have it all. Second, be transparent about your reasoning. Clearly communicate what you're gaining and what you're giving up. For example, you might say we're choosing user experience over feature richness because simplicity drives adoption in our market. Third, recognize that the right trade offs, well, they change over time. What works in your startup phase like speed over perfection, well, it shifts as you mature. Maybe it's now reliability over rapid releases. So adjust as your context evolves. And fourth, involve diverse perspectives in these trade off discussions. Developers, sales and users, they all value different things. As a po, certainly you own the decisions. But just because you can make the final call doesn't mean you shouldn't listen to other perspectives. For me, some of my best decisions have come from really hearing what others had to say. I once had a developer pushing hard for fixing technical debt, but I was totally focused on new features. My instinct was to like, override the developer and push forward with my new features. But I remember having this nagging feeling that I needed to pause and listen and learn more. So I dug deeper to try to understand why this mattered so much to them. Turns out they'd been burned before by technical debt. In the end, we actually ended up spending a whole sprint focused on system improvements and our throughput. Well, it increased over the following sprints because of that one decision. The key is to stay flexible in your thinking. Your way isn't always the only way. And sometimes the best solutions come from blending different viewpoints. That's what real collaboration looks like. Not just nodding along, but actually being open to changing your mind when someone makes a good point. Now, just a pro tip here. When someone shares an idea, maybe an idea you don't necessarily agree with, instead of saying but try saying yes. And it's amazing how this tiny subtle change opens up conversations and gets people really thinking together. Don Reinerston, in his excellent product Management book the Principles of Product Development Flow gives us a powerful tool you can use to help guide these conversations. It's called Weighted shortest Job first. A funny name, I know, but I found it to be an amazing tool. The formula is simple. Cost of delay divided by job size. This helps us focus on high value items that don't take long to implement. Think of cost of delay as the money you're losing each day, week or month that you delay delivering something valuable. It's like having a lemonade stand. If you wait an extra day to open, that's a day's worth of sales you've lost forever. Hello, Delicious lemonade, anyone? Now, to calculate cost of delay, we're going to look at three things. The business value, how time critical it is, and whether it reduces risks or enables new opportunities. We add these three scores together to get our cost of delay. Now, here's the key to making this work well. Score one column at a time across all features. For example, start by scoring business value for all the features on your list. Find the smallest one and give it a score of one. Then score everything relative to that baseline. Then move to the next column, time criticality, and do the same thing. Find the least time critical item, mark it a one, and score everything else compared to that. And then repeat that for risk reduction. Finally, estimate the job size using the same approach. Find the smallest job market as a one and score everything else relative to that. Now, job size is about the work remaining to complete. So if you've got something in flight, we're only talking about the work remaining to complete it. Okay? So when you divide the cost of delay by job size, you get your weighted shortest job first score. The highest score goes to the top of your priority list. Now, I know this may sound a little complicated, so to help you out, I've built a spreadsheet that's going to do all the math for you. You'll find it below this lesson. This approach makes economic trade offs visible and explicit. It creates a shared understanding of the priorities based on value. But I would say that the conversations you have while scoring, they're often as valuable as the final numbers themselves. Okay, just the last thought here. Value based decision making. It's not about avoiding trade offs or trying to do it all on your own. It's about about making decisions intentionally and collaboratively and in alignment with what matters most to your users and your organization.
