The role of product owners and designers in AI-first organizations

Most product teams were designed for a world where building was slow and expensive. Someone had to write the requirements, guard the backlog, and translate between the business and the people making the product. That someone was the product owner or product manager.

That world is ending. AI has collapsed the cost of making things. A designer can go from a customer problem to a tested, working concept in days. When building is cheap, the expensive part is deciding what is worth building. So the question every growth-stage leader should be asking is simple: who on the team is best equipped to make that decision?

Increasingly, it is not the product owner.

The case for cutting the role

Look at what a strong product designer already does today:

Frames the problem. Talks to customers, understands their real needs, and defines what is broken.
Shapes the solution. Turns that understanding into concepts, flows, and working prototypes.
Proves it. Puts ideas in front of real users before engineering commits a single sprint.
Defines it. Writes the decisions down clearly enough for engineering to build without guesswork.
Delivers it. Works alongside engineering through release, and measures whether it worked.

Now look at the traditional product owner. Their core output is the backlog: user stories, acceptance criteria, priorities. Every one of those artifacts is a description of something a designer has already understood more deeply, because the designer was in the room with the customer and built the thing being described.

When both roles exist, the work passes through an extra pair of hands. The designer learns something from customers. They explain it to the product owner. The product owner rewrites it as a ticket. Engineering reads the ticket and asks the designer what it means. That loop is not alignment. It is a translation tax, and fast-moving companies pay it on every feature.

The most expensive handoff in product development is the one between the person who understands the customer and the person who decides what to build.

There is a skills gap, too. Most product owners are not trained to research, design, or prototype. They are asked to make product decisions without the tools to test them. So they rely on opinion, stakeholder pressure, or the loudest request in the queue. Designers can settle those debates with evidence in a few days.

Two roles, moving in opposite directions

The modern PM and the modern designer are now at odds. AI tools have handed PMs the ability to generate screens, flows, and prototypes, and many are being asked to use them. But generating a screen is not the same as designing a product. Without the fundamentals of hierarchy, interaction, accessibility, and systems thinking, the output looks finished and fails in the hands of customers. Designers then spend their time reviewing and reworking it.

The reverse is not true. The PM workflow of writing requirements, managing a backlog, running planning, and reporting progress is learnable, structured, and increasingly automated. Designers pick it up quickly, and AI handles much of it for them.

PMs are being asked to design without the fundamentals. Designers can run the PM workflow with the tools they already have. Only one of those gaps is easy to close.

That asymmetry is the whole argument. When one role can absorb the other and the reverse produces lower-quality work, keeping both is a choice to pay for overlap.

The usual objections

The standard defense of the role sounds reasonable:

“Someone has to own the business outcome.” Designers already do. They are in the room when customers explain what they would pay for, and they see where revenue is won or lost in the product itself.
“Someone has to manage stakeholders.” Designers already do. Sales, support, legal, and leadership review their work every week. They are closer to those conversations, not further from them.
“Someone has to sequence the work with engineering.” Designers already do. They sit with engineers daily and know what is ready, what is risky, and what can wait.

Each objection describes work designers are already doing, usually with more context. The product owner is not filling a gap. They are duplicating a seat.

Do the math

Picture a team with five product owners and three designers. Five people describe the work. Three people actually understand the customer and shape the product. The designers become the bottleneck, and the product owners spend their days waiting on them, then translating what they produce.

Now picture eight product designers who think in business terms. Every one of them can frame a problem, prove a solution, and ship it with engineering. Same headcount. No translation layer. Nearly three times the capacity to do the work that actually moves the product forward.

Five product owners and three designers is a team built to talk about the product. Eight product designers is a team built to make it.

What changes in an AI-first team

AI does not just speed up design. It removes most of the work that justified a separate owner.

Requirements can be drafted from a designer’s decisions in minutes. Acceptance criteria can be generated from the design system. Backlog grooming becomes a short conversation instead of a weekly ceremony. What remains is the hard part: knowing which problems are worth solving and proving the answer before you invest. That has always been the core of good design.

The teams moving fastest right now share a pattern. They have fewer roles and shorter loops. One person owns the problem and the solution, works directly with engineering, and is accountable for the outcome. Call it a design-led product lead. The title matters less than the principle: the person closest to the customer makes the call.

A test for your organization

Ask these questions about your own team:

How many of your product roles can talk to a customer, design a solution, and test it, without help?
When a customer insight surfaces, how many people touch it before it becomes a decision?
If you removed the backlog for a month, would the team ship more or less?
Is your product owner deciding, or documenting decisions made elsewhere?
Are your designers trusted with business outcomes, or only with screens?

If the answers point to translation rather than leadership, you are paying for a role your operating model no longer needs.

The bottom line

This is not an argument against people. Many product owners are capable leaders who would thrive with broader ownership. It is an argument against a structure built for a slower era. In a growth company, every layer between the customer and the decision costs time, money, and clarity.

Design that can frame, prove, and deliver is the most efficient path from problem to revenue. Put your headcount there.

Try this week: count the people on your product team who describe the work, and the people who make it. If the first number is bigger, you know where your next hires should go.

Then: map one recent feature from first customer insight to release. Count the handoffs, and ask which ones added judgment and which ones only added time.