The Ownership Map
Ownership is not who produces the thing. Ownership is who breaks the tie. Everyone can contribute to every row. Exactly one function owns each decision, and the owner is accountable for the outcome...
The template
The Ownership Map
One page you can put on a wall. When design, PM, and engineering can all generate, the old handoff boundaries stop describing anything real, and the argument moves from "who does the work" to "who decides." This map answers the second question. Fill it in with names, print it, and let people disagree with it out loud rather than quietly in reviews.
The rule that makes the map work
Ownership is not who produces the thing. Ownership is who breaks the tie. Everyone can contribute to every row. Exactly one function owns each decision, and the owner is accountable for the outcome, not for the output.
Two failure modes this is built to prevent. Shared ownership of a decision, which means the loudest person decides and nobody is accountable. And ownership assigned by who happens to have capacity, which means the boundary moves every sprint and no one can plan against it.
The map
Fill the owner column with a function, then a name underneath. A row with a function but no name is not owned.
| Decision | Owner | Consulted | Notes |
|---|---|---|---|
| What problem we are solving | PM | ||
| Which users we are solving it for | PM | ||
| What the product will not do | Design | The refusal set is a design artifact | |
| The constraint set for a surface | Design | Rule plus failure condition | |
| The acceptable range of generated output | Design | Best, worst acceptable, refuse | |
| The quality rubric and its dimensions | Design | Versioned, scored, argued about | |
| When output is good enough to ship | Design | Against the rubric, not vibes | |
| The wrong path: recovery, disclosure, correction | Design | First-class surface, not overflow | |
| Latency and cost budgets per surface | Engineering | Design sets the experience band | |
| Model, retrieval, and tooling choices | Engineering | ||
| What gets instrumented | PM | Design owns what the events must answer | |
| Sequencing and what ships this quarter | PM | ||
| Whether a decision gets reversed | Original owner | Reversal follows the decision record |
Adjust the rows to your product. Do not adjust the rule that every row has one owner.
The three boundaries that actually get fought over
Write your team's answer next to each. These are where the map earns its keep.
1. Who decides when output is good enough. The honest default in most teams is whoever is in the room at the end. Put it in writing instead. If design owns the rubric, design owns this call, and the rubric is what makes the call reviewable rather than personal.
Your answer: _______
2. Who owns the prompt or the system instructions. This one is new and it is contested, because the prompt is simultaneously copy, behavior spec, and code. The workable split: design owns what the behavior must be, engineering owns how it is implemented and evaluated, and neither ships a change to it alone.
Your answer: _______
3. Who owns the failure states. Everyone agrees these matter and nobody wants the ticket. Name the owner before launch. An unowned failure state is discovered by a customer.
Your answer: _______
What each function owns, in one line each
Design owns the specification of behavior. Constraints, ranges, rubrics, refusal, recovery, disclosure. What the product does across every state, including the ones nobody drew.
PM owns the problem and the sequence. Which problem, for whom, in what order, against what outcome. PM does not own quality; PM owns whether the right thing is being made at all.
Engineering owns the mechanism and the budget. How it works, what it costs, how fast it is, whether it holds under load and under failure.
The overlap is not a problem to eliminate. The overlap is where the work is good. What matters is that the tie-break is named in advance.
Running it
Print it. Put names on it. Then two habits:
Review it once a quarter, not once. Ownership drifts as the product changes, and a map from two quarters ago is a source of arguments rather than a way to end them.
When a decision gets escalated, the first question is which row it belongs to. If the answer is "none of them," you found a missing row, and that is the most valuable thing the map does.
The one thing to do this week
Fill in the three contested boundaries above with names, not functions. Send it 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.
From "What Design Owns Now", chapter 4 of The Design Operating Model. falkster.com/design/what-design-owns-now