Anyone Can Build. Who Owns the Outcome?

A product manager built a working prototype with AI.

Engineering looked at the generated code and gave a direct answer: none of it could be used. It would need to be rebuilt.

The team was left with an uncomfortable question.

If engineering had to rewrite everything, what exactly had the product manager contributed?

I heard this while speaking with product and technology leaders about how AI should change their teams. Product used to write requirements. Design made the interface. Engineering wrote code. Marketing created the campaign.

Now each role can produce some version of the others' work. That can make the roles look obsolete.

I came away with a different conclusion: we had confused the artifact with the job.

Disposable code can still reduce uncertainty

The engineer may have been right about the code. A generated prototype may fail production standards for reliability, security, or maintainability.

It can still make an ambiguous idea concrete. A customer can react to an experience instead of a document. The team can expose a missing interaction before engineering commits to the real build.

The product manager may have reduced product uncertainty. Engineering still had to make the system real for customers.

Those are different jobs.

Small teams taught me why this matters

Inside our company, the same person may talk with a customer, investigate the problem, prototype a solution, help implement it, and examine what happened afterward.

AI lets more people move across that workflow. Much of the speed comes from keeping the same customer context and tradeoffs in one person's head instead of handing them across four functions.

A field experiment at Procter & Gamble found a similar effect on a bounded product-innovation task. Individuals using AI performed as well as two-person teams without it, and commercial and technical professionals produced more balanced ideas. Human judgment still added value when selecting among them. The Cybernetic Teammate

AI can help fewer people contribute across more of the work. That makes ownership more important, not less.

I now define a role by what the person owns

When a role starts to blur, I ask three questions:

1. What decision is this person trusted to make?

2. What quality are they responsible for?

3. What failure should they catch or escalate?

Product owns which user problem matters. Design owns whether the interaction works for the user. Engineering owns whether the system can run safely and reliably. Marketing owns whether the promise is truthful and reaches the right audience. Leadership owns how those decisions fit together.

People should still cross those boundaries. Engineers should challenge the problem. Product managers should understand technical tradeoffs. Designers should care about implementation.

But crossing a boundary is not the same as removing responsibility.

If this goes wrong for a real customer, who was expected to notice, decide, and take responsibility?

That question tells me more about a role than a list of artifacts ever did.

What the product manager contributed

I return to the prototype engineering planned to rebuild.

If it helped the team test a user need, expose a tradeoff, or change what engineering would build, the product manager did meaningful product work.

If it only made an untested idea look real, AI had made the wrong artifact more convincing.

The engineer's rewrite did not make the prototype pointless. The prototype did not make the engineering work complete.

AI made the artifact easier to create. It also made the harder question impossible to avoid: who owns the outcome?