Evaluating Decisions

Given a decision with multiple options, produce:

1. Decision Matrix — options scored against weighted criteria
2. Tradeoff Analysis — what you gain/lose with each option
3. Recommendation — the pick, with justification and confidence level

Example prompt: "Should we use PostgreSQL, MongoDB, or DynamoDB for our new order-tracking service?"

Progress:

• Step 1: Clarify the decision — what's actually being decided, and by when
• Step 2: Identify all viable options (don't skip the "do nothing" option if relevant)
• Step 3: Define evaluation criteria and their weights
• Step 4: Score each option against each criterion
• Step 5: Build the Decision Matrix
• Step 6: Write the Tradeoff Analysis
• Step 7: Give a clear Recommendation with confidence and conditions

Step 1 — Clarify the decision State the decision in one sentence. Note constraints (budget, time, must-haves) and who's affected.

Step 2 — Identify options List 2-5 realistic options. Merge near-duplicates. Always consider "status quo / do nothing" as a baseline unless explicitly irrelevant.

Step 3 — Define criteria Pick 4-6 criteria that actually differentiate the options (e.g., cost, speed to implement, risk, scalability, reversibility). Assign weights (e.g., 1-5 or percentages) reflecting what matters most to the stated goal. Ask what's implicit if the user didn't specify priorities — otherwise default to a sensible weighting and state your assumption explicitly.

Step 4 — Score Score each option per criterion on a consistent scale (e.g., 1-5). Base scores on evidence or stated facts, not vibes — note assumptions when data is thin.

Step 5 — Decision Matrix Present as a table: rows = options, columns = criteria (with weights), plus a weighted total column. Sort by total score descending.

Step 6 — Tradeoff Analysis For each option, 2-4 bullets covering: what you gain, what you sacrifice, key risk, and reversibility (how hard to undo).

Step 7 — Recommendation One clear pick (or a conditional "if X, choose A; if Y, choose B"). State confidence (high/medium/low) and the top 1-2 conditions that would change the recommendation.

Example 1: Input: "Choose a database for order-tracking service. Priorities: reliability, dev speed, cost."

Output:

Decision Matrix

Tradeoff Analysis

• PostgreSQL: Strong consistency and mature tooling; slower initial schema iteration; easy to reverse (widely supported).
• MongoDB: Fastest to prototype with flexible schema; weaker transactional guarantees for order integrity; moderate reversibility.
• DynamoDB: Scales effortlessly, low ops burden; highest cost at scale and steep query-modeling learning curve; hard to reverse once data model is baked in.

Recommendation Choose PostgreSQL (high confidence) — order-tracking needs strong consistency, and the dev-speed gap is small enough to accept. Reconsider MongoDB only if the team has zero SQL experience and timeline is under 2 weeks.

Example 2: Input: "Should we hire a contractor or a full-time employee for a 6-month project with likely follow-on work?"

Output:

Decision Matrix

Tradeoff Analysis

• Contractor: Fast start, lower short-term cost, easy to end engagement; weaker institutional knowledge retention if follow-on work materializes; highly reversible.
• Full-time Hire: Better long-term investment if follow-on work is likely; slower hiring process and higher fixed cost; low reversibility (layoffs are costly/disruptive).

Recommendation Choose Contractor now (medium confidence), with an explicit option-to-convert clause. If follow-on work is confirmed within 3 months, revisit and convert to full-time — this captures speed now without sacrificing long-term fit.