Problem Decomposition — Make the Elephant Edible

A horizontal split builds the database, then the API, then the UI — nothing works until the last week. A vertical slice picks one tiny user journey and builds it through every layer. The first slice is ugly; the second is faster; by the fifth you have a working product spine.

• Walking skeleton — end-to-end version with one trivial feature wired through every layer including deploy. Now every later slice is just adding muscle.
• Tracer bullets (Pragmatic Programmer) — same idea: shoot one round through, see what you hit, adjust.
• Steel thread — same again, different name; teams use whichever metaphor sticks.

• "Could one person finish it in two days?" If not, split again.
• "Does it change observable behavior?" If no, it's a refactor disguised as a feature.
• "Could we ship it tomorrow if we had to?" Forces honesty about hidden dependencies.
• "Is it independently testable?" If not, you'll never trust it landed.
• INVEST heuristic — Independent, Negotiable, Valuable, Estimable, Small, Testable.

• Premature decomposition. Splitting before you understand the shape of the problem produces nonsensical pieces.
• Slices that aren't really vertical. "Just the API" is a horizontal slice in disguise — nobody can use it.
• Big-bang refactors. Stop the world to refactor for two months = high risk. Refactor in slices, behind flags.
• Lost forest for trees. A roadmap of 200 tiny tickets with no narrative loses people. Keep an outcome-level summary.
• YAGNI gone wrong. "We'll add it later" sometimes means "we'll never add it" — for cross-cutting concerns (auth, audit), build for the second use case from day one.