What Design Owns Now
When design, PM, and engineering can all generate, the old handoff boundaries stop describing anything. The argument moves to who decides.
The short version
- Design owns the specification of behavior: the constraint set for a surface, the acceptable range of generated output, the quality rubric, the call on when output is good enough to ship, what the product refuses to do, and the wrong path. PM owns the problem and the sequence. Engineering owns the mechanism and the budget. The reason the old boundaries stopped working is that they were drawn around production, and production is no longer scarce for any of the three functions. So ownership gets redefined as who breaks the tie, one named function per decision, reviewed quarterly.
- The old boundary was a handoff. PM writes the requirement, design makes the thing, engineering builds it. Everyone knew where their part started because their part started when someone else's file arrived.
- That line is gone. It did not move, it dissolved. A PM can now generate four working directions before the kickoff meeting. An engineer can produce an interface that looks designed without asking anyone. A designer can ship a working prototype without a ticket. Everybody can make everything, badly or well, at speed.
- Which means the interesting question is no longer who does the work. It is who decides.
Ownership is who breaks the tie
Be literal about that. Everyone can contribute to every decision, and exactly one function owns each one, and owning it means accountability for the outcome rather than the output.
Two failure modes this is built to prevent, and both are common enough to be recognizable.
Shared ownership of a decision. It sounds collaborative.
In practice it means the loudest person in the room decides and nobody is accountable afterward. Every team that says "we decide quality together" is describing a process where quality is decided by whoever has the most energy at 4pm on a Thursday.
Ownership assigned by capacity. Design owns the empty states this quarter because the designer had time. Next quarter engineering owns them because the designer did not. The boundary moves every sprint and nobody can plan against it, so nobody plans.
The rows
Fill the owner column with a function, then a name underneath it. A row with a function but no name is not owned.
| Decision | Owner |
|---|---|
| What problem we are solving | PM |
| Which users we are solving it for | PM |
| What the product will not do | Design |
| The constraint set for a surface | Design |
| The acceptable range of generated output | Design |
| The quality rubric and its dimensions | Design |
| When output is good enough to ship | Design |
| The wrong path: recovery, disclosure, correction | Design |
| Latency and cost budgets per surface | Engineering |
| Model, retrieval, and tooling choices | Engineering |
| What gets instrumented | PM |
| Sequencing and what ships this quarter | PM |
| Whether a decision gets reversed | Original owner |
Adjust the rows to your product. Do not adjust the rule that every row has exactly one owner.
A few of those deserve a note. The refusal set is a design artifact, because what a product declines to do is an experience decision before it is a policy decision. Latency belongs to engineering as a budget, and design sets the experience band it has to fit inside. Instrumentation belongs to PM, and design owns what the events have to be able to answer, which is a different thing and the reason design has to be in that conversation early rather than reading a dashboard someone else specified. The mechanics of that live in Ship With Observability.
The three boundaries that actually get fought over
Everything else on the map is uncontroversial once written. These three are where it earns its keep.
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 repeats rather than a decision process. If design owns the rubric, design owns this call, and the rubric is what makes it reviewable rather than personal. The failure mode without one is a design leader who is 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. This one is new and it is fairly contested, because a prompt is copy, behavior specification, and code at the same time, and each function has a legitimate claim on one of those three. The split that works: design owns what the behavior must be, engineering owns how it is implemented and evaluated, and neither ships a change to it alone. Leave it unassigned and it gets written by whoever is closest to the code at eleven at night, and then the product's voice is whatever that person was in the mood for.
Who owns the failure states. Everybody agrees these matter. Nobody wants the ticket. So they float, and an unowned failure state gets discovered by a customer.
Name the owner before launch, in writing, on the map.
What each function owns in one line
Design owns the specification of behavior. Constraints, ranges, rubrics, refusal, recovery, disclosure. What the product does across every state, including the ones nobody drew. The method for writing those is in Specifying Behavior, and the scoring side of it borrows its mechanics from The Eval Is The Spec.
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, which is a bigger job than it sounds and gets smaller every time a PM starts adjudicating spacing.
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.
Overlap between the three is where the work is good, so nobody should be trying to remove it. What matters is that the tie-break gets named before the tie happens, because a tie-break negotiated during a disagreement is not a tie-break, it is a fight with an agenda item.
Running it
Print it. Put names on it. Then two habits.
Review it once a quarter rather than once. Ownership drifts as the product changes, and a map from two quarters ago generates arguments instead of ending them.
And when a decision gets escalated, make the first question which row it belongs to. If the answer is none of them, you just found a missing row, and that is the most valuable thing this map ever does. New surfaces in AI products keep producing decisions that no existing row covers, which is precisely why the boundary keeps getting fought over in the first place.
This week
Fill in the three contested boundaries with names, not functions. Then 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 and did not need writing down.
The full one-pager, with all thirteen rows, the consulted column, and the three boundary prompts, is in The Ownership Map. The short version for a conversation with a skeptical PM is What does design own when everyone can generate?
Chapter 4 of a series on the design operating model. Next: Part II opens with why there is no final state to draw, and what a spec looks like when output is assembled at runtime.
Take the template
One-page ownership map
Frequently asked
What does design own when PMs and engineers can also generate interfaces?+
Design owns the specification of behavior: the constraint set for a surface, the acceptable range of generated output, the quality rubric, when output is good enough to ship, what the product refuses to do, and the wrong path of recovery, disclosure, and correction. PM owns the problem and the sequence. Engineering owns the mechanism and the budget. Everyone can contribute to every row; exactly one function breaks the tie.
How do you define ownership when everyone can produce the work?+
Stop defining it by production and define it by tie-break. Ownership is who decides when there is disagreement, and the owner is accountable for the outcome rather than the output. That reframing removes the two failure modes that wreck design and product boundaries: shared ownership of a decision, which means the loudest person decides, and ownership assigned by whoever has capacity, which means the boundary moves every sprint.
Who owns the prompt or the system instructions?+
The workable split is that design owns what the behavior must be, engineering owns how it is implemented and evaluated, and neither ships a change to it alone. The prompt is simultaneously copy, behavior spec, and code, which is why it gets contested. Leaving it unassigned means it gets written by whoever is closest to the code at eleven at night, and then the product's voice is an accident.
Who decides when generated output is good enough to ship?+
Design, and only because design owns the rubric. The honest default in most teams is whoever happens to be in the room at the end, which is not a decision process. Putting it in writing with a rubric behind it makes the call reviewable rather than personal, and it means a disagreement about quality becomes a disagreement about a written dimension instead of about taste.
Who owns the failure states in an AI product?+
Whoever is named before launch. Everyone agrees failure states matter and nobody wants the ticket, so they end up unassigned, and an unowned failure state is discovered by a customer. In the operating model here they belong to design as a first-class surface, because recovery, disclosure, confidence, and correction are where the relationship with the user is built or lost.
How often should an ownership map be revisited?+
Once a quarter, not once. Ownership drifts as the product changes, and a map from two quarters ago becomes a source of arguments rather than a way to end them. The most valuable moment is when a decision gets escalated and the first question is which row it belongs to. If the answer is none of them, you found a missing row.
Related reading
Chapters and essays on the same thread, across both handbooks.
The Receipt and the Work
The design file was never the work. It was the receipt, and it stopped working as one the moment anyone could produce one in ninety seconds.
Specifying Behavior
A principle has never stopped anyone shipping anything. A constraint is a rule you can catch being broken, the only kind that survives generated output.
You Cannot Mock a Distribution
There is no final state to draw when the output is assembled at runtime. What you specify instead is a band, and everything inside it ships without your review.
The Shape of Uncertainty
How a product says it is not sure without looking broken. There are four moves, and the wrong one is why products read as falsely confident or hedged.
The Rubric Is the Spec
Your taste lives in a recurring meeting, which caps quality at what you can personally review. A rubric is that taste in a form that runs without you.