Main idea

When producing and maintaining documents, tickets and reports absorbs most of a Product Manager's days, that production ends up defining the position: you hire on it, you evaluate on it, you describe it in job specs. Not because it was judged essential, but because it occupied the space.

Cost acts here as misleading proof: what is heavy looks important. A task that takes six hours a week becomes an object of reporting, a displayed skill, a professional identity.

The demonstration runs backwards, and it is brutal: when the cost of that layer collapses, you discover it wasn't the job. Nothing else changed — not the product, not the market, not what was really expected of the role.

The mechanism doesn't stop at defining an existing position: it manufactures new ones. When the layer gets heavy enough, it is given a title of its own — Product Owner — and a job spec built around passing information along. The position then inherits the same fate as the definition: it was justified by a cost, and it becomes hard to defend once that cost falls.

Layer added by "The PO Is Not a Job, It's a Function — and AI Doesn't Change That, It Accelerates It" (2026-08-03).

Layer added by "PM, Developers, and AI: Roles Are Blurring, Responsibilities Remain" (2026-08-01). The mechanism also plays out inside a job, on what set its practitioners apart from one another. Writing a solid spec, producing a first data analysis, running a benchmark, drafting a release note, making an acceptable mockup, synthesizing interviews: these outputs differentiated Product Managers from each other as long as they stayed expensive. When they become accessible, they don't leave the job — they move from distinguishing mark to minimum bar, and those whose value rested on that intermediate execution lose it without anything about the product or the market having changed.

Why it matters

This explains why automation is experienced as an identity threat rather than a gain: it doesn't only remove hours, it removes what made the skill visible.

And it gives a useful retrospective test: what disappears without anyone trying to restore it was not the core of the job.

Nuances and limits

The collapse of a cost doesn't on its own prove the layer was incidental. Some heavy tasks are heavy because they are genuinely decisive, and automating them silently degrades the result.

And an incidental layer can carry real side effects: writing a spec by hand forces you to read it, and that detour disappears with the chore.

Open questions

• Before automating it, how do you tell a heavy incidental task from a task that is heavy because it is decisive?