Purpose
When systems fail unexpectedly, spontaneous attempts often produce more noise than insight. Hypothesis-driven Troubleshooting translates symptoms into testable assumptions and makes troubleshooting learnable.
Engineering Analysis method
Hypothesis-Driven Troubleshooting
Organizes possible explanations for symptoms, prioritizes tests by information value, and records diagnosis and evidence.
Jede Vermutung wird mit einer Prüfung verknüpft, die möglichst viel Information pro Test liefert. Dadurch entsteht eine Reihenfolge, in der die stärksten Hypothesen zuerst unter Druck geraten und die Diagnostik nicht im Kreis läuft. Der Ansatz verbindet Debugging mit sauberer Evidenz.
Which competing hypothesis best explains all observed signals, and which safe test discriminates among them most strongly?
- Participants
- 1-6
- Time
- 30–180 minutes per failure; for production-critical events run alongside safe containment.
The steps form one complete method run.
Symptom
Symptom view
Operationalise observed failure and collect Is/Is-Not cases.
Hypotheses
Hypothesis space
Derive several mechanistic explanations from signals, architecture, and changes.
Predictions
Prediction matrix
Write observable predictions and falsifying signals for every hypothesis.
Test
Test result
Run safest highest-information test, changing one condition at a time.
Decide
Diagnostic finding
Update hypotheses against all evidence, record mechanism, and hand over next action/residual uncertainty.
Add new evidence at review and version decisions with the prior state.
A good fit when
Wenn Systeme unerwartet ausfallen, liefern spontane Versuche oft mehr Lärm als Erkenntnis. Hypothesis-driven Troubleshooting übersetzt Symptome in überprüfbare Annahmen und macht die Fehlersuche lernbar.
Ideal for
- Unclear technical disruptions
- Debugging sessions
- Incident diagnosis
Not good for
- Known standard problems
- Non-testable questions
- Pure root-cause workshops without system access
Outputs
Diagnostic finding
Troubleshooting log with prioritised hypotheses, predictions, discriminating tests, results, and residual uncertainty.
Hypothesis-Driven Troubleshooting · working structure
Fictional example
Fictional values show the actual method fields.
| Hypothesis | Mechanism | Prediction | Falsifier | Test | Finding | Status |
|---|---|---|---|---|---|---|
| Shared pool exhaustedAdd evidence and rationale. | Batch occupies shared pool | Isolated pool removes timeout | Timeout persists with isolated pool | Compare shared and isolated pool | Failure only with shared pool | Supported |
| EU network faultAdd evidence and rationale. | Regional packet loss | EU loss affects web and mobile | Mobile remains stable | Compare EU web and mobile | Mobile has no loss | Weakened |
| Web release blocksAdd evidence and rationale. | Release blocks requests in browser | Direct API works | Direct call also fails | Bypass web and call API | Direct call fails | Rejected |
1. Mechanism
- Shared pool exhausted
- Batch occupies shared pool
- EU network fault
- Regional packet loss
- Web release blocks
- Release blocks requests in browser
2. Prediction
- Shared pool exhausted
- Isolated pool removes timeout
- EU network fault
- EU loss affects web and mobile
- Web release blocks
- Direct API works
3. Falsifier
- Shared pool exhausted
- Timeout persists with isolated pool
- EU network fault
- Mobile remains stable
- Web release blocks
- Direct call also fails
4. Test
- Shared pool exhausted
- Compare shared and isolated pool
- EU network fault
- Compare EU web and mobile
- Web release blocks
- Bypass web and call API
5. Finding
- Shared pool exhausted
- Failure only with shared pool
- EU network fault
- Mobile has no loss
- Web release blocks
- Direct call fails
6. Status
- Shared pool exhausted
- Supported
- EU network fault
- Weakened
- Web release blocks
- Rejected
All values are fictional.
First step
Set symptom, affected/unaffected cases, current signals, and safe test boundaries; separate containment from diagnosis.
Good to do first
Deep dive
How it works
Every guess is paired with a test that delivers as much information as possible per attempt. This creates a sequence in which the strongest hypotheses are put under pressure first and diagnostics do not run in circles. The approach combines debugging with clean evidence.
In detail
Hypothesis-Driven Troubleshooting treats every explanation as provisional. Symptoms, context, and changes are used to form hypotheses that are tested with the most informative possible checks. After each test, the knowledge state is updated and the next hypothesis is chosen. That creates a traceable diagnostic path instead of a collection of spontaneous fix attempts.
Facilitation
Keep hypotheses, expected observations, and test results visible. Prioritize tests that reduce a lot of uncertainty with little risk. Stop parallel trial-and-error if it worsens the evidence or creates side effects.
The method guide walks execution through 5 phases, timing, 5 pitfalls, and clear stop criteria.
Open method guideYour perspective
Does this method help with your work?
Your feedback helps shape the next improvements to methodatlas.
Sources and topics
Artifact templates
Hypothesis-Driven Troubleshooting: WorksheetSet subject, evidence, roles, flow, and review.markdown
Hypothesis-Driven Troubleshooting: WorksheetSet subject, evidence, roles, flow, and review.
markdownhypothesis-driven-troubleshooting-working-template.md
Set subject, evidence, roles, flow, and review.
Hypothesis-Driven Troubleshooting: Worksheet
Question
To be confirmed
Desired outcome
To be confirmed
Scope
Complete run Time: 30–180 minutes per failure; for production-critical events run alongside safe containment.
Complete this worksheet on paper or in your own document during the work.
Preparation for this scope
Method setup
- Materials: Precise symptom, architecture and changes, hypothesis board, predictions, safe tests, and evidence log
- Roles: Troubleshooting lead · hypothesis owners · operator · system experts · scribe
- Advance information: Set symptom, affected/unaffected cases, current signals, and safe test boundaries; separate containment from diagnosis.
- Overall time needed: 30–180 minutes per failure; for production-critical events run alongside safe containment.
- Setup: Prepare a workspace with Symptom · Hypotheses · Predictions · Test · Decide; separate example from live data.
Prepare for the work steps
Symptom: Symptom view
- Set symptom, affected/unaffected cases, current signals, and safe test boundaries; separate containment from diagnosis.
- Precise symptom, architecture and changes, hypothesis board, predictions, safe tests, and evidence log
Hypotheses: Hypothesis space
- Symptom view
Predictions: Prediction matrix
- Hypothesis space
Test: Test result
- Prediction matrix
Decide: Diagnostic finding
- Test result
Hypothesis-Driven Troubleshooting · working structure
| Hypothesis | Mechanism | Prediction | Falsifier | Test | Finding | Status |
|---|---|---|---|---|---|---|
| Shared pool exhausted | ||||||
| EU network fault | ||||||
| Web release blocks |
- Shared pool exhausted: Add evidence and rationale.
- EU network fault: Add evidence and rationale.
- Web release blocks: Add evidence and rationale.
The blank worksheet contains prompts only.
Reference · original teaching example
Symptom: Symptom view
Expected artifact: Symptom view
Operationalise observed failure and collect Is/Is-Not cases.
Entry:
...
- Is success/failure measurable and free of causal claims?
Hypotheses: Hypothesis space
Expected artifact: Hypothesis space
Derive several mechanistic explanations from signals, architecture, and changes.
Entry:
...
- Does each explain affected and unaffected cases?
Predictions: Prediction matrix
Expected artifact: Prediction matrix
Write observable predictions and falsifying signals for every hypothesis.
Entry:
...
- Are predictions recorded before testing and discriminating?
Test: Test result
Expected artifact: Test result
Run safest highest-information test, changing one condition at a time.
Entry:
...
- Does test vary exactly the discriminating condition and remain reversible?
Decide: Diagnostic finding
Expected artifact: Diagnostic finding
Update hypotheses against all evidence, record mechanism, and hand over next action/residual uncertainty.
Entry:
...
- Does leading hypothesis explain all signals with a serious alternative tested?
Open questions and next steps
...
Method guide: https://methodatlas.meierhoff-systems.de/en/methods/hypothesis-driven-troubleshooting/run-sheet
Alternatives and neighbors
Fitting alternatives with decision guidance, followed by other related methods.
Operations
5 Whys
Instead of Hypothesis-Driven Troubleshooting, choose 5 Whys when you want to quickly ask your way from symptom to possible cause without a test plan.
Operations
Root Cause Analysis
Instead of Hypothesis-Driven Troubleshooting, choose Root Cause Analysis when you want to systematically narrow down causes instead of stopping at symptoms.
Operations
Change Analysis
Compares an outlier with a stable case and filters out the differences that explain the deviation.
Engineering
Failure Scenario Analysis
Thinks through failures in advance, assesses controls, and shows gaps in testing, prevention, and response.
Engineering
Goal Question Metric
Moves technical problems, hypotheses, and next steps toward a concrete result through "formulate the goal clearly", "derive probing questions for each goal", and "set the review cadence".
Engineering
Golden Path
Describes the preferred default path for common use cases and adds templates, checks, and exceptions.
Constraints and origin
MediumWorkshop + async30-240 min
Profile
- Method form
- Analysis method
- Participants
- 1-6
- Time
- 30-240 min
- Maturity
- Established
- Origin
- Praxisgemeinschaft
Next up: Blameless Postmortem