If you're a product owner, you're likely throwing a lot of money away

I would definitely consider myself more of an engineer than a PM, but I've had my hands in many pots over the course of my career. One such pot was a startup I worked for a while back, where I sat in on prioritization meetings. These meetings were primarily composed of PMs but also included the directors of several engineering and design teams. They ultimately decided what would be worked on that sprint, the projected schedule for other tasks in later sprints, and some of the discussions that shaped the roadmap. In other words, these meetings essentially determined what the product would become.

Few discussions at a company are more important. If a company's success is 50% about the ability to sell the product and 50% about the product itself (though, personally, I'd argue it's closer to 30%-70%, but I'm biased), then it's not a stretch to say that the survival of the company—or at the very least, the product—hinges on what comes out of those meetings. The tasks would be decided, broken down, worked on by engineers, and eventually pushed into production, where they would (or often wouldn’t) contribute positively to the company in some way.

Given the importance of prioritization, how do you imagine these decisions are made? Here’s a quick example of an exchange:

Exec: "Sorry for the short notice, but we have some high-priority security-related tasks that need to be included in this sprint. Looks like they'll require a fair amount of resources."

PM: "Ah, okay. The sprint is already pretty full, so we’ll have to drop some tasks. These are our lowest-priority ones: an update to the checkout design, a bug fix in the signup form, and a schema update to improve inventory query performance."

Exec: "Okay, how many would we need to cut?"

PM: "They're all pretty comparable, so probably two out of three."

Exec: "I see. Hmmm. Well, improving the checkout conversion rate would definitely be helpful. What do you think about keeping that one in the sprint?"

PM: "Yeah, I think that works."

Obviously, this exchange is completely made up, but I’m sure similar conversations happened regularly in those meetings. Tasks were inevitably left off the sprint’s task list in favor of more pressing ones—decisions that, in most cases, were completely justified. Things come up, and companies have to adjust; that's just the way it is.

But my issue isn’t with tasks being deprioritized or assigned high priority—it's with how these decisions are made. Unless someone has an emotional stake in a decision (e.g., a pet project, something a colleague really needs, etc.), most of these choices are made based on gut instinct. Granted, a lot of the time, it's the gut instinct of highly experienced professionals who are very good at what they do—but it's gut instinct nonetheless.

So what’s missing from this exchange? One word: numbers.

Rarely would someone provide a numerical argument for prioritizing one task over another. Sure, the task might involve a metric, such as conversion rate, but rarely anything beyond that. A for-profit company exists to generate the most revenue with the least cost, and as a product owner, you’re essentially doing the same thing on a smaller scale—your product is your company. Yet, I’d be hard-pressed to find product owners making decisions based on real metrics.

Good product owners use an abstract representation of their product called a KPI tree to help decide what’s important. A KPI tree is a tool for connecting lower-level KPIs (e.g., conversion rate) to revenue or other critical company-wide metrics. Really good product owners might even maintain a spreadsheet to assess how sensitive their KPIs are to overall performance, keeping this as an informal prioritization algorithm in the back of their minds. But I have yet to meet someone who models the impact of a new task on a KPI, in a mathematical sense, before it’s done.

Why is this the case? I think there are two main reasons.

First, product owners have diverse skill sets, but they can't have all the skills. PMs are typically chosen for their ability to lead a product, which means they need to be well-organized, strong communicators, quick problem solvers, and capable of making rapid decisions. This is already a tall order when hiring, so unless it's a specifically technical role, companies won’t prioritize data analysis skills as much.

Second, this kind of analysis is really time-consuming. Product owners tend to be among the busiest people at most companies, and adding yet another complex process to their workload is a big ask.

If you had asked me four years ago, I would have agreed: it's simply not worth the effort to model a new task’s impact on revenue or company costs. But a lot has changed. AI now enables a single person to do far more than before. There are tools that can automate 90% of this analysis (I’ve even worked on one of them).

The amount of wasted engineering time I’ve seen is staggering—and I suspect it’s not even the biggest problem compared to lost revenue from suboptimal prioritization. And I don’t think that startup I worked for was an outlier; if anything, it was likely in the upper percentiles of efficiency compared to other tech companies.

But considering how dramatically AI is reshaping workflows across industries, I think product owners, too, need to rethink their approach. No matter the skill level, gut instinct is still just a guess—and if finance, science, and countless other fields are any indication, calculation beats intuition more often than not.