How To Break A Complex Problem Into Solvable Parts

Problems stay complex longer than they should because of two tendencies that reinforce each other.

The first is the solutioning reflex: the urge to generate answers before fully understanding the problem. This is culturally rewarded — appearing to know what to do reads as competent. The person who says "let me think about the structure of this before we talk about solutions" can look indecisive. The result is high-velocity motion in the wrong direction.

The second is complexity as status signal. In some environments, maintaining that your domain is complex and hard to understand is a way of protecting territory. If the problem is simple, anyone can solve it. If it's complex, you need the expert. This is not entirely cynical — some domains genuinely are hard — but the reflex to preserve apparent complexity is real and worth naming.

Decomposition cuts through both. It makes the problem legible to everyone in the room. It reveals which parts are genuinely hard and which are not. It shifts the conversation from "how do we handle this?" to "who handles which part?" This is almost always a productive shift.

Hierarchical decomposition is systematic. You start with the problem at the top level and recursively break it into sub-problems until you reach components that are small enough to have clear owners and clear approaches.

The classic example is the McKinsey issue tree. Start with the central question. Branch it into major sub-questions. Branch each of those further until you reach "leaf nodes" — specific, answerable questions that individual team members can own.

The discipline is in the branching logic. Each branch should represent a genuinely different class of the problem, not just a restatement with different words. "Sales are low" broken into "sales are low in Region A" and "sales are low in Region B" is a geographic breakdown — useful if the regions are genuinely different. "Sales are low" broken into "we're not reaching enough prospects" and "we're not converting the prospects we reach" is a process breakdown — different and often more useful.

The choice of how to break the problem determines what you look at and what you miss. There's no objectively correct decomposition — only more and less useful ones for the question at hand.

Before generating solutions, map the constraints. This is counterintuitive to people who think of constraints as the enemy of good ideas. Constraints are actually clarifying. They tell you where the real problem is.

Types of constraints:

Hard constraints — cannot be violated. Legal requirements, physical laws, absolute budget ceilings. Any solution that violates a hard constraint is not a solution.

Soft constraints — strong preferences that can be adjusted under sufficient pressure. Budget targets (as opposed to limits), timelines, team composition. These constrain the solution space without eliminating options entirely.

Hidden constraints — the most dangerous. Assumptions that function like constraints without being explicitly recognized as such. "We've always done it this way" is a hidden constraint. "Our customers expect X" might be a hidden constraint based on outdated data. Surfacing hidden constraints often reveals that the solution space is larger than it appeared.

A useful exercise: generate a list of constraints for your problem, then mark each H (hard), S (soft), or X (hidden/uncertain). Then ask: if I could remove any one constraint, which would change the problem most? That constraint is probably worth examining closely.

Every plan is a bet on a set of assumptions being true. Most plans don't make their assumptions explicit — which means the bets are being placed without awareness.

The practice is simple: for any approach you're considering, ask "what has to be true for this to work?" and write down every answer you generate. Force yourself to be specific. Not "the market has to want this" but "at least 15% of mid-market SaaS companies have this problem as a top-three priority."

Then evaluate each assumption on two dimensions: - How confident are you that it's true? (High / Medium / Low) - How much does the plan depend on it? (High / Medium / Low)

The dangerous assumptions are Low Confidence + High Dependency. These are the ones that will kill your plan. Either find a way to validate them before committing resources, or redesign the approach so it doesn't depend on them.

This is what "first principles thinking" actually means in practice. It's not about being iconoclastic or contrarian. It's about identifying which foundational assumptions you've taken for granted, checking whether they're solid, and rebuilding your reasoning from the ones that are.

MECE (Mutually Exclusive, Collectively Exhaustive) is a quality check for your decomposition, not a method for generating it. Once you have a breakdown, run the two-part test:

Mutually Exclusive: Is there overlap between the parts? If two sub-problems share territory, you'll confuse causes and double-count solutions. The fix is clearer boundary-setting between the parts.

Collectively Exhaustive: Do the parts cover the whole problem? Is there territory that none of the parts addresses? If so, you have a blind spot built into your decomposition. The fix is either adding a part or reconsidering how you've drawn the boundaries.

Perfect MECE is an ideal, not always achievable. But running the check will catch most structural errors in your problem breakdown before you spend weeks working on a decomposition that has a logical hole in it.

A problem that hasn't been decomposed cannot be effectively delegated. "Handle the growth problem" is not a clear assignment. "Own the analysis of our new customer acquisition channels for the next six weeks, specifically focusing on cost per acquisition and lead quality across channels, and bring a recommendation on where we should shift budget" — that's an assignment. The specificity comes from decomposition.

This is why good managers tend to be good problem decomposers. They don't necessarily do the analytical work themselves — but they can break the problem into pieces that map onto people's capacities and areas of expertise. The decomposition is the management act.

When you encounter a problem you can't hand off, ask: is it genuinely inseparable, or just not decomposed yet?

Stuck is almost always a decomposition failure. The problem hasn't been broken down to the level where any single piece is approachable.

The recovery move: zoom to the smallest possible piece. Not "solve the retention problem" — but "talk to five churned customers this week and listen for the most common reason they left." Not "fix the architecture" — but "understand what specifically breaks when two services try to write to the database simultaneously."

The smallest tractable piece gives you a place to start. Starting generates information. Information refines your decomposition. Better decomposition reveals the next step. Progress accelerates.

Decomposition is a learnable skill, not a personality trait. It can be practiced on any problem you encounter, including trivial ones. The habit of asking "what are the parts of this?" before asking "what do I do?" will improve your thinking across every domain you work in. Start with a problem you're stuck on right now. Write the problem at the top of a page. Draw two branches. Name them. Then do it again for each branch. See what you find.