stakeholder-tradeoff

Make explicit who pays and who benefits when a decision pulls stakeholders in different directions. Builds a stakeholder × criterion matrix so the trade-off is visible, not hidden in politics. Sibling of decision-record — that one locks the choice; this one surfaces the human cost of each option before the lock.

When to use

• PO, ops, support, and engineering disagree on an approach and the user wants the disagreement made legible.
• A decision benefits one segment at the cost of another (free vs paid users, internal vs external, region A vs region B).
• A roadmap step has undeclared trade-offs and the user wants them surfaced before commit.
• German triggers: "Wer zahlt was?", "Stakeholder-Konflikt", "Trade-off zwischen X und Y".

Do NOT use when:

• One stakeholder owns the decision unambiguously — surface their decision and stop.
• The trade-off is technical-only (perf vs storage) — route to decision-record.
• The trade-off is risk-only — route to risk-officer.

Cognition cluster

• Mental model 5 — Opportunity cost. Every + on the matrix is also an opportunity cost on the stakeholders not getting that benefit; the matrix only earns its keep when it surfaces who pays for the chosen +. See docs/contracts/mental-models.md § 5.
• Mental model 27 — Outcome over output. Picking the option with the most checkmarks is output theatre; pick the option whose – cells land on stakeholders who can execute mitigations. See mental-models.md § 27.
• Mental model 29 — Pre-mortems. For the recommended option, state the failure mode each –-bearing stakeholder will name in six months. If you cannot, the lens is incomplete — re-interview. See mental-models.md § 29.
• Team + product context-spine slots. Read team for the silent-stakeholders inventory (on-call, support, finance) and product for end-user / segment lenses (free vs paid, region, cohort). See context-spine.

Procedure

1. Identify the stakeholders

Each by role, not name. Roles are stable across people — "on-call engineer" not "Anna". Include silent stakeholders the room forgot (support, finance, legal, end-users, future-team).

2. Capture each stakeholder's lens

For each stakeholder:

• What they want — outcome, in their voice.
• What they fear — the failure mode they cannot accept.
• What they will trade — what they will give up to get the outcome.

If a lens is missing, mark unknown and surface it — do NOT invent a position the stakeholder did not state.

3. Build the matrix

Criterion	PO	Ops	Support	Eng	End-user	...
Time-to-ship	+	–	0	–	+
Operational load	0	–	–	–	+
...

+ benefits, – costs, 0 neutral. The columns are stakeholders; the rows are criteria. Criteria that score 0 everywhere are noise — drop.

4. Surface the trade-off

Pick the top 2-3 criteria where the matrix splits stakeholders hardest. State the trade-off in plain language:

"Picking option X means PO ships faster, but on-call carries more pages. Picking option Y means on-call sleeps, but PO slips two weeks."

If no option splits the matrix unfavourably, the trade-off is imaginary — surface that and stop.

5. Recommend a path

Pick the option whose – cells are owned by stakeholders who can execute mitigations. Avoid options where the cost lands on a stakeholder who has no voice in the room. State the recommendation explicitly with a one-sentence rationale.

6. Validate the matrix

Verify before emitting: every stakeholder has wants / fears / trades filled or marked unknown, the matrix has no row that scores 0 everywhere, the trade-off paragraph names a concrete cost (not just "there is a trade-off"), and the recommendation cites which – cells the named owner can execute. Ensure no silent stakeholder column is missing.

Related Skills

WHEN to use this

• A request crosses two stakeholder lenses (eng ↔ PO, PO ↔ ops, ops ↔ infra) and the trade-off is not yet code.
• The room agrees on the goal but disagrees on who absorbs the cost.
• A roadmap step has undeclared trade-offs that need surfacing before commit.

WHEN NOT to use this

• The conflict surfaces inside an open PR (test-coverage fails but PO wants to ship) — start with code-review-multi-lens (sibling C8); a C8 verdict that surfaces stakeholder conflict becomes input to this skill for escalation. Boundary prose lives in docs/guidelines/cross-role-handoff.md.
• The trade-off is purely technical (perf vs storage, sync vs async) — route to decision-record; if it is one costly choice on ≥ 3 options with user-weighted criteria, its § Weighted-matrix mode scores it (this skill answers WHO pays; that mode answers WHICH option wins).
• The dominant axis is risk, not stakeholder cost — route to risk-officer.
• The output is the locked decision artifact — hand off to decision-record once the matrix is built.

When the agent should load this

• "Wer zahlt was bei dieser Entscheidung?"
• "PO und Ops sind sich uneinig — wir brauchen Klarheit."
• "Was ist der Trade-off zwischen X und Y für die einzelnen Lenses?"
• "Stakeholder-Konflikt vor dem Commit auflösen."
• "Diese Roadmap-Phase hat undeclared trade-offs."

Output

The trade-off report is a single block with these ordered fields:

1. Decision: — one sentence framing the choice
2. Stakeholders: — bullet list, each with wants / fears / trades
3. Matrix: — markdown table with criteria rows and stakeholder columns
4. Trade-off in plain language: — one paragraph naming the cost
5. Recommendation:, Rationale:, Next: — explicit choice + rationale + handoff target

Stakeholder trade-off
Decision: <one sentence>

Stakeholders:
  - <role>  wants: <outcome>     fears: <failure>     trades: <what>
  - ...

Matrix:
  | Criterion       | <SH 1> | <SH 2> | ... |
  | ...

Trade-off in plain language:
  <one paragraph>

Recommendation: <option>
Rationale:      <one sentence>
Next:           /decision-record  to lock the choice

Gotcha

• The room is rarely all the stakeholders. Add the silent ones explicitly (support, future-team, end-users).
• A + everywhere column is suspect; either a stakeholder understated the cost or you understated the cost.
• The "happy path" recommendation is the option with the cost on someone who is not in the room. Resist it.

Do NOT

• Do NOT label stakeholders by name — roles only.
• Do NOT score before listing the stakeholders' own words; agent ventriloquism is the failure mode.
• Do NOT pick the option that scores best on all stakeholders — if it exists, the trade-off was imaginary; surface that.
• Do NOT lock the choice in this skill; hand off to decision-record.

Runnable example

A pricing-page rewrite that ships faster vs gives ops more lead time:

• Decision: "Should the pricing-page rewrite ship in 2 weeks (option A) or 4 weeks with a managed rollout (option B)?"
• Stakeholders:
  • PO wants: revenue lift on Q-end · fears: churn signal in the noise · trades: copy polish for time-to-ship.
  • On-call eng wants: change window outside Friday · fears: Saturday paging on a marketing rollout · trades: shippable A/B framework for a deploy gate.
  • Support lead wants: scripted answers for the new tier · fears: ticket-volume spike unprepared · trades: depth of answers for breadth.
  • End-user (free tier) wants: clear "what stays free" line · fears: silent paywall on a feature they rely on · trades: nothing — silent stakeholder.
• Matrix splits hardest on operational load (option A: – for on-call + support, + for PO) and clarity for end-users (option B: + for support + end-user, – for PO timing).
• Trade-off in plain language: "Option A means PO hits Q-end, but on-call carries a marketing-rollout pager and support eats ticket spikes blind. Option B means support and end-users land softly, but PO slips two weeks past Q-end."
• Recommendation: option B. Rationale: the – cells in option A land on stakeholders who cannot mitigate from inside the rollout (free-tier user has no voice in the room).
• Next: /decision-record to lock option B; the supersession chain cites the original "ship by Q-end" mandate as the constraint that changed.