A Problem Hypothesis Review is a structured check of the explanations a team is considering for a problem.
The purpose is not to vote for the most popular cause. It is to decide which hypothesis deserves the next test.
State each hypothesis clearly
A useful hypothesis describes a possible cause-and-effect relationship. For example: when fixture pressure falls below the normal range, the part shifts during drilling and hole position moves out of tolerance.
Hypothesis-Driven Problem Solving helps turn assumptions into explanations that can be tested. Avoid labels such as operator error or machine issue because they are too vague to test well.
Review supporting evidence
Ask what facts make the hypothesis plausible. Evidence may include timing match, process comparison, data pattern, Gemba observation, or historical occurrence.
Problem-Solving Evidence Plan helps define the next evidence needed to reduce uncertainty. A hypothesis should not gain strength simply because several people believe it.
Review contradictory evidence
Strong problem solving actively looks for facts that do not fit the explanation. Examples include the defect occurring when the suspected cause is absent, the suspected cause being present on good product, or timing that does not match.
Contradiction is valuable because it prevents wasted testing.
Review testability
Ask whether the hypothesis can be tested safely and practically. Cause Verification helps confirm whether changing a suspected cause changes the problem condition.
A useful test should create information, not only activity.
Consider risk and learning value
Some hypotheses deserve earlier testing because they involve safety, customer escape, or major equipment risk. Others deserve priority because one test can eliminate several explanations at once.
Is / Is Not Analysis helps compare where, when, and under what conditions a problem does and does not occur.
Use tests that reduce the most uncertainty with reasonable effort.
Decide the next test
The review should end with a selected hypothesis, test method, owner, timing, and expected evidence.
Do not leave with a ranked list and no experiment.
Common mistakes
Voting on causes, allowing vague hypotheses, reviewing only supporting evidence, ignoring contradictions, selecting the easiest test regardless of learning value, running several tests without a decision rule, and treating an unproven hypothesis as the root cause are common mistakes.
Practical sequence
- state the problem clearly.
- list plausible hypotheses.
- review supporting evidence.
- review contradictory evidence.
- assess testability.
- consider risk and learning value.
- select the next hypothesis to test.
- define the expected evidence.
- update the hypothesis set after the result.
The practical lesson
A Problem Hypothesis Review protects the team from jumping to causes. The next test should be chosen because it is likely to reduce uncertainty, not because the explanation sounds convincing.