tjboudreaux/thinking-kepner-tregoe

Kepner-Tregoe Problem Analysis

Overview

Kepner-Tregoe (KT) is a structured root-cause method. This skill focuses on Problem Analysis (PA) — the IS/IS-NOT boundary contrast — which is the high-value KT process for debugging. When a defect is selective (some cases affected, others not), the boundary between IS and IS-NOT reveals the distinction that points at the root cause.

Decision Analysis (DA) and Potential Problem Analysis (PPA) are de-emphasized here. For pure decision-making among alternatives, use thinking-opportunity-cost. For risk anticipation before a change, use thinking-pre-mortem. Those skills are purpose-built for those tasks; KT's DA/PPA add overhead without unique mechanism.

Situation Analysis (SA) is retained as a lightweight triage step when facing multiple concerns, but it is not a required preamble — jump directly to PA when the problem is already clear.

Core Principle: The boundary between what IS affected and what IS NOT affected encodes the root cause. Find the distinction, find the cause.

When to Use

• A defect is selective: affects some endpoints/regions/users/times but NOT others — there is an IS-vs-IS-NOT boundary to contrast
• The cause is unclear and not obvious from a stack trace, error message, or a single recent change
• Multiple possible causes exist and you need a systematic way to narrow them
• A complex situation has multiple concerns that need triage before diving in

Decision flow:

Defect is selective (not 100%)? → No → IS/IS-NOT has no signal; use direct debugging or thinking-systems
                                → Yes → Cause obvious from stack trace/recent change? → Yes → Just fix it
                                                                                      → No → APPLY KT PROBLEM ANALYSIS

When NOT to Use

• The failure is uniform (affects 100% of requests/everything) — there is no IS-vs-IS-NOT boundary to contrast; PA gives no signal. Use thinking-systems or direct debugging.
• The cause is already obvious from a stack trace, error message, or a single recent change — just fix it; IS/IS-NOT is overhead here.
• A quick hypothesis is cheaply testable — test it (thinking-occams-razor) before building a full specification matrix.
• Pure decision-making with no deviation to diagnose — use thinking-opportunity-cost, not KT's Decision Analysis.
• Risk assessment for a planned change — use thinking-pre-mortem, not KT's Potential Problem Analysis.

Trigger Card

When a defect is selective (some cases affected, others not) and the cause is unclear:

1. State the problem precisely — what is the deviation? In what object? Where/when does it occur?
2. Map IS vs IS-NOT — what IS affected vs what IS NOT, side by side. The boundary is the signal.
3. Find the distinction — what is different about the IS cases vs the IS-NOT cases? That distinction IS the cause.

Skip if the failure is uniform (100%) — there's no boundary to contrast; use direct debugging. If the cause is obvious from a stack trace or recent change, just fix it. For a single cheaply-testable hypothesis, test it first.

Procedure

Step 1 (optional): Situation Analysis — Triage Multiple Concerns

Only when facing several problems at once. List all concerns, separate them if compound, and prioritize by Timing/Impact/Trend:

| Concern | Timing | Impact | Trend | Priority | |---------|--------|--------|-------|----------| | API latency spike | Urgent | High | Worsening | P0 | | Checkout errors | Soon | High | Stable | P1 |

For each concern, decide: Problem Analysis (PA), or delegate to another skill.

Step 2: State the Problem Precisely

Describe the deviation from expected behavior with specificity:

"API response time increased from 200ms to 800ms for /checkout endpoint,
US-East only, starting Monday 9 AM, affecting ~30% of requests."

Step 3: Build the IS/IS-NOT Matrix

Specify the problem across four dimensions. The power is in the distinction column — what's unique about the IS side?

| Dimension | IS (affected) | IS NOT (not affected) | Distinction | |-----------|---------------|----------------------|-------------| | WHAT — object | /checkout endpoint | /cart, /product, /user | Payment processing | | WHAT — defect | 4x latency increase | Errors, timeouts, data corruption | Performance only | | WHERE — location | Production US-East | EU, US-West, staging | Single region | | WHERE — on object | Database query phase | Auth, validation, serialization | DB layer | | WHEN — first seen | Monday 9:00 AM | Before Monday, after 6 PM | Business hours | | WHEN — pattern | During checkout submit | During browsing, cart add | Write operations | | EXTENT — how many | ~30% of requests | 100% of requests | Intermittent | | EXTENT — trend | Stable since Tuesday | Getting worse | Plateaued |

Step 4: Extract Distinctions

For each row, ask: "What's unique or distinctive about the IS side compared to the IS-NOT side?"

Distinctions:
- Only /checkout (payment processing) — not other endpoints
- Only US-East (specific DB replica) — not other regions
- Only during business hours (load-related?) — not off-peak
- Only ~30% of requests (specific query pattern?) — not all
- Started Monday 9 AM — what changed?

Step 5: Identify Changes

What changed in, on, around, or about the distinctions near the first observation time?

Changes near Monday 9 AM:
- Payment provider SDK updated (Sunday night deploy)
- Database index rebuild scheduled (Sunday maintenance)
- New fraud detection rules enabled (Monday 8:45 AM)

Step 6: Generate and Test Possible Causes

Each candidate cause must explain BOTH the IS and the IS-NOT:

| Possible Cause | Explains IS? | Explains IS-NOT? | Verdict | |----------------|-------------|------------------|---------| | Fraud rules adding DB queries | ✓ Only checkout, only write ops | ✓ Not other endpoints | Pursue | | Payment SDK change | ✓ Only checkout | ✗ Would affect all regions | Ruled out | | Index rebuild | ✓ DB layer | ✗ Would affect all queries | Ruled out |

Step 7: Verify the True Cause

Design a test to confirm or rule out the leading candidate:

Verification for "Fraud detection rules":
1. Check: Rules enabled 8:45 AM (matches timeline)
2. Check: Rules only on checkout (matches scope)
3. Test: Disable rules in canary, measure latency
4. Examine: Query logs for fraud check queries

Output Contract

A completed KT Problem Analysis produces:

1. Problem Statement — specific, measurable deviation
2. IS/IS-NOT Matrix — all four dimensions with distinctions extracted
3. Changes List — what changed near the distinctions around the first observation
4. Cause Test Table — each candidate tested against IS and IS-NOT
5. Confirmed Root Cause — with verification evidence
6. If used, SA Triage — prioritized concern list with assigned processes

Anti-Patterns

| Anti-Pattern | Symptom | Correction | |---|---|---| | KT on uniform failure | Running PA when 100% of requests fail | No boundary to contrast; use direct debugging or thinking-systems | | Over-specifying the matrix | Filling every IS/IS-NOT cell for a simple bug | Stop when the distinction is clear; don't ritualize | | DA/PPA sprawl | Running full Decision Analysis or Potential Problem Analysis for routine tasks | Redirect to thinking-opportunity-cost (decisions) or thinking-pre-mortem (risks) | | Skipping cause testing | Pursuing the first plausible cause without testing against IS-NOT | Every cause must explain BOTH IS and IS-NOT | | SA as mandatory preamble | Running full Situation Analysis before every PA | Jump directly to PA when the problem is already clear | | Ignoring the distinction | Building the matrix but not extracting what's unique about IS | The distinction IS the signal; without it, the matrix is just a table |