Purpose
Turn a messy, high-stakes product tradeoff into a structured decision brief that translates the same decision into the language, incentives, and risk lens of each stakeholder group — so a director can drive cross-functional alignment instead of relitigating the decision in every meeting.
When to Use
Invoke this skill when the user asks to:
- Frame a hard product, platform, or roadmap tradeoff for cross-functional alignment
- Prepare to present a contested decision to engineering, GTM, and executives
- Resolve competing priorities where each function wants a different outcome
- Build a decision brief or one-pager for a leadership review or steering committee
- Pre-handle objections before a tense alignment meeting
- Translate a technical or strategic tradeoff into terms each stakeholder cares about
Inputs Required
Before starting, collect:
- The decision: The specific tradeoff being made, framed as a question or fork (e.g., "Rebuild the billing platform now vs. patch and defer 2 quarters")
- The options: 2–4 realistic paths under consideration (if only one is given, help surface the alternatives)
- Stakeholder groups: Which functions have a stake and who owns each (engineering, GTM/sales/marketing, exec, finance, support, etc.)
- What each group wants: Known positions, concerns, or pressures per group — even if partial
- The constraint forcing the decision: What makes this urgent — deadline, budget, tech debt, market window, headcount
- Success metric: What "the right call" is ultimately measured against (revenue, retention, velocity, risk reduction)
- Decision owner and timeline: Who makes the final call and by when
If stakeholder positions are partial, infer the likely position of each group from their function's typical incentives and flag it as an assumption.
Instructions
Step 1: Sharpen the Decision Frame
Restate the tradeoff as a clean, mutually exclusive fork — not a vague topic.
- Convert "we need to figure out billing" into a specific decision with named options
- State what is genuinely at stake if the decision goes wrong in each direction
- Name the real constraint forcing the timing — decisions feel political when the forcing function is unstated
- Write a one-sentence decision statement in the form: "Should we [Option A] or [Option B], given [constraint], to achieve [success metric], by [date]?"
Step 2: Build the Options Matrix
Compare 2–4 options across a consistent set of dimensions. Present as a table.
Columns are the options; rows are:
- What it is: One-line description
- Time to value: Rough effort/timeline
- Impact on success metric: Direct effect on the metric that matters
- Primary risk: The single biggest thing that could go wrong
- Reversibility: One-way door vs. two-way door
- Who it helps / who it costs: Which stakeholder group gains and which pays
Be honest about the option the user seems to favor — do not stack the deck.
Step 3: Translate Impact Per Stakeholder
For each stakeholder group, produce a short block that reframes the recommended direction in their terms:
- What they care about: Their core incentive and pressure
- How this decision affects them: Concrete impact on their goals, velocity, quota, or risk exposure
- Their likely objection: The specific pushback this group will raise
- The reframe that lands: How to position the tradeoff so they see the upside for their function — or the fair cost they're being asked to accept
Cover at minimum engineering, GTM, and executive. Add finance/support/other if provided.
Step 4: Make the Recommendation
State a clear recommendation — do not present options and abdicate.
- Name the recommended option and give the 2–3 reason case
- Assign a confidence level: High / Medium / Low, with the reasoning
- State the conditions that would change the call (what new information would flip it)
- Name the one thing being sacrificed by choosing this path, and why that cost is acceptable
Step 5: Pre-Handle Objections
List the 4–6 hardest objections across all stakeholders, and for each:
- The objection stated in its strongest form (steelman it)
- The direct response — data, reframe, or acknowledged tradeoff
- Whether it's a blocker (must resolve to proceed) or a concern (note and move on)
Step 6: Produce Audience-Specific Talking Points
Generate a tight set of talking points tailored to each meeting context:
- For engineering: Lead with technical risk, sequencing, and velocity impact
- For GTM: Lead with customer/revenue impact and timeline commitments they can make externally
- For executives: Lead with the success metric, the strategic bet, the confidence level, and the ask — 3–4 sentences max, no jargon
Output Format
- Structure: Decision brief in ordered sections; options presented as a comparison table; per-stakeholder and talking-point blocks as labeled sub-sections
- Length: 900–1,300 words
- Format: Structured document with one table (options matrix) and the rest in scannable labeled blocks
- Sections: Decision Statement → Options Matrix → Per-Stakeholder Impact → Recommendation & Confidence → Objection Pre-Handling → Audience-Specific Talking Points
- Tone: Senior product director — decisive, plainspoken, intellectually honest about tradeoffs; no hedging, no false consensus
Quality Checklist
Before delivering output, verify:
- [ ] The decision statement is a single mutually-exclusive fork with a named constraint and success metric
- [ ] The options matrix covers every option across all listed dimensions, including reversibility
- [ ] Every stakeholder group provided has its own impact block with a named likely objection and a reframe
- [ ] A single recommendation is made with an explicit High/Medium/Low confidence level and stated flip conditions
- [ ] At least 4 objections are steelmanned and each is labeled blocker vs. concern
- [ ] Executive talking points are 3–4 sentences and free of internal jargon
Notes
- The most common failure in tradeoff framing is a matrix with no recommendation — a director's job is to have a point of view, not to stay neutral
- If the user only supplies one option, the highest-value move is surfacing the credible alternatives; a "decision" with one path isn't a tradeoff
- When stakeholder positions are inferred rather than known, label the assumption explicitly so the user can correct it before walking into the room
- Naming what is being sacrificed builds more trust than pretending the recommended path has no cost — stakeholders trust honesty about tradeoffs more than optimism
How to use this skill
This file is a Claude Code skill in Anthropic's standard format — markdown with YAML frontmatter at the top.
Installing in Claude Code:
~/.claude/skills/<folder-name>/SKILL.md— auto-loads in every session anywhere on your machine (recommended for skills you'll use across multiple projects)<your-project>/.claude/skills/<folder-name>/SKILL.md— auto-loads only when working in that project (recommended for project-specific skills)
Restart Claude Code or open a new session to register.
Using in Claude.ai, ChatGPT, Gemini, or other AI tools:
- Drag this file into a new chat, or copy and paste its contents
- Send your task or request as your next message — the AI will apply the skill where it fits
For Claude Code skill details: https://docs.anthropic.com/en/docs/claude-code/skills