Problem solving subassemblies provide structured processes for moving from a stated problem to a high-quality solution.
Trigger: Symptoms that keep recurring; root cause analysis
Origin: Taiichi Ohno, Toyota Production System
Composed From: Variable Isolation + Decomposition
Ask “why?” recursively, at least five times. Each answer becomes the input to the next “why?”
Example:
Problem: the machine stopped
Why? — overload
Why? — inadequate lubrication
Why? — lubrication pump malfunction
Why? — worn pump shaft
Why? — no strainer, metal chips got in
Root cause: no strainer on the lubrication pump
Addressing the symptom (restart the machine) fixes nothing. Addressing the root cause (add a strainer) prevents recurrence.
Known limits: Linear causal chains are a simplification. Complex systems have multiple interacting causes, not a single root. In complex domains, use five whys to identify contributing factors, not the definitive root cause.
Trigger: Problems that feel impossible; stuck problems with “insurmountable” constraints
Composed From: First Principles + Assumption Surfacing
Protocol:
List all the constraints on the problem
For each constraint, ask: Is this actually a constraint, or an assumption I’m treating as a constraint?
Identify the one constraint whose removal would make the problem trivially easy
Ask: What is the cheapest way to remove or relax that constraint?
Many “impossible” problems are impossible only given a particular constraint that turns out to be negotiable, removable, or based on an outdated assumption.
Known limits: Not all constraints can be relaxed, some are genuine physical or ethical limits. The skill is accurately distinguishing real constraints from assumed ones.
Trigger: Planning; reverse-engineering successful outcomes; strategy
Composed From: Inversion + Chunking + Operationalizing
Protocol:
Define the desired end state precisely and concretely
Ask: What is the last thing that must happen before the end state?
Ask: What must happen before that?
Recurse until you reach something you can do today
Working backward is more reliable than working forward because it ensures that every step in the plan is actually necessary for the goal, not merely plausible-seeming or traditional.
Amazon’s PR/FAQ process uses this explicitly: Write the press release for the finished product before building it. Every subsequent decision is evaluated against whether it helps you get to that press release.
Known limits: Requires a clearly defined end state. If the goal is vague, working backward produces a vague plan. Operationalizing must precede working backward.
Trigger: Creative problems; situations where premature commitment is a risk
Composed From: Decomposition + Category Questioning + Chunking
Related Modules: Creative Schema, Constraint Relaxation, First Principles
List all possible approaches to a problem before evaluating any of them. Defer all judgment until the space is mapped.
The discipline of deferring evaluation is counterintuitive but important. Evaluative judgment during generative thinking systematically suppresses promising-but-incomplete ideas before they can be developed. Most prematurely abandoned approaches would have been viable if given more development time.
IDEO’s design thinking process formalizes this as “diverge before you converge," the brainstorm phase must be complete and judgment-free before the evaluation phase begins.
Known limits: In time-pressured situations, exhaustive solution space mapping is impractical. Set a time box: Generate as many approaches as possible in N minutes, then evaluate.
Trigger: Novel problems where existing approaches have been exhausted
Composed From: Analogical Reasoning + Archetype Recognition + First Principles
Find a solved problem in a different domain with the same underlying structure. Import and adapt the solution.
The history of innovation is substantially a history of analogical transfer. Darwin imported Malthus’s economics into biology to develop natural selection. Shannon imported Boltzmann’s thermodynamics into communication theory to develop information theory.
Protocol:
Strip your problem to its abstract structural form (remove all domain-specific content)
Ask: What other domain has this structure?
Find the solution in that domain
Map it back to your domain
Adapt where the mapping is imperfect
Known limits: False structural similarity, the analogy seems to hold but breaks down at the critical step. Always test the mapping at each step before trusting the transferred solution.