The old boundary was a handoff. PM writes the requirement, design makes the thing, engineering builds it. Everyone knew where their part started because it started when someone else's file arrived.
That line did not move. It dissolved.
A PM can generate four working directions before kickoff, an engineer can produce an interface that looks designed without asking anyone, and a designer can ship a working prototype without a ticket. So ownership gets redefined around the only thing still scarce: who decides. Everyone can contribute to every row. Exactly one function breaks the tie, and that function is accountable for the outcome rather than the output.
Design owns the specification of behavior. Concretely, six rows: what the product will not do, the constraint set for a surface, the acceptable range of generated output, the quality rubric and its dimensions, when output is good enough to ship, and the wrong path of recovery, disclosure, and correction.
PM owns the problem and the sequence. Which problem, for whom, in what order, against what outcome, plus what gets instrumented. Design owns what the events have to be able to answer, which is a different thing, and the reason design belongs in that conversation early, before somebody else's dashboard is already built.
Engineering owns the mechanism and the budget. Model, retrieval, and tooling choices. Latency and cost budgets per surface, with design setting the experience band those budgets have to fit inside.
And reversal belongs to the original owner of the decision, following the decision record, so a reversal has to argue with the original reasoning.
Three boundaries are where this earns its keep, and the rest of the map is uncontroversial once written.
Who decides when output is good enough. The honest default in most teams is whoever is in the room at the end, which is an accident that keeps repeating. If design owns the rubric, design owns the call, and the rubric makes it reviewable instead of personal.
Without one, the design leader becomes the only quality gate in the company, which caps the product at the number of things one person can look at.
Who owns the prompt. Contested for a good reason: it is copy, behavior spec, and code at once. The split that works is design owning what the behavior must be, engineering owning implementation and evaluation, and neither shipping a change alone.
Who owns the failure states. Everyone agrees they matter, nobody wants the ticket, so they float. An unowned failure state is discovered by a customer. Name the owner before launch, in writing.
Two failure modes the map exists to prevent.
Shared ownership of a decision, which sounds collaborative and means the loudest person decides. And ownership assigned by whoever has capacity this quarter, which moves the boundary every sprint so nobody can plan against it.
Two rules for running it. Fill the owner column with a function and then a name underneath, because a row with a function but no name is not owned. And review it once a quarter rather than once, because a map from two quarters ago generates arguments instead of ending them.
The most useful habit attached to the map: when a decision gets escalated, the first question is which row it belongs to. If the answer is none of them, add the row.
One thing to do this week: fill in the three contested boundaries with names, not functions, and send them to your PM and engineering counterparts with one line. Here is what I think I own, tell me where I am wrong. The disagreements that come back are the real map. Everything they agree with was already settled.
The full one-pager with all thirteen rows, the consulted column, and the boundary prompts is The Ownership Map. The long version is What Design Owns Now.