Why Product Owners Are Becoming Obsolete
The role that was supposed to bridge business and technology is now the bottleneck. Here's what's replacing it.
The Product Owner role emerged from Scrum as the answer to a real problem: developers needed someone to represent customer interests in the development process. Someone to prioritize the backlog, clarify requirements, and make trade-off decisions.
For a while, it worked. Product Owners became the bridge between business stakeholders and development teams. They translated customer needs into user stories, negotiated priorities, and ensured the team was building the right things.
But something changed.
The Bottleneck Effect
As software teams scaled, the Product Owner became a bottleneck. Every decision, every clarification, every priority call had to flow through a single person. Teams waiting for PO availability. Stakeholders frustrated by delayed feedback. Developers building in the dark because the PO was in another meeting.
The solution? Add more Product Owners. But this created its own problems: inconsistent decisions, conflicting priorities, and even more translation layers between customers and code.
Enter the Product Engineer
The most effective teams have discovered a different approach. Instead of funneling all customer context through a single role, they’re distributing product thinking across the engineering team.
Product Engineers don’t just write code—they understand customers. They participate in user research. They analyze usage data. They make product decisions autonomously, within strategic guardrails set by product leadership.
“The best code comes from developers who understand why they’re writing it.”
What This Means for POs
This doesn’t mean Product Owners disappear overnight. But their role is evolving. The most forward-thinking POs are becoming:
- Product Strategists: Setting direction rather than managing backlogs
- Customer Champions: Ensuring customer voice is heard, not filtering it
- Coaches: Helping engineers develop product thinking skills
The backlog grooming, ticket writing, and requirement clarification that consumed most PO time? That’s being automated or distributed to engineers who can handle it themselves.
The Data Supports This
Organizations that have shifted to product engineering models report:
- 40% faster feature delivery
- 60% reduction in “clarification” meetings
- Higher developer satisfaction and retention
- Better customer outcomes (features actually get used)
The broken telephone problem—customer needs getting lost in translation—is solved not by adding more translators, but by removing the need for translation altogether.
This article is adapted from Chapter 3 of “The Broken Telephone: From Product Owner to Product Engineer.” The book goes deeper into the organizational changes, skill development, and cultural shifts required to make this transition.
John Macias
Author of The Broken Telephone