(What the Problem-Solving Process Actually Looks Like)

This is the second post in the series “Problem First: AI-Assisted Problem Solving for Organizations That Can’t Afford to Get It Wrong.”

In the first post in this series, I argued that organizations are consistently bad at solving problems—not because of the lack of talent or effort, but because they skip the most important step: understanding what problem they actually face. The Tylenol reflex, the technology-centric trap, the confusion of puzzles and messes—these are all symptoms of the same underlying failure. Organizations treat problem solving as an instinct when it should be treated as a discipline.

The response to that post confirmed something I’ve suspected for a long time: people overwhelmingly agree that problem definition matters. Almost nobody disagrees with the principle. And yet, when you ask a simple follow-up question—so what does a rigorous problem-solving process actually look like?—the room goes quiet.

That silence is the problem. We have a broad consensus that structured problem solving is important, but almost no shared understanding of what it involves. Everyone knows you should “define the problem before solving it.” Few can tell you what that means in practice: what stages the process includes, what each stage produces, what happens when you skip one, and how the stages connect to each other.

This post is my attempt to fill that gap. What follows is not a theory. It’s a map, a five-stage anatomy of what rigorous problem solving looks like, from the moment a problem is first felt to the moment solutions are ready to be acted upon. Each stage has a defined purpose, a clear output, and a predictable failure mode when skipped. The stages build on each other. Skip one, and everything downstream is compromised.

I have no doubt that other versions of this process exist, and I would welcome the chance to see and discuss them. Some may include additional stages; others may organize the work differently. But I am confident that any viable problem-solving process must include, at a minimum, the five stages outlined below. Omit any one of them, and the process won’t get streamlined. It’ll become incomplete.

Stage 1: Problem Intake and Framing

The purpose

Capture the problem as it is actually experienced—not as it has been prematurely diagnosed.

What this stage involves

Every problem-solving process begins with someone saying, in effect, “Something is wrong and I want to fix it.” That initial statement is precious. It’s also almost never the right problem definition.

The purpose of the first stage is to create space for the full picture to emerge. This means inviting a description of the issue that includes not just the headline complaint but the context surrounding it: where the problem manifests, when it started, who is affected, what has already been tried, why the prior attempts to solve the problem have been unsuccessful, and what’s at stake if it isn’t resolved.

Crucially, this stage must welcome messy, incomplete, and uncertain inputs. If people feel they need a polished problem statement before they can begin, they will—consciously or not—skip the ambiguity that often contains the most important clues.

The output

A structured problem statement that reflects three things: what is happening, where it manifests, and why it matters. This statement becomes the anchor for everything that follows. It is not yet a diagnosis. It is a clear, honest articulation of the situation as currently understood.

What goes wrong when you skip it

This is the stage most organizations believe they perform. They actually don’t. What typically passes for problem framing is a meeting where someone in authority declares what the problem is, and everyone else nods. The declaration feels like framing. It isn’t. It’s a premature conclusion dressed up as a starting point.

Consider how many corporate initiatives begin with a solution embedded in the problem statement: “We need to improve our digital presence” (solution: digital). “We need to reduce headcount in the operations division” (solution: layoffs). “We need an AI strategy” (solution: AI). In each case, the “problem” has already been defined in terms of a preferred answer. The framing stage, if it happens at all, becomes a formality, a rubber stamp on a decision that was made before the process began.

The cost is that the actual problem, the one hiding behind the executive’s confident declaration, never gets examined.

Stage 2: Clarification, Assumptions, and Boundaries

The purpose

Reduce ambiguity by distinguishing what is known from what is assumed—and surface the constraints that will shape any viable solution.

What this stage involves

Once a problem has been framed, it needs to be pressure-tested. This means asking targeted follow-up questions to resolve major unknowns, identify constraints—organizational, legal, cultural, financial, technical—and, most importantly, draw a sharp line between facts and assumptions.

The distinction between facts and assumptions is the single most underrated element of problem solving. Organizations routinely treat assumptions as facts, especially when those assumptions are long-held, widely shared, or endorsed by senior leadership. The longer an assumption has gone unquestioned, the more solid it appears—and the more dangerous it becomes.

The output

A confirmed working frame, which includes: the key assumptions underlying the problem statement (explicitly labeled as assumptions, not facts), the known constraints that any solution must respect, and the areas of genuine uncertainty that remain. This output protects every stage that follows. If the assumptions are wrong, it’s better to discover it at this stage than after solutions have been generated and resources committed.

What goes wrong when you skip it

The paint pump. The food additive. Both stories from the first post in this series are textbook examples of what happens when Stage 2 is skipped. In the paint pump case, the engineers held an unexamined assumption: the problem was mechanical. Nobody asked whether the indoor and outdoor testing conditions were truly equivalent. Nobody distinguished between what was known (the pump clogs outdoors) and what was assumed (the clogging is caused by the pump design). The assumption shaped the entire problem definition—and nearly led to a costly crowdsourcing campaign aimed at solving a problem that didn’t exist.

The food company’s assumption was equally invisible and equally costly: the preparation process was untouchable. “We can’t change the process; it’ll be too expensive!” This wasn’t a fact. It was a belief—one that, once surfaced and challenged, turned out to be wrong. The actual solution was a minor, inexpensive process change.

The pattern is always the same: an assumption that nobody identifies as an assumption silently narrows the solution space, often eliminating the best answer before the search even begins.

Stage 3: Root Cause Analysis

The purpose

Move from symptoms to plausible underlying causes.

What this stage involves

This is the analytical center of gravity of the entire process. With a well-framed problem and tested assumptions in hand, the task now is to ask: why is this happening? Not just the proximate cause, but the structural, process-level, human, and strategic factors that allow the problem to persist.

Rigorous root cause analysis does several things that distinguish it from casual diagnosis. First, it generates multiple hypotheses, not just one. The goal is not to converge prematurely on a single explanation but to map the plausible causal landscape. This is what distinguishes root cause analysis from simpler diagnostic methods like the popular 5 Whys technique. The 5 Whys drives toward a single explanation as quickly as possible, useful for straightforward, linear failures, but dangerously reductive when the problem has multiple contributing causes operating at different levels. Root cause analysis resists this premature convergence.

Second, root cause analysis assigns confidence levels: some root causes will be well-supported by evidence; others will be tentative, requiring further investigation. Third, it explicitly resists the temptation to jump to solutions.

This last point deserves emphasis. The gravitational pull toward solutioning is strongest at precisely this stage, because the root causes themselves often suggest obvious fixes. But “obvious” and “correct” are not synonyms. A root cause analysis that collapses into solution generation has failed at its primary task.

The output

A root cause map, which includes: primary root causes, contributing factors, and any open questions that further investigation might resolve. This map is what makes the difference between solutions that address symptoms and solutions that address disease.

What goes wrong when you skip it

When organizations skip or rush root cause analysis, they get solutions that treat symptoms. And symptoms, once treated, come back.

The pattern is familiar to anyone who has watched organizations cycle through repeated “fixes” for the same persistent problem. Employee engagement is low, so the company launches a wellness program. Engagement stays low. They add flexible hours. Still low. They redesign the office. Still low. Each intervention addresses a plausible surface cause. None reaches the root—which might be a toxic management culture, a misalignment between the company’s stated values and its actual practices, or a structural problem with how work is organized. Without root cause analysis, each new initiative is another round of Tylenol: temporarily soothing, fundamentally useless.

IBM’s recent research on AI agent deployments reveals the same pattern at the technology level. Many AI implementations stall after the pilot phase, not because the technology fails, but because organizations try to force-fit advanced tools onto workflows whose underlying problems were never diagnosed. Technology works. The process it was applied to was broken from the start.

Stage 4: Solution Generation

The purpose

Generate diverse, actionable, and non-obvious options that are directly mapped to the root causes identified in the previous stage.

What this stage involves

If the first three stages have been done well, solution generation becomes a fundamentally different exercise than what most organizations are used to. Instead of brainstorming in a vacuum—“what could we do about this?”—the question becomes sharply focused: “given these specific root causes, these constraints, and these assumptions, what interventions would address the actual drivers of the problem?”

Good solution generation has three characteristics. First, the solutions are mapped to root causes. Every proposed solution should be traceable back to a specific cause it addresses. Solutions that can’t be linked to a diagnosed root cause are guesses, however sophisticated they may appear. Second, the solutions are varied in ambition. A useful solution set includes incremental options (low risk, quick implementation), moderate options (meaningful change with manageable disruption), and bold options (transformative but demanding). This range is important because organizations need to choose based on their appetite for risk and available resources. Third, the solutions are honest about trade-offs. Every solution has costs, risks, and second-order effects. Presenting options without trade-offs isn’t optimism; it’s malpractice.

The output

A portfolio of solution directions, each specifying what root cause it addresses, why it might work, and what trade-offs and risks it carries.

What goes wrong when you do it badly

Solution generation is, paradoxically, the stage organizations are most comfortable with—and the one where the most established techniques exist, from brainstorming and design sprints to crowdsourcing (and other open innovation approaches). The problem is rarely a lack of methods. It’s that these methods are deployed without the foundation that the first three stages provide, which means they generate solutions untethered from a properly diagnosed problem.

Two failure modes dominate at this stage. The first is what I call best-practice dumping: offering generic industry solutions that aren’t connected to the specific problem’s root causes. “Companies in your industry typically do X” is not a solution to your problem; it’s a solution to someone else’s. The second failure mode is single-answer bias: converging on one recommendation before alternatives have been genuinely explored. This often happens when the person generating solutions has a favorite methodology, a pre-existing relationship with a vendor, or simply a strong intuition. Intuition is valuable. But a process that produces only one option hasn’t explored the solution space; it’s merely confirmed a prior preference.

Stage 5: From Analysis to Action

The purpose

Translate the problem-solving work into committed next steps—so that good analysis doesn’t die in a slide deck.

What this stage involves

This is the stage that separates organizations that think well from organizations that act well on their thinking. The previous four stages can produce a superb diagnosis and a compelling set of solutions. None of that matters if the work stops at the report.

Stage 5 is where the analysis meets organizational reality. It asks: which solutions should be pursued, in what sequence, and by whom? It requires honest conversation about priorities, resources, timelines, and accountability. Specifically, it involves three activities. First, stress-testing the preferred solutions: probing assumptions, anticipating implementation barriers, and identifying what could go wrong. Second, sequencing and prioritizing: determining which actions to take first based on impact, feasibility, and dependencies. Third, assigning ownership: ensuring that every committed action has a named person responsible for it, a timeline, a clear definition of what success looks like, and the resources—budget and people—allocated to carry it out. An initiative launched without dedicated resources isn’t a commitment; it’s a wish.

The output

An action plan naming owners, allocating resources, defining timelines, and establishing success criteria. Not a menu of possibilities, but a set of commitments.

What goes wrong when you skip it

This is perhaps the most quietly devastating failure in problem solving: the analysis-to-action gap. Organizations invest real effort in understanding a problem, generate thoughtful solutions—and then nothing happens. The findings sit in a document that gets circulated, praised, and ignored. Six months later, someone asks why the problem hasn’t been addressed, and the cycle starts again from scratch.

The analysis-to-action gap is not a failure of will. It’s a failure of process. When a problem-solving effort ends with “here are some options to consider,” it draws the process boundary in the wrong place. The most failure-prone moment—the transition from analysis to action—is left outside the structured process, handled ad hoc, with no discipline applied to it.

Stage 5 exists to bring that transition inside the process itself: to ensure that the same rigor applied to diagnosing the problem and generating solutions extends all the way through to deciding, resourcing, and executing.

The Chain, Not the Links

It’s tempting to treat these five stages as a checklist—five boxes to tick on the way to a solution. That would miss the point. The power of the process lies not in the individual stages but in their connection. Each stage produces something that the next stage depends on. Skip Stage 2, and Stage 3 will operate on unexamined assumptions. Rush Stage 3, and Stage 4 will generate solutions to the wrong causes. Omit Stage 5, and the entire effort evaporates.

The chain matters more than the links.

And here is what makes this more than an academic exercise: the organizations that need this process most—the ones operating with thin margins, limited staff, and no room for wasted effort—are the ones least likely to have it. Small and mid-sized enterprises. Nonprofits. Mission-driven organizations working under constant resource pressure.

These organizations can’t afford to solve the wrong problem twice. They can’t absorb the cost of the Tylenol reflex. They need a process that is rigorous without being cumbersome, structured without being bureaucratic, and accessible without requiring a dedicated innovation department.

That’s what the next post in this series will address: why SMEs and nonprofits face a unique problem-solving deficit—and why the current moment, with AI tools rapidly becoming available, makes closing that deficit both more urgent and more possible than ever before.

Next in the series: “The Organizations That Need Problem Solving Most Are the Ones Doing It Least.”