evaluating-trade-offs

$npx mdskill add liqiongyu/lenny_skills_plus/evaluating-trade-offs

Produce a decision-ready trade-off evaluation pack with cost and impact ranges.

  • Turns ambiguous pros/cons debates into a structured trade-off evaluation.
  • Depends on user-provided options, assumptions, and cost estimates.
  • Uses order-of-magnitude ranges, opportunity cost, and thought experiments.
  • Delivers an options matrix, cost table, impact ranges, and recommendation.

SKILL.md

.github/skills/evaluating-trade-offsView on GitHub ↗
---
name: "evaluating-trade-offs"
description: "Produce a Trade-off Evaluation Pack (options matrix, cost table, impact ranges, recommendation). See also: evaluating-new-technology (tech-specific)."
---

# Evaluating Trade-offs

## Scope

**Covers**
- Turning an ambiguous “pros/cons” debate into a decision-ready **trade-off evaluation**
- Comparing options using **all-in cost** (not just dollars) and explicit **opportunity cost**
- Using **order-of-magnitude estimates** (ranges + confidence) instead of false precision
- Stress-testing decisions with **thought experiments** (pre-mortems, reversibility, “worse first” dips)
- Avoiding sunk-cost traps with a clean **stop/continue** decision rule

**When to use**
- “Help me evaluate this trade-off and recommend a path.”
- “Create a pros/cons that actually leads to a decision.”
- “Compare options with cost/impact ranges and key assumptions.”
- “We’re debating speed vs quality—what’s the right trade and how do we manage the dip?”
- “Should we keep investing in this project, or stop? (Sunk cost question.)”

**When NOT to use**
- You need to clarify what problem you’re solving (use `problem-definition`).
- You need a full cross-functional decision process with stakeholder alignment and governance (use `running-decision-processes`).
- You’re prioritizing across many initiatives (use `prioritizing-roadmap`).
- You’re evaluating a specific technology, vendor, or build-vs-buy for a tool/platform (use `evaluating-new-technology`).
- You’re cutting scope to hit a date/timebox (use `scoping-cutting`).
- You need to model feedback loops, second-order effects, or system dynamics (use `systems-thinking`).
- The decision is personal/legal/HR/financial advice (escalate to qualified humans).

## Inputs

**Minimum required**
- The trade-off / decision statement (one sentence) and a decision date (or “by EOW”)
- 2–4 options you’re choosing between (include “do nothing” if plausible)
- Constraints + non-negotiables (budget, headcount, policy, deadlines, customer commitments)
- What “good” means (success metrics + guardrails) and the time horizon you care about
- What you already know (evidence) + biggest unknowns (assumptions that drive the choice)

**Missing-info strategy**
- Ask up to 5 questions from [references/INTAKE.md](references/INTAKE.md) (3–5 at a time).
- If inputs are unavailable, proceed with explicit assumptions and label unknowns that would change the recommendation.

## Outputs (deliverables)

Produce a **Trade-off Evaluation Pack** in Markdown (in-chat; or as files if requested) in this order:
1) **Trade-off brief** (decision, why now, options, constraints, horizon, stakeholders)
2) **Options + criteria matrix** (criteria + weights/guardrails; option notes)
3) **All-in cost + opportunity cost table** (money, people/time, eng effort, complexity, displacement)
4) **Impact ranges (order-of-magnitude)** (upside/downside ranges, confidence, key assumptions)
5) **Worse-first + mitigation plan** (expected dip, leading indicators, mitigations, comms)
6) **Recommendation + stop/continue triggers** (decision, rationale, review date, kill/continue criteria)
7) **Risks / Open questions / Next steps** (always included)

Templates: [references/TEMPLATES.md](references/TEMPLATES.md)  
Expanded guidance: [references/WORKFLOW.md](references/WORKFLOW.md)

## Workflow (7 steps)

### 1) Frame the trade-off (make it decidable)
- **Inputs:** User request; [references/INTAKE.md](references/INTAKE.md).
- **Actions:** Write the decision in one sentence (“We are choosing X vs Y by DATE to achieve GOAL”). List constraints/non-negotiables. Confirm the decision owner and who must live with the outcome.
- **Outputs:** Trade-off brief (decision, why now, constraints, stakeholders).
- **Checks:** You can answer: “What exactly are we deciding, by when, and for what outcome?”

### 2) Define what you’re optimizing (criteria + horizon)
- **Inputs:** Goals, metrics, guardrails; time horizon.
- **Actions:** Pick 4–8 criteria (include at least one *guardrail* like trust/reliability/cost). Decide weights only if it changes the decision. Explicitly name what you’re *not* optimizing for.
- **Outputs:** Options + criteria matrix (criteria definitions + weights/guardrails).
- **Checks:** Criteria reflect real trade-offs (not “everything is important”); horizon is explicit (e.g., 90 days vs 2 years).

### 3) Build the all-in cost + opportunity cost view
- **Inputs:** Team capacity, budget, dependencies, timelines.
- **Actions:** Estimate **all-in cost** (cash, headcount time, eng effort, maintenance, coordination). List the **opportunity cost**: what won’t be done if you choose each option.
- **Outputs:** All-in cost + opportunity cost table.
- **Checks:** Costs include “hidden” items (maintenance/on-call, tooling, cross-team coordination, switching costs).

### 4) Estimate impact with ranges (avoid false precision)
- **Inputs:** Any baseline numbers; evidence; assumptions.
- **Actions:** For each option, estimate upside/downside as **ranges** and note confidence. Prefer **order-of-magnitude** comparisons (10× vs 1.1×). Identify the 2–3 assumptions that drive the model.
- **Outputs:** Impact ranges table (range, confidence, key assumptions).
- **Checks:** No fake decimals; uncertainty is explicit; the decision is driven by a few key drivers you can name.

### 5) Run “thought experiments” (think more, build less)
- **Inputs:** Options, assumptions, risks.
- **Actions:** Do a pre-mortem for the top 1–2 options (“It failed—why?”). Identify the cheapest evidence to de-risk the biggest assumption (data pull, customer calls, small prototype, timeboxed spike). Decide if this should be a **thought experiment only** (no build) vs a real experiment.
- **Outputs:** Assumption list + minimal validation plan (if needed).
- **Checks:** Proposed tests are the smallest that could change your mind; you’re not shipping an “obvious loser” experiment.

### 6) Account for “worse first” + sunk costs
- **Inputs:** Expected short-term impacts; current investment/sunk costs.
- **Actions:** Name any “worse-first” dip (short-term pain) and plan mitigations/leading indicators. Apply a sunk-cost reset: “If we weren’t already doing this, would we start today?” Define stop/continue triggers and a review date.
- **Outputs:** Worse-first plan + stop/continue triggers.
- **Checks:** The plan anticipates the dip; continuation logic ignores sunk costs and focuses on future ROI and strategic fit.

### 7) Recommend, commit, and quality-gate
- **Inputs:** All artifacts above.
- **Actions:** Write the recommendation with rationale and explicit trade-offs (what you will stop doing). Add risks, open questions, and next steps with owners/dates. Run [references/CHECKLISTS.md](references/CHECKLISTS.md) and score with [references/RUBRIC.md](references/RUBRIC.md).
- **Outputs:** Final Trade-off Evaluation Pack.
- **Checks:** A stakeholder can read this async and make (or support) the decision without re-litigating the debate.

## Quality gate (required)
- Use [references/CHECKLISTS.md](references/CHECKLISTS.md) and [references/RUBRIC.md](references/RUBRIC.md).
- Always include: **Risks**, **Open questions**, **Next steps**.

## Examples

**Example 1 (resource allocation):** “Should we invest in SEO or paid acquisition for the next 2 quarters? Build a trade-off pack with all-in cost, ROI speed, and assumptions.”  
Expected: all-in cost vs alternatives, order-of-magnitude impact ranges, and a clear recommendation + review date.

**Example 2 (speed vs quality):** “We can ship v1 next week with rough edges or delay 3 weeks to ship ‘noteworthy’. Evaluate the trade-off and propose a worse-first mitigation plan if we ship now.”  
Expected: explicit criteria/guardrails (trust/support load), dip plan, and stop/continue triggers if metrics degrade.

**Boundary example:** “Help me decide if I should leave my job.”
Response: this skill is for organizational/product leadership trade-offs; suggest a personal decision framework or coach instead.

**Boundary example 2:** “Model the second-order effects of switching from monolith to microservices on team velocity and hiring.”
Response: second-order systems effects are better served by `systems-thinking`; this skill evaluates discrete options with cost/impact ranges and a recommendation, not dynamic system models.

## Anti-patterns (common failure modes)

1. **False precision trap**: Presenting cost/impact estimates with decimal-point accuracy (“$127,450 savings”) when the real confidence is order-of-magnitude. Use ranges and explicit confidence levels.
2. **Sunk cost anchoring**: Framing the “do nothing” option as “waste our prior investment” instead of asking “if we started fresh today, would we choose this?” The stop/continue test must ignore sunk costs.
3. **Missing opportunity cost**: Evaluating options on their own merits without explicitly stating what will NOT get done if each option is chosen. Every “yes” is a “no” to something else.
4. **Criteria inflation**: Listing 12+ criteria where “everything is important,” which makes the matrix unreadable and hides the real trade-off. Limit to 4-8 criteria with explicit weights or guardrails.
5. **Recommendation without triggers**: Making a recommendation but not defining when to revisit or kill it. A good recommendation includes a review date and stop/continue criteria.

More from liqiongyu/lenny_skills_plus