Four years ago I wrote about a frustration I saw every day: UX people reduced to wireframe machines. Product Owners reduced to backlog pushers. People with deep expertise using a fraction of it, because the system demanded no more from them. The deadline had to be hit. The feature had to ship. Polish could be sprinkled on at the end.
That frustration has been sitting there ever since. Now something is changing it.
AI doesn’t move bricks in a product organization. It moves questions. For years, the most important question was whether we could make the release. It should now be whether we should build the thing at all.
When prototypes can be built over a weekend, the question actually gets harder to ask. The CEO is already in love with his own demo, and the PM asking for time to investigate is holding a weaker hand than before. AI doesn’t make the build trap easier to escape. It makes it deeper. That’s the real job of this layer: pulling off a shift in which question carries weight, toward an organization that does the opposite.
When that shift lands, the entire identity of a product team gets turned upside down.
The old identity is built on execution
Who you are as a product leader has historically followed what you produce. The PM writes requirements. The designer makes mockups. The developer builds. Three roles, three streams of work, one division of labor.
That division no longer holds. When a designer can build a working prototype with Claude Code, and a PM can code an MVP in an afternoon, the split collapses at the execution level. The roles live on, but the boundary between them is no longer set by who can find the keys.
That’s the easy half of the point. The hard half comes now.
Identity has to move from “what I make” to “what I vouch for”
If your identity as a product leader is built on writing requirements, you’re in trouble. AI writes better requirements than most PMs.
If your identity as a designer is built on making wireframes, you’re in trouble. AI makes wireframes faster than you can describe them.
That doesn’t make the PM or the designer redundant. But their identity can no longer live in the output. It has to move: from I’m the one who makes X to I’m the one who vouches for X being the right thing.
Marty Cagan’s four product risks are a useful place to put the new identity. The risk areas don’t collapse just because execution flattens out. They change character:
- The feasibility boundary moves outward: what used to take six months of architecture can be built in a week. But the risk doesn’t disappear. It moves from “can we build it” to “can we run it in production without maintenance eating the team”. AI-generated code is still code that has to be understood, debugged and maintained.
- Value becomes more important, not less. When the cost of building falls, the price of building the wrong thing rises.
- Usability moves from UI details to the whole chain of experience, from first touchpoint to support.
- Viability has to be pulled in earlier. You can no longer park the question of can we make money on this until after the MVP.
Four areas of responsibility a product team has to cover, distributed deliberately among people who can touch everything.
The build trap gets worse, not better
Melissa Perri wrote Escaping the Build Trap in an era when building was expensive. When it took months, resources, business cases. Even then the build trap was a real problem: companies built things because they could, not because they should.
Take that world. Make the cost of building marginal. Remove the natural brake that this will take six months used to be. The build trap gets deeper. More subtle. Harder to escape.
That’s the counterintuitive point about AI acceleration. It doesn’t solve the problem of building too much of the wrong thing. It makes it worse. And it makes the most important part of product management, saying no, waiting, investigating, harder to defend in an organization where everyone else can build right away.
The principle I would write on the wall of a new team is short:
The customer’s problem before our solution.
An identity statement. Our job is to choose more sharply, not to produce more.
Decision quality is the new bottleneck
John Cutler distinguishes between decision quality and execution quality. AI accelerates execution. Decision quality hasn’t kept up, and can’t keep up, because it comes from somewhere else. It comes from context, judgment, understanding users, understanding the business, the courage to say no.
That’s the new bottleneck. And that’s where the product team should put its identity.
So what does judgment actually consist of, once you strip away the word and look at the work? Four things I see again and again in people who make sharp product decisions:
- Domain knowledge, the deep understanding of the customer, the industry, the problems that aren’t written down anywhere.
- Discovery discipline, the habit of testing assumptions before building on them.
- Output evaluation, the ability to read an AI-generated prototype, a piece of code, a PRD, and spot where it limps, without having produced it yourself.
- The courage to say no, not as an attitude, but as a practice, every week, in concrete cases.
The rest of the playbook is about how those four things get built.
A recent study from Microsoft Research confirms the pattern. 885 product managers answered how AI is changing their work, supplemented with telemetry and in-depth interviews (Ulloa et al., 2025). One sentence stands out: accountability must not be delegated to non-human actors.
That’s the foundation of the culture layer. AI can generate. It can execute. It can suggest. But it cannot carry the responsibility when something goes wrong, and if the responsibility for a decision doesn’t sit with a human, it sits nowhere.
The product leader’s new identity: the judge who carries the responsibility when the AI is wrong.
The liberation nobody talks about
There’s a point hidden in this that’s easier to see than to pull off. UX people and POs are, in principle, freed to move from execution pressure to craft. In practice, many don’t react with gratitude. They react with resistance to the AI that just abolished their visible contribution. That resistance is rational: their careers are built on the artifact that can now be generated.
When a developer can generate a UI in five minutes, nobody can keep a UX designer in the corner with the words we just need a few sketches. When AI can empty a backlog faster than a team can refine it, a PO can no longer hide behind tickets. The execution pressure, the excuse for why people never got to use their expertise, falls away.
A liberation, if you can find your new identity in it.
The liberation isn’t free. It requires leadership to actively rebuild the reward system away from visible output. I haven’t seen a single organization that has finished that work.
What it means in practice
Three principles a team can test itself against:
- The customer’s problem before our solution.
- The question is not whether we can, but whether we should.
- AI can generate everything. We vouch for it.
That’s the cultural frame everything else has to hang on. If it isn’t clear, organizational structure, skills, processes and tools will pull in different directions.
That’s why culture sits at the top of the pyramid.