Sequencing Work So Value Lands Early
Order the work so something useful reaches people in the first slice, and let the second slice — not a guess — justify the foundation.
The ask, the obvious response, and how it goes wrong
Every lesson starts where the work starts: someone asked for something, and the first response that comes to mind has a problem.
In what order should we build this so something useful lands before the whole thing does?
Returns self-service is the team's next project. The tech lead proposes: "First we model returns properly — a return aggregate, a state machine, carrier adapters — then the API, then the order-page UI, then the support dashboard. Eight weeks, and we will never have to redo it."
Build the foundation first. A clean return model and state machine make every later piece simpler, and doing it once, properly, avoids a rewrite. The UI is the easy part; leave it for the end.
Nothing reaches a customer for eight weeks. Support keeps handling every return by email the whole time, and nobody learns whether customers would even use self-service.
- Nothing reaches a customer for eight weeks. Support keeps handling every return by email the whole time, and nobody learns whether customers would even use self-service.
- The state machine is designed for returns the team imagines — partial returns, exchanges, multi-carrier — before a single real return has gone through it. The first real case (one item returned from a bundle) does not fit, and "never have to redo it" becomes the first redo.
- At week five priorities shift — a payments incident, a holiday freeze. The team leaves with a well-designed return aggregate and no feature. Layer-first work has no useful midpoint.
- Support, who asked for this, sees nothing for two months and builds its own workaround in a spreadsheet, which becomes something the eventual feature has to integrate with.
What is really going on
- Value lands when a slice reaches a user: a thin path through every layer that does one real thing end to end. Layers produce value only when the last one is done; slices produce it with each one.
- The first slice should deliver value with the least foundation that is honest: a "Start a return" button on the order page that collects the items and reason and opens a pre-filled support ticket. No state machine, no carrier integration — and support stops re-typing order numbers from emails in week one.
- The second slice justifies the foundation. When the team adds printable labels for the main carrier, it needs return states (requested, label issued, received) — and it knows, from the first slice's real tickets, which states actually happen. The model gets built when a second concrete use needs it, shaped by the first.
- Each slice should be shippable on its own and useful if the project stops there. That is the test for a good sequence: if priorities change after any slice, what shipped still earns its keep.
- Sequencing is also risk ordering. Put the slice that answers the biggest unknown early — "will customers self-serve at all?" — not the slice that is most comfortable to build.
Layers produce nothing until the last one
The tech lead's plan is four layers: model, API, UI, dashboard. Each is useful only to the layer above it, so the first thing a customer or support agent can use arrives with the last layer. Until then, progress is real but invisible, and every week of it is a week in which the plan can be interrupted with nothing to show.
Slices cut the same work the other way. Each one goes through as many layers as it needs to do one real thing, and the foundation grows as the slices ask for it.
The first slice lands value; the second justifies the foundation
The first slice is allowed to be crude behind the scenes. A button that opens a support ticket is not a returns system, but it removes the worst part of support's day and tells you how many customers want to self-serve and why they return things.
The second slice is where the model earns its place. Labels need states, and by now there are a few weeks of real returns to design those states from. The model built at slice two is smaller and closer to reality than the one designed at week zero.
Weeks 1–3 return model and state machine. Weeks 4–5 API and carrier adapters. Weeks 6–7 order-page UI. Week 8 support dashboard. First user value: week 7.
Week 1 "Start a return" → pre-filled ticket. Weeks 2–3 label for the main carrier, with the return states it needs. Weeks 4–5 refund status on the order page. Weeks 6–8 support dashboard and second carrier, if still worth it. First user value: week 1.
Both plans end in a similar place if nothing changes. Only the slice-first plan is worth something if the project stops at week three — and it designs the model from real returns instead of imagined ones.
The stop test
For every slice, ask: if we stopped right after this, would we be glad we shipped it? A sequence where every answer is yes is robust to the reprioritisation that almost always comes. A sequence where the first few answers are "no, it only matters once the rest lands" is a layer plan wearing slice labels.
The stop test is also the easiest way to explain the plan to a tech lead who wants the foundation first. It does not argue that the foundation is unimportant; it argues about when the foundation is cheapest to get right.
The tech lead has posted the four-layer plan with "and we will never have to redo it". The PM is watching the thread.
"I think we should be more agile about this and ship something earlier. Can we skip the state machine for now?"
"I agree we need the return model — I want to build it in week two, when the label slice needs it, instead of week one. That way week one ships a 'Start a return' button that ends support's re-keying, and we design the states from two weeks of real returns. If priorities change after week one, support still has the button. The cost is a few days reworking the ticket path when the model lands; I think that is worth it."
When foundation first is right
Slice-first is the default for product work, not a law. Some foundations are expensive to change once anything depends on them, and there the order flips.
Should this project start with a slice or with the foundation?
when The foundation is internal and reversible, and the biggest unknown is whether people will use it.
cost Known rework when the foundation lands; messier intermediate code.
when Others will build on it immediately — a public API, a data model partners read, a migration of existing orders.
cost Weeks with no user value; design made with less evidence, so spend more on getting it reviewed.
when The path crosses several systems and the integration risk is the unknown.
cost A first week or two that proves the plumbing but gives users nothing yet.
How to do it
Most important first.
- List the user-visible outcomes first — support stops re-keying returns, customers get a label without emailing, finance sees refunds reconciled — and order them by value and by what each one teaches you.
- Cut the first slice so it lands something real in the first week or two, even if it leans on a manual step behind the scenes (The First Version That Teaches You Something).
- Build foundation in the slice that first needs it, and only as much as that slice needs. Record the shape you expect later in a decision record, without building it (Decision Records).
- Check every slice against the stop test: "If we stopped after this, would we be glad we shipped it?" If not, reorder.
- Name the foundation you are deferring and the risk you are accepting, so the tech lead's concern is recorded rather than overruled (Naming the Trade-off).
- Do the irreversible parts first and deliberately: a data model other systems will read, a public API, a migration of existing records. Deferring is cheap only for the reversible parts (Reversible vs Irreversible Decisions).
How to explain the decision
The sentences, the order, and what to lead with — for someone who did not make the call.
- Lead with what lands when: "Week one, customers can start a return from the order page and support gets a pre-filled ticket. Week three, they can print a label. The state machine arrives with the label, because that is when we need it."
- Address the foundation concern directly: "We are not skipping the return model. We are building it in the slice where we will know which states really happen, instead of guessing them now."
- Give the stop test as the reason: "If priorities change after week one, support still has the button. If we build the model first and priorities change, we have a model."
- Name what you are accepting: "We will rework the ticket-creation path when the state machine lands. That is a few days, and it buys six weeks of support not re-keying returns."
- "We will rewrite the ticket path anyway — why build it?" Because it ships in a week and support uses it for the six weeks the full model would take. The rework is a few days.
- "Doing it properly once is faster than doing it twice." When we know the shape, yes. Right now we would be doing it properly for returns we have imagined.
- "Support has waited this long, they can wait eight more weeks." They have been waiting while building a spreadsheet we will have to integrate with. Every week makes the final version harder.
What can go wrong
- Slices that are not slices: "slice one: the database tables" is a layer with a new name. If no user can see it, it is not a slice.
- The manual step behind the first slice is never replaced. Support is still processing pre-filled tickets by hand a year later, because each later slice was judged "good enough" without it.
- Foundation deferred past the point of pain: by slice four, three slices have each built their own half-model of a return, and consolidating them costs more than building it at slice two would have (Tech Debt Is a Product Decision).
- Sequencing by stakeholder volume rather than value — the loudest team's slice goes first, and the one that answers the biggest unknown goes last.
- "Slices mean no architecture." They mean architecture arrives when there is evidence for its shape. The design thinking still happens early; the building waits for the second use.
- "The first slice should be the hardest part, to de-risk it." De-risk the biggest unknown, which is often "will anyone use it", not the hardest code.
- "Letting the second slice justify the foundation means never building foundation." It means building it at slice two, deliberately. Waiting until slice five is a different failure.
Knowing whether it worked
- Support's time on returns drops in the first weeks of the project, not only at the end of it (The Support Loop).
- The foundation, when it arrives, is smaller than the original design because the first slice ruled things out.
- A mid-project reprioritisation leaves something in production that the team is glad exists.
- Each slice's demo is a real customer path, not a diagram or a list of endpoints (Running a Demo That Ends With a Decision).
- At 10x team size, slices are how several engineers work on one project without blocking each other; layer-first work queues everyone behind whoever owns the bottom layer.
- At 10x customers, a slice that leans on a manual step may flood it. The first slice for a large store might route only one category or one country to self-service, to stay within what support can absorb.
- At platform scale, where other teams build on the returns model, foundation-first earns more of its keep: other people's code is the second slice, and it arrives whether the model is ready or not.
- Some rework is guaranteed. The first slice's shortcut is replaced and the code around it changes. You trade a known small rework for an unknown large one.
- The architecture looks messier mid-project. Engineers who value a clean model up front will find the intermediate states uncomfortable, and they are right that it costs something.
- It needs more coordination with support and the PM, because every slice is a small launch with its own communication (Writing for Stakeholders).
Where this applies
Product advice is context-sensitive. These labels say what each claim is specific to, and where a different stage, team or product would differ.
- GENERALLanding value in slices applies to any feature with several user-visible outcomes. It applies less to a single indivisible change, such as a database version upgrade, where the only slice is the whole thing.
- PRODUCT-SPECIFICFor features used only inside your own product, slice-first is cheap. For a public API or a data model partners integrate against, the foundation is the product and the order flips — design it first, because the second slice is someone else's code.
- STAGE-SPECIFICPre-product-market-fit, a first slice leaning on a manual step is normal and may last months. In a scaled store the manual step has a volume ceiling, so the first slice has to be scoped to stay under it.
Where the depth lives
This domain teaches the product-side judgement and hands the mechanism off.