Who Does What Now

Product Manager's (PM) say they can code. Engineers say they can do product. AI handed everyone a new set of tools, but it didn't hand anyone a new set of skills.

The Lines Are Blurring

Something interesting is happening inside product and engineering teams right now.

Product managers are opening code editors for the first time, using AI to generate working prototypes they couldn't have built six months ago. Engineers are producing polished product requirements and user research summaries with AI assistance, tasks that once belonged exclusively to PMs.

The lines that defined who does what are blurring. That is creating real tension around ownership, accountability, and the purpose of each role.

Lowering Barriers, Not Raising Expertise

Let's be precise about what AI is enabling here, because the hyperbole is running ahead of the reality.

A PM using AI to generate code is not becoming an engineer. They are producing a functional prototype that demonstrates intent. That prototype still needs to be reviewed, hardened, and maintained. It requires someone who understands what is underneath the hood. The PM made the first mile faster. They did not make the whole journey shorter.

An engineer using AI to produce a Product Requirements Document (PRD) is not becoming a PM. They are generating a structured document. That document still needs to reflect genuine user insight, organizational strategy, stakeholder alignment, and prioritization decisions that require judgment the AI does not have. The engineer produced a draft. The PM work hasn't gone anywhere.

What AI has done is lower the barrier to entry for adjacent tasks but not eliminate the expertise required to do them well.

🚀 MARTY SAYS

"Anyone can use a flight simulator. That doesn't mean anyone can land a plane in a crosswind. The tool and the judgment are different things."

The Real Tension

The friction isn't really about who can do whose job. It is about accountability.

When a PM-generated prototype gets shipped with a security flaw, who owns that? When an engineer-written PRD leads to a product nobody uses, who's responsible? When AI wrote half of both, the answer gets murky fast.

This is not a hypothetical. It is already happening in organizations that moved fast on AI adoption without thinking through the governance layer. The speed was real. So was the confusion about who was responsible when things went sideways.

The answer isn't to restrict who uses what tools. It is to be explicit about who owns what outcomes, regardless of which tools were used to get there.

THE OWNERSHIP FRAMEWORK

The question is not "who built it?" It is "who is accountable for it?" In product and engineering, that answer should not change because AI was involved. If a PM owns the product decision, they own it whether they used AI or not. If an engineer owns the implementation, same rule applies. Tools change. Accountability doesn't.

Safe Harbor: Three Things You Can Do This Week

Have the accountability conversation with your team. Not about AI tools but about outcomes. Who owns what? Make it explicit before AI involvement makes it ambiguous.
Try the adjacent task. If you're a PM, use AI to generate a prototype. If you're an engineer, use AI to draft a product requirements document. Not to replace the other role but to understand what the tool can and cannot do, and where the real expertise still lives.
Review one recent AI-assisted deliverable. Ask honestly: if this had been produced without AI, would the quality be different? The answer will tell you something important about where the real value is being added.

Next week: Prompt Engineering was the 'sexiest job' of 2023. Today, the title is vanishing. We look at where those people and skills actually went.