The Death of the Product Owner

Welcome to the attention economy

AI is creating superabundance, and product teams are feeling it from both directions. They can build and test more ideas while their customers are already saturated with content, tools, and competing demands. As I related to my good friend Jason Ling, “We need to be so focused on strategy because you can do anything.” The compression of work changes where time is worth spending; choosing what deserves sustained attention becomes a much more consequential part of the job.

I was very big on process when engineering capacity was the bottleneck. Research became requirements, requirements became specifications, and design produced mockups before engineering could build. Now one of my lead PMs is prototyping while the developers are occupied with other work, taking an idea far enough to evaluate before involving an engineer to scale it. The process around the work can become the constraint when people no longer need every handoff to make progress.

This shift came up at ProductCon New York earlier this year in Jefferson Rabb’s talk on product velocity. The Business Insider CPO described engineering moving faster and product becoming the bottleneck. In the organizer’s recap, he asked, “If capacity is no longer the dominant prioritization concern,” then “is this thing a good idea?” Teams need a faster, more flexible way to answer that question as the cost of exploring an idea falls.

Jason is already changing the way his team works at UptimeHealth, which helps dental, medical, and veterinary practices maintain equipment and arrange repairs. Our conversation got into how AI changes the contribution expected from product people, the way ideas develop, and the structure of the teams responsible for them.

What's actually dying

Product owner and product manager mean different things across companies. In the distinction Jason and I were discussing, the product owner administers delivery through backlog management, story refinement, and coordination. In contrast, the product manager carries broader responsibility for customer understanding, strategy, and business value. Plenty of people do both. The work most exposed to AI is the administration, regardless of the title attached to it.

A well-maintained backlog becomes harder to justify as someone’s primary contribution when software can generate tickets and organize the requirements. Product people need to explain why an idea deserves investment and stay accountable for whether it helps customers. Jason’s hiring questions get directly at that: “Can they think big picture? Can they think business?” Roles built around overcomplicated processes will disappear, and the processes themselves will need to be rebuilt in a much leaner form.

Three implications for product teams

• Smaller teams will carry broader responsibilities across product, design, and engineering.
• Prototype-driven development will bring feedback and technical judgment into the work earlier.
• Leaner processes will require clear ownership and stronger prioritization.

Smaller teams, bigger jobs

I expect teams of eight to twelve people to move toward groups of three to five, depending on the product and the support it requires. Fewer people means fewer handoffs, more meaningful individual work, and greater responsibility for the result. It can also mean paying more for someone who contributes across disciplines while spending less on the team overall. T-shaped skills combine depth in one discipline with an understanding of others; M-shaped skills bring depth in several. Those combinations become more useful when each person can take an idea further without waiting for another department.

I still see value in a product, design, and engineering trio, even as those capabilities overlap. Someone needs to own the business decisions, someone the design decisions, and someone the engineering decisions. A PM who can prototype needs an engineer’s judgment about production, just as an engineer benefits from understanding the customer’s problem. Broader skills should make collaboration more effective while keeping responsibility clear.

Prototype-driven product development

Jason and his designer begin with working prototypes, using a design system to keep them consistent. During a conversation with his chief revenue officer, he had Claude open and was prototyping as they talked, giving them something to react to immediately. Stakeholders and engineers get involved early, the team revises the idea, and the designer works through the finer details. Once it is sufficiently developed, AI generates tickets that Jason reviews before engineering reviews them and adds them to the backlog. The documentation follows a conversation informed by something people have actually used.

Jason described reaching initial feedback in about three days for work that might previously have taken two weeks of research, meetings, and PRDs. That is his experience, but the sequence is useful for other teams to examine. It also makes engineering judgment more important: a convincing prototype can conceal substantial integration and reliability work. As he said, “the engineering team keeps the product team honest.” They need to be involved before a demo becomes a promise to a customer.

Leaner processes, clearer ownership

I’m moving toward more chaordic systems that combine order and chaos, allowing people to experiment without losing accountability. Teams need autonomy to explore, clear decision owners, and specialist review when failure carries a meaningful risk. We’re in a weird AI puberty phase, with capabilities changing faster than working habits. Excessive process can stall a team, while too little can become a chaotic shitshow. Leaders have to determine which decisions people can make independently and where the organization needs greater control.

That also requires stronger prioritization. Generating more prototypes creates more demands on the people who must evaluate, support, and improve them. Teams need criteria for continuing an experiment, changing direction, or stopping, along with the discipline to defer other work. Customer attention is already saturated; creating another feature is useful only if it earns continued use and supports a business outcome.

How to prepare for the future of product

Develop expertise across disciplines

Use real work to build judgment outside your specialty. A PM can prototype a customer problem and review it with design and engineering; an engineer can join discovery conversations and connect technical decisions to the customer’s workflow. Retain depth in your discipline while learning enough about the others to recognize what you missed and work through it with your colleagues.

Practice discovery through prototypes

Test a specific assumption with a rough working version before committing to a detailed build. Give customers and colleagues something they can interact with, observe where their responses differ from your expectations, and revise accordingly. Jason’s workflow keeps product, design, and engineering involved as the idea develops so that the team can address customer feedback and technical constraints together.

Take responsibility for outcomes

Define the customer benefit, business outcome, and evidence that would justify further investment. Jason described building a prototype after a sales conversation and hearing, “When can we have this?” That response is encouraging, but the team still needs to determine whether the delivered product earns ongoing use. Product people should be able to connect the initial problem to the result after release.

Prioritize and limit distractions

Review the portfolio and the process together. Protect the work that deserves sustained attention, defer competing initiatives, and remove steps that add administration without improving a decision or managing a meaningful risk. Leaders need to protect focus as deliberately as they once protected engineering capacity.

I’m excited about people gaining more control over their work and taking on bigger problems. The product people I want on my team understand the business, work across disciplines, and stay accountable for what reaches the customer. Their judgment determines where all this new capability is worth spending.

What You Should Read

The Dot and the Swarm

Ethan Mollick; One Useful Thing; October 1, 2026

Mollick revisits his assumption that humans would need to organize groups of AI agents carefully. His argument connects directly to this issue: as coordination becomes easier, deciding where to direct the work becomes more consequential.

Gemini 4 Argon: our next era of frontier intelligence

Koray Kavukcuoglu; Google; September 30, 2026

Google’s launch post describes its new model’s work on software engineering, complex professional tasks, and cybersecurity. Access is beginning with trusted cyber defenders and testers before a broader release.

Function-preserving watermarking of AI-generated proteins

David Stutz and colleagues; Nature; September 30, 2026

Watermarking is moving into biology. This research explores how AI-generated protein sequences and structures can carry a detectable signature while preserving function in the tested designs, raising questions about provenance and scientific integrity.

The ugly economics of consumer AI

Russell Brandom; TechCrunch; September 30, 2026

Consumer AI adoption can grow while willingness to pay remains limited.

AI godfathers warn of runaway ‘intelligence explosion’

Dan Milmo; The Guardian; September 28, 2026

Researchers urge preparation for accelerated AI research and development.

Who You Should Follow

Jason Ling

Jason’s conversation shaped this issue. Follow him for his perspective on AI prototyping, working with designers and engineers, and what product people need to contribute as the work changes.

Paweł Huryn

Paweł shares practical guides for product managers learning to prototype, build, and bring a product to its first users. His Product Compass is useful for readers who want to start doing more of the work themselves.

Marty Cagan

Marty writes about the decisions and leadership that make product teams effective. His recent posts challenge the assumption that AI makes experienced product leadership less necessary.

Aakash Gupta

Aakash’s Product Growth interviews get into how product teams use AI, how roles are changing, and what those changes mean for a product career.

Sachin Rekhi

Sachin writes about using AI in product discovery, prototyping, and everyday product work. His guides connect hands-on building with the decisions product managers still need to make.

Where You Should Go

Philly Builds AI Founder Series with Jake Stein

October 6; Philadelphia. A conversation with Common Paper co-founder Jake Stein about building companies, testing customer problems, and deciding when to pivot. Registration requires host approval; approved attendees receive the address.

Executive Dinner on Leveraging AI Agents

October 7, from 7 p.m.; Philadelphia. StackAI is hosting technology leaders for a discussion of agent governance, costs, use-case selection, and business value. Registration requires host approval, and the location is shared with registrants.

EPIC Responsible AI Wellness Usage Conference

October 15, 10:30 a.m.–1:30 p.m.; Life Sciences Pennsylvania. An in-person conference on responsible AI in wellness.

Advancing Human Judgment in an AI World

October 16, noon–1 p.m.; online. Inquiry Institute’s session is for leaders, coaches, consultants, and professionals interested in using AI thoughtfully while strengthening the quality of their results.

Claude Code vs. Codex: Loops, Graphs, and Harnesses

October 17, 1–4 p.m.; Turkish Brew, Philadelphia. Bring a laptop and a project to this Coffee & Code Philly pair-programming meetup. Compare tools, debug agent workflows, and test generated changes with other builders. Experience with either tool is optional.

Copyright 2026 - Christie Mealo