methodatlas
Engineering

Hypothesis-Driven Troubleshooting

Turns technical problems, hypotheses, and next steps into a tangible result by collecting symptoms, formulating hypotheses, and refining them through testing.

Core question
Which hypothesis best explains the symptom, and which test delivers the highest information value?
MediumWorkshop + async30-240 min
Open runsheetPlan sessionStart comparison
Purpose

The method helps clarify technical problems, hypotheses, and next steps in a concrete way. It breaks a technical problem into testable parts. The result is captured as a hypothesis log, a test plan, and evidence notes.

How it works

The team follows the steps: collect symptoms, formulate hypotheses, prioritize tests by information value, run and document tests, and reject, confirm, or refine the hypotheses. Each step is captured visibly. At the end, a hypothesis log, a test plan, and evidence notes are available so decisions, tests, or actions can follow directly.

Visual orientation

Method sketch for a quick mental model.

Hypothesis-driven TroubleshootingSymptome in prüfbare Hypothesen, erwartete Beobachtungen und informative Tests übersetzen, danach den Wissensstand aktualisieren
Hypothesis-Driven TroubleshootingDas Visual zeigt Symptome, Hypothesen mit erwarteten Beobachtungen, Testplan, Evidenz und Diagnose als gerichteten Troubleshooting-Lernpfad.Troubleshooting als gerichteten Lernpfad führenJede Erklärung bleibt Hypothese, bis ein Test mit erwarteter Beobachtung sie bestätigt, verwirft oder verfeinert.vor jedem Test erwartete Beobachtung notierennach jedem Test Wissensstand aktualisierenSymptomebeobachtbar, reproduzierbar,abgegrenztHypothesis LogHyp.UrsacheErwartungStatusH1Cache staleRefresh behebtverworfenH2DB timeoutLatenz steigtbestätigtH3Deploy diffRollback hilftoffenTestplanhoher Informationswert, geringesRisikoEvidenzBeobachtung aktualisiertHypothesenDiagnosebestätigte Erklärung und nächsterFix

Flow

  1. 1Collect symptoms
  2. 2Formulate hypotheses
  3. 3Prioritize tests by information value
  4. 4Run and document tests
  5. 5Reject, confirm, or refine the hypotheses

The runsheet guides execution with 5 phases, timeboxes, 5 pitfalls, and clear stop criteria.

Open runsheet

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

Deep dive

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.

Output artifacts
Hypothesis LogTest PlanEvidence NotesDiagnosis Summary
Tags
troubleshootingdebuggingdiagnosis

Sources

Google SRE - Root Cause Analysis for Probing Incidentsre.googleWhat is a Hypothesis - Types, Examples and Writing Guideresearchmethod.net
Artifact templates
Hypothesis-Driven Troubleshooting Working TemplateCompact working template for Hypothesis-Driven Troubleshooting with context, input, output artifacts, and next step.
markdown

hypothesis-driven-troubleshooting-working-template.md

Compact working template for Hypothesis-Driven Troubleshooting with context, input, output artifacts, and next step.

Hypothesis-Driven Troubleshooting Working Template

Goal

Troubleshooting approach that turns symptoms into testable hypotheses and focused tests.

Context

When and for what do we use this method?

Input

Which data, observations, decisions, or materials are available?

Execution

Short notes along the runsheet.

Output artifacts

  • Hypothesis Log:
  • Test Plan:
  • Evidence Notes:
  • Diagnosis Summary:

Assumptions and open questions

  • ...

Decision / Next step

Owner, date, and success signal.

When to choose differently

Short decision aid for existing alternatives.

5 Whys

Statt Hypothesis-Driven Troubleshooting, wenn ihr ohne Testplan schnell von Symptom zu möglicher Ursache fragen wollt.

Root Cause Analysis

Statt Hypothesis-Driven Troubleshooting, wenn du Ursachen systematisch eingrenzen und nicht bei Symptomen stehen bleiben willst.

Similar methods

All methods
Engineering
Fault Isolation

Turns technical problems, hypotheses, and next steps into a tangible result by clarifying the symptom and system boundaries, breaking the fault space into areas, and narrowing the affected area.

Operations
Change Analysis

Turns workflows, data, causes, and improvements into a tangible result by describing the deviation, choosing a comparison case, and deriving causes and actions.

Engineering
Failure Scenario Analysis

Turns technical problems, hypotheses, and next steps into a tangible result by defining the system or process, collecting plausible failure scenarios, and deriving tests, 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

Turns technical problems, hypotheses, and next steps into a tangible result by choosing a common use case, describing a best-practice path, and integrating feedback and exceptions.

Engineering
Kanban

Turns technical problems, assumptions, and next steps into a tangible result through mapping the workflow, making work visible, and improving bottlenecks.