This article is about the process of taking a design spec for a new product or large feature, (usually in Figma) and breaking it down into tickets and sub tickets that can be assigned to developers.

Slice Horizontally, Not Vertically

The approach that comes most naturally for most people is to break the work down by feature group. "Let's start with Feature A, then move on to Feature B, then Feature C". If we have multiple developers on the project this also gives us neat seams along which to distribute responsibilities.

With Vertical Slices

With this approach, most of the value is delivered on the very last day.

This is risky for several reasons—you're betting months of work on assumptions that won't be tested until it's expensive to change course. But it's also demoralizing. The team ships nothing to users for a long time. Stakeholders grow impatient with demos that are perpetually "almost ready." And when the final deadline approaches, everything gets stitched together under pressure.

Instead, you should break out the User Types, and focus on end-to-end flows (horizontal slices).

Instead of asking "which features can we finish this month?", ask "who can use this product by the end of this sprint, and for what?". Each milestone now has a clear definition of done: a real person can accomplish a real task.

In this model, you might deliver basic functionality to an internal operations team in month one. It won't have every feature, but it will have enough for them to do their job better than yesterday. In month two, you expand—maybe to external power users, maybe to additional use cases. By month three, you're ready for broader rollout. Each step is usable, testable, and valuable on its own.

This forces hard prioritization decisions upfront. You can't hand-wave about which features are essential when you're committing to ship something usable in two weeks. But those decisions were always going to be made—the question is whether you make them deliberately at the start or frantically at the end.

This dramatically shortens feedback loops. When User Type A starts using the product in month one, you learn things that inform what you build for User Type B in month two.

The other benefit is cultural. Teams that ship real value every month build momentum and build morale as more of their work goes live.