Decision Matrix
Overview
A weighted decision matrix (a.k.a. weighted scoring model, Pugh matrix, or trade study)
turns a fuzzy "which should I pick?" question into a transparent, defensible number.
You list the options (the things you choose between), the criteria (what matters),
assign each criterion a weight (how much it matters), score every option on every
criterion, and compute a weighted total. The highest total is the recommended choice.
Keywords: decision making, weighted scoring, trade-off analysis, multi-criteria decision
analysis (MCDA), Pugh matrix, vendor selection, job offer comparison, prioritization.
Use this skill whenever someone must choose among 2+ discrete alternatives and wants the
reasoning to be explicit rather than a gut feel. Do not force a matrix on a binary
yes/no decision or a problem with a single dominant constraint — say so instead.
Workflow
Follow these steps in order. Confirm with the user at steps 1–4 before computing.
Frame the decision. State the single question being answered (e.g. "Which CRM
should we adopt?"). One decision per matrix. If the user has bundled several
decisions, split them.
List the options. Gather 2–7 concrete alternatives. Fewer than 2 is not a
decision; more than ~7 becomes noisy — shortlist first. Always consider adding a
baseline "do nothing / status quo" option when relevant.
Elicit the criteria. Ask what factors matter. Aim for 4–8 criteria. Each must be:
- Distinct (not measuring the same thing twice — avoid double-counting).
- Discriminating (options actually differ on it; drop criteria where all score equally).
- Phrased so higher = better (rename "Cost" → "Affordability", or mark it as a cost
criterion to invert — see references/scoring-guide.md).
Set weights. Assign each criterion a weight reflecting its importance. Use any
consistent scale (1–5, or percentages summing to 100). Normalize internally so totals
are comparable. Capture must-have constraints separately as pass/fail gates, not
weights — a dealbreaker should eliminate an option, not just dock points (see
references/scoring-guide.md, "Constraints vs. criteria").
Score each option × criterion. Use a fixed scale (default 1–5; 1 = poor, 5 = excellent).
Score one criterion across all options at a time (column-wise) to keep scoring calibrated.
Note the rationale for extreme scores.
Compute. Weighted score = Σ(weight × score) per option, normalized to a 0–100 index.
Use scripts/decision_matrix.py to do this reproducibly from a JSON or CSV file rather
than doing arithmetic by hand.
Sanity-check & sensitivity. Ask: "Does the winner feel right?" If the top two are
within ~5%, the decision is a near-tie — flag it and run sensitivity analysis (vary the
most subjective weights/scores; see the script's --sensitivity flag). State which
assumptions the result hinges on.
Report. Present the ranked table, the winner, the margin, the key drivers, and the
risks/caveats. Use templates/report.md. Be explicit that the matrix informs the
decision — it does not replace judgment.
Scoring Scale (default)
| Score |
Meaning |
| 5 |
Excellent / best in class |
| 4 |
Good / above average |
| 3 |
Adequate / acceptable |
| 2 |
Weak / below average |
| 1 |
Poor / unacceptable on this axis |
Keep the scale consistent across all criteria. For details on normalizing mixed units
(dollars, days, ratings) and handling cost-style criteria, see references/scoring-guide.md.
Worked Example (abbreviated)
Choosing a project-management tool across Cost, Ease of use, Integrations, Support.
| Criterion |
Weight |
Tool A |
Tool B |
Tool C |
| Affordability |
3 |
5 |
3 |
2 |
| Ease of use |
5 |
3 |
5 |
4 |
| Integrations |
4 |
3 |
4 |
5 |
| Support |
2 |
4 |
3 |
5 |
| Weighted |
|
47 |
52 |
52 |
Tool B and Tool C tie at 52. That is the signal to stop and look deeper: Tool C wins on
the highest-weight-adjacent criteria but loses on cost; Tool B is balanced. Run sensitivity
on the Ease-of-use weight. See examples/tool-selection.md for the full walkthrough,
including the JSON input and the script output.
Best Practices
- Weight before you score. Set weights and criteria before seeing the options'
scores, to avoid rationalizing a pre-chosen winner.
- Score column-wise, one criterion at a time across all options, for calibration.
- Separate gates from scores. Must-haves are pass/fail filters applied first.
- Show your work. Always surface the table and weights, never just the final number.
- Treat near-ties as ties. A 1-point gap on a subjective 1–5 scale is noise.
- Run sensitivity on the squishy inputs — the weights and scores you were least sure of.
- Keep criteria independent to avoid silently double-counting one concern.
Common Pitfalls
- Fudging weights to get the answer you wanted. If you adjust inputs after seeing
results, say so explicitly and re-justify.
- Too many criteria. Beyond ~8, low-weight noise drowns the signal. Consolidate.
- Non-discriminating criteria. If every option scores the same, the criterion adds
nothing — drop it.
- Mixing cost and benefit directions. Forgetting to invert a "lower is better"
criterion silently rewards the worst option. See references/scoring-guide.md.
- False precision. Reporting 73.42 implies accuracy the inputs don't have. Round and
present margins, not decimals.
- Ignoring dealbreakers. A weighted average can let a strong option survive a fatal
flaw. Apply hard constraints first.
Supporting Files
references/scoring-guide.md — scales, normalization of mixed units, cost vs. benefit
criteria, weighting methods (direct, ranking, pairwise/AHP), and constraints vs. criteria.
scripts/decision_matrix.py — stdlib Python tool. Computes weighted scores and rankings
from JSON/CSV, prints a formatted table, supports cost criteria and --sensitivity.
examples/tool-selection.md — full worked example with input file and script output.
templates/report.md — fill-in template for presenting the decision and recommendation.
1---2name: decision-matrix3description: Builds a weighted decision matrix to compare options against criteria with transparent, reproducible scoring and sensitivity analysis. Use this skill when the user needs to choose between multiple options, compare alternatives, "help me decide", "which should I pick", weigh trade-offs, evaluate vendors/tools/candidates/houses/job offers, run a pros-and-cons or scoring analysis, rank choices objectively, or justify a recommendation with numbers. Triggers include "decision matrix", "weighted scoring", "compare these options", "pugh matrix", "trade study", and "how do I choose between X and Y".4license: MIT5---67# Decision Matrix89## Overview1011A weighted decision matrix (a.k.a. weighted scoring model, Pugh matrix, or trade study)12turns a fuzzy "which should I pick?" question into a transparent, defensible number.13You list the **options** (the things you choose between), the **criteria** (what matters),14assign each criterion a **weight** (how much it matters), score every option on every15criterion, and compute a weighted total. The highest total is the recommended choice.1617Keywords: decision making, weighted scoring, trade-off analysis, multi-criteria decision18analysis (MCDA), Pugh matrix, vendor selection, job offer comparison, prioritization.1920Use this skill whenever someone must choose among 2+ discrete alternatives and wants the21reasoning to be explicit rather than a gut feel. Do **not** force a matrix on a binary22yes/no decision or a problem with a single dominant constraint — say so instead.2324## Workflow2526Follow these steps in order. Confirm with the user at steps 1–4 before computing.27281. **Frame the decision.** State the single question being answered (e.g. "Which CRM29 should we adopt?"). One decision per matrix. If the user has bundled several30 decisions, split them.31322. **List the options.** Gather 2–7 concrete alternatives. Fewer than 2 is not a33 decision; more than ~7 becomes noisy — shortlist first. Always consider adding a34 baseline "do nothing / status quo" option when relevant.35363. **Elicit the criteria.** Ask what factors matter. Aim for 4–8 criteria. Each must be:37 - **Distinct** (not measuring the same thing twice — avoid double-counting).38 - **Discriminating** (options actually differ on it; drop criteria where all score equally).39 - **Phrased so higher = better** (rename "Cost" → "Affordability", or mark it as a cost40 criterion to invert — see references/scoring-guide.md).41424. **Set weights.** Assign each criterion a weight reflecting its importance. Use any43 consistent scale (1–5, or percentages summing to 100). Normalize internally so totals44 are comparable. Capture **must-have constraints** separately as pass/fail gates, not45 weights — a dealbreaker should eliminate an option, not just dock points (see46 references/scoring-guide.md, "Constraints vs. criteria").47485. **Score each option × criterion.** Use a fixed scale (default 1–5; 1 = poor, 5 = excellent).49 Score one criterion across all options at a time (column-wise) to keep scoring calibrated.50 Note the rationale for extreme scores.51526. **Compute.** Weighted score = Σ(weight × score) per option, normalized to a 0–100 index.53 Use scripts/decision_matrix.py to do this reproducibly from a JSON or CSV file rather54 than doing arithmetic by hand.55567. **Sanity-check & sensitivity.** Ask: "Does the winner feel right?" If the top two are57 within ~5%, the decision is a near-tie — flag it and run sensitivity analysis (vary the58 most subjective weights/scores; see the script's `--sensitivity` flag). State which59 assumptions the result hinges on.60618. **Report.** Present the ranked table, the winner, the margin, the key drivers, and the62 risks/caveats. Use templates/report.md. Be explicit that the matrix informs the63 decision — it does not replace judgment.6465## Scoring Scale (default)6667| Score | Meaning |68|------:|--------------------|69| 5 | Excellent / best in class |70| 4 | Good / above average |71| 3 | Adequate / acceptable |72| 2 | Weak / below average |73| 1 | Poor / unacceptable on this axis |7475Keep the scale consistent across all criteria. For details on normalizing mixed units76(dollars, days, ratings) and handling cost-style criteria, see references/scoring-guide.md.7778## Worked Example (abbreviated)7980Choosing a project-management tool across Cost, Ease of use, Integrations, Support.8182| Criterion | Weight | Tool A | Tool B | Tool C |83|---------------|:------:|:------:|:------:|:------:|84| Affordability | 3 | 5 | 3 | 2 |85| Ease of use | 5 | 3 | 5 | 4 |86| Integrations | 4 | 3 | 4 | 5 |87| Support | 2 | 4 | 3 | 5 |88| **Weighted** | | **47** | **52** | **52** |8990Tool B and Tool C tie at 52. That is the signal to stop and look deeper: Tool C wins on91the highest-weight-adjacent criteria but loses on cost; Tool B is balanced. Run sensitivity92on the Ease-of-use weight. See examples/tool-selection.md for the full walkthrough,93including the JSON input and the script output.9495## Best Practices9697- **Weight before you score.** Set weights and criteria *before* seeing the options'98 scores, to avoid rationalizing a pre-chosen winner.99- **Score column-wise**, one criterion at a time across all options, for calibration.100- **Separate gates from scores.** Must-haves are pass/fail filters applied first.101- **Show your work.** Always surface the table and weights, never just the final number.102- **Treat near-ties as ties.** A 1-point gap on a subjective 1–5 scale is noise.103- **Run sensitivity on the squishy inputs** — the weights and scores you were least sure of.104- **Keep criteria independent** to avoid silently double-counting one concern.105106## Common Pitfalls107108- **Fudging weights to get the answer you wanted.** If you adjust inputs after seeing109 results, say so explicitly and re-justify.110- **Too many criteria.** Beyond ~8, low-weight noise drowns the signal. Consolidate.111- **Non-discriminating criteria.** If every option scores the same, the criterion adds112 nothing — drop it.113- **Mixing cost and benefit directions.** Forgetting to invert a "lower is better"114 criterion silently rewards the worst option. See references/scoring-guide.md.115- **False precision.** Reporting 73.42 implies accuracy the inputs don't have. Round and116 present margins, not decimals.117- **Ignoring dealbreakers.** A weighted average can let a strong option survive a fatal118 flaw. Apply hard constraints first.119120## Supporting Files121122- `references/scoring-guide.md` — scales, normalization of mixed units, cost vs. benefit123 criteria, weighting methods (direct, ranking, pairwise/AHP), and constraints vs. criteria.124- `scripts/decision_matrix.py` — stdlib Python tool. Computes weighted scores and rankings125 from JSON/CSV, prints a formatted table, supports cost criteria and `--sensitivity`.126- `examples/tool-selection.md` — full worked example with input file and script output.127- `templates/report.md` — fill-in template for presenting the decision and recommendation.