What's the first step in breaking down a complex problem?

Write the problem as one specific question. A vague problem statement produces a vague breakdown, and sharpening the question first makes everything downstream easier.

How do I know when I've broken a problem down enough?

When each branch is something you could actually check, assign, or answer directly, not when it simply feels detailed. If a branch still feels vague, split it again.

How to Break Down a Complex Problem (Without Overcomplicating It)

Most complex problems aren't actually complicated once you split them correctly — they're just big and undifferentiated. The skill isn't intelligence, it's a repeatable way of splitting.

Why big problems feel stuck

A problem like "our onboarding isn't working" is hard to act on because it's really several smaller problems tangled together — a confusing first screen, a slow signup flow, unclear next steps, missing follow-up. Tackled as one blob, it's overwhelming. Split into its actual parts, each piece is manageable on its own.

The method: one root question, MECE splits, repeat

State the problem as one specific question. "Why is onboarding completion only 40%?" beats "onboarding isn't working."
Split it into parts that don't overlap and don't leave anything out — see What Does MECE Mean?. For onboarding, that might be by step (signup, setup, first action) or by cause (confusing UI, missing motivation, technical friction).
Push deeper on whichever branch is most likely to matter. If signup has 90% completion but "first action" has 35%, that's where you branch again.
Stop at a branch you can actually check or act on. "Users don't understand what to do after setup" is a hypothesis you can test. "Onboarding is confusing" is not.

This is exactly the structure of an issue tree — the method has a name because it's used constantly in consulting, but it's not consulting-specific.

A trap to avoid: solving before structuring

The instinct with a hard problem is to jump straight to a fix. Structuring first — even for five minutes — usually surfaces that the "obvious" fix only addresses one branch, and there were two or three others you hadn't considered. A little structure upfront is cheaper than redoing work later.

Another trap: over-structuring

Not every problem needs five levels of branches. Split until each piece is something you can actually act on, then stop. A tree that's technically more detailed but no more actionable is just extra overhead.

Try it on a real problem

The best way to get faster at this is to practice on a problem you actually have — not a textbook example. Meceify gives you a blank canvas to break it down visually, drag branches around as your thinking shifts, and flag what's still unclear: build your first tree →