Most problems feel harder than they are because they arrive with their full emotional weight attached. The techniques for structured problem-solving work precisely because they separate the cognitive process of understanding a problem from the emotional reaction to having it. This separation is not cold or analytical in a bad sense; it is what makes clear thinking possible when it matters most.
The eleven steps below draw from cognitive psychology, decision science, and organizational problem-solving research. They are not a rigid algorithm. They are a framework for thinking more deliberately in situations where instinct alone tends to produce poor results.
Step 1: Write the Problem Down in One Sentence
This sounds trivial and consistently proves not to be. A problem you can state precisely in a single sentence is a problem you understand well enough to begin solving. A problem that requires three paragraphs to describe is usually either multiple problems that need to be separated, or a problem that has not been adequately defined yet.
The constraint of one sentence forces clarity. It forces you to identify what is actually broken (the symptom or the cause?), who it affects, and what would constitute a resolution. Many problems, when subjected to this constraint, reveal themselves to be different problems than initially assumed.
Step 2: Distinguish Between What You Know and What You Assume
Write two columns: “What I know for certain” and “What I am assuming.” Problems get harder when assumptions are treated as facts. A business problem that feels unsolvable when you assume the customer base is shrinking becomes a different problem when you recognize that you actually do not have the data to confirm this.
This step also surfaces hidden assumptions that might be blocking solutions. “We cannot do X because of Y” is often an assumption about Y rather than a verified fact about it.
Step 3: Define What Success Looks Like
Before generating solutions, define what you are trying to achieve. Be specific. “Fix the problem” is not a success criterion. “Reduce customer churn by 20% within 90 days” is. “Feel better about the situation” is not. “Have a clear decision made and communicated to everyone affected by Friday” is.
Clarity about the endpoint prevents two common failure modes: solving the wrong problem (optimizing for something that is not actually the core issue) and moving the goalposts mid-solution (changing what success means as the difficulty of achieving it becomes apparent).
Step 4: Ask What Is Causing the Problem, Not Just What the Problem Is
Symptoms and causes are different. Treating the symptom without addressing the cause produces the same problem again in a different form. The “5 Whys” technique, developed by Toyota and now standard in process improvement frameworks, asks you to ask “why?” five successive times to move from the observable symptom to the underlying cause.
A website with declining traffic (symptom) might have declining traffic because content quality dropped (why 1) because the editorial process changed (why 2) because the editor who maintained standards left (why 3) because compensation was below market rate (why 4) because budget decisions prioritized other departments (why 5, root cause). Solutions at each of these levels produce different results.
Step 5: Generate Options Without Evaluating Them
Brainstorming is only useful if evaluation is explicitly postponed. The moment an option gets criticized during generation, the generation process stops. People filter ideas before expressing them, knowing criticism is coming.
Set a timer for 10 minutes. Write every possible approach, including impractical and absurd ones. The constraint of not evaluating during this phase often surfaces creative options that would otherwise be self-censored. The absurd ideas sometimes contain seeds of practical solutions.
Step 6: Add One Constraint-Violating Idea
After step 5, deliberately generate one option that assumes a core constraint does not exist. What would you do if time were not a constraint? If money were not a constraint? If the organizational politics did not exist?
This exercise often reveals whether the constraints you are working within are actual (genuinely fixed) or assumed (negotiable if approached differently). It sometimes produces the best solution in the list.
Step 7: Evaluate Options Against Your Success Criteria
Return to the success criteria you defined in step 3 and score each option against them. A simple scoring matrix (rate each option on each criterion from 1-5) produces a more defensible ranking than pure intuition. It also makes the tradeoffs explicit: an option that scores high on speed and low on cost might be preferable to one that scores moderate on both, depending on which criterion matters more in this specific situation.
Step 8: Identify the Risks of Your Top Option
Pre-mortem analysis asks: “If we implement this solution and it fails, what will have gone wrong?” This is more productive than asking “could this go wrong?” because it assumes failure and works backward, surfacing specific failure modes rather than vague concerns.
For each identified risk, determine whether it is addressable (build in a mitigation) or acceptable (acknowledge it and proceed anyway with awareness). Unidentified risks are the ones that derail implementations.
Step 9: Make the Decision and Commit a Timeline
Analysis can be indefinitely extended. The point at which additional analysis produces diminishing returns (rather than genuinely new information) varies by problem, but most people reach it far earlier than they stop analyzing.
Once you have enough information to have reasonable confidence in your chosen option, commit a decision and attach a specific implementation timeline. Decisions without timelines tend to drift. A decision with a clear next step, a responsible person, and a date becomes substantially more likely to produce change.
Step 10: Implement in Phases Where Possible
For complex problems, incremental implementation with defined checkpoints is more reliable than a single large-scale rollout. Phased implementation allows for early feedback, course correction, and evidence-gathering about whether the solution is working before full commitment of resources.
Define in advance what you will look for at each checkpoint to determine whether to continue, adjust, or stop. This criterion should be established before implementation begins, when you are still thinking clearly, not in the middle of it when you are invested in the solution working.
Step 11: Debrief After Resolution
Once the problem is resolved (or the implementation is complete), take 30 minutes to document: what worked, what did not, what you would do differently, and what the process revealed about underlying causes that might produce similar problems in the future. This step is consistently skipped and consistently valuable. Problems that are not debriefed tend to recur.
The goal is not blame attribution but learning capture: what information does this resolved problem give us about how to prevent or solve similar problems faster in future?
