Idea

A consumable artifact can ground a function, not a profession

Info

Originally written in French. Translated by AI — the meaning has been preserved, not the prose.

Main idea

The main argument in favour of the Product Owner rests on the backlog: the role is said to maximize the product's value by keeping it, refining it and prioritizing it. But a backlog item is useful up to delivery and afterwards loses most of its value. Tickets and specifications drift out of sync, trade-offs change during implementation, and the final behavior in production differs from what was written. The backlog is neither the product's memory nor the place where you think it: ticket tools remain card tools, where you push the result of thinking already structured elsewhere.

Keeping an artifact that gets consumed is real work, and it can be done excellently. But it leaves nothing behind on which expertise accumulates. That is the definition of a function: an assignable, redistributable task whose value is exhausted along with its object. A profession assumes that the practice deposits something that lasts.

This argument owes nothing to automation: it already held when tickets were written by hand.

Layer added by "PM, Developers, and AI: Roles Are Blurring, Responsibilities Remain" (2026-08-01). The distinction also works the other way round, on needs that don't yet have a name. Evaluating probabilistic outputs, keeping a product memory, orchestrating chains of agents, maintaining documentation a machine can use: these responsibilities become central in a tooled-up team without any of them necessarily becoming a position. Some will stabilize into titles, others will remain competencies distributed across the team, others again will be absorbed by Product Ops, design, engineering or QA. The same criterion settles it: what is durably deposited in whoever practises it can ground a profession, the rest stays a function to be assigned.

Why it matters

This moves the debate about the role from a terrain of opinion to an examination of its support: what does it rest on, and does that object last?

And it applies to any role defined by the upkeep of an intermediate artifact — minutes, tracking matrices, coordination dashboards.

Nuances and limits

The reasoning pushes you to underestimate what keeping a disposable artifact does deposit anyway: a fine knowledge of the product, of its uses, of its debts, which stays with the person even after the tickets are gone.

And the boundary between function and profession depends on social conventions as much as on the nature of the object: a profession can form around entirely perishable work as soon as a market, a training path and a community recognize it.

Open questions

  • What durable object could a role centred on coordination produce, that is neither the documentation nor the product itself?