the ability to decompose a large feature into independently shippable increments is one of the most underrated skills in software. it's fundamentally a design skill, not a project management one.
a bad decomposition ships pieces that aren't useful on their own. a good decomposition ships pieces that each deliver value, even if the full vision isn't realized yet. the difference is whether you're building a car wheel-by-wheel (useless until complete) or building a skateboard, then a scooter, then a bike, then a car (useful at every stage).
the skateboard metaphor is overused but it captures something true. each increment should be a complete thing, not a partial thing. the increment might be small and limited, but it should work and deliver value to someone.
how i decompose
i start with the end state and work backwards, asking "what's the smallest version of this that someone would use?" that becomes increment one. then i ask "what's the next thing that would make the biggest difference?" that's increment two. and so on.
the key constraint is that each increment must be deployable and usable independently. if increment two only makes sense after increment three, the decomposition is wrong.
status: practical note. updated with examples from recent projects.