Incremental Development

For a long time the rule was simple: finish everything on the list, then ship. Building a document editor meant having editing, sharing, comments, search, and permissions all in place before anyone outside the team saw it. If the list took ten months, then for ten months nobody used the product and nothing came back to tell the team whether what they were building was right. Under waterfall, where each phase finishes before the next one starts, that silence was treated as normal.

The bill arrived in the final month. The team would launch and only then discover that nobody used comments, and that what people actually wanted was a way to group documents into folders. Three of those ten months turned out to be wasted, and the arithmetic showed up far too late to do anything about it.

Planning meetings stalled at the same point every time. Someone would ask whether the team could put out what they had, and the answer was always that it was only half done. The word "half" was the problem. Two finished features out of five and five features all stuck at the halfway mark are completely different situations, and both got the same name. In the first case there are two things you could ship today. In the second there is nothing.

Incremental development is the practice of deliberately producing the first situation. Slice the work, finish one slice all the way through, ship it, and attach the next slice on top. Progress stops being a percentage and becomes a count of things people are already using.

Cut the work along a task a user can complete from start to finish. This runs against the instinct to split by layer — one pass for the screens, one for the server, one for the database. Split by layer and nothing works until all three passes are done. Split by task and each slice drags a thin strip of screen, server, and storage along with it, so the very first slice actually runs.

There are four steps.

1. Break the work into things a user wants to accomplish. For search, that might be find by title, find by document text, and filter by author — three separate slices. A user story, which states a single requirement in one sentence from the user's point of view, is the usual format for writing those slices down.
2. Order the slices. The criterion is not size but how badly the slice is missed when it isn't there. On a team with three thousand documents, missing title search hurts every day, while filtering by author is a once-a-month inconvenience.
3. Finish exactly one slice, completely. Finished here means it satisfies the definition of done (DoD) — reviewed, tested, and live somewhere real users can reach it.
4. Ship it, watch what happens, and pick the next slice. Sometimes that means following the order you already set. Sometimes title search alone ends the support tickets and the remaining two slices quietly drop down the list.

Size each slice to fit inside one sprint. On a two-week cycle that means something you can ship in two weeks. Slices any larger leave the cycle ending with nothing to release, which removes the whole advantage. Slices much smaller flip the cost the other way, since the review and announcement overhead of shipping starts to exceed the cost of building.

The first place most people meet this is the minimum viable product (MVP) — the smallest version of a product that can test a hypothesis. Deciding what counts as that minimum is exactly the act of choosing a first slice. It's the reason the better MVPs make one thing genuinely work instead of sketching a thin imitation of the entire product.

It shapes release planning the same way. Shipping something every two weeks instead of once a year cuts the time it takes to find out you built the wrong thing from ten months to two weeks, and because less changes at once, tracing a problem back to its cause gets easier. When yesterday added one slice, there's one place to look.

Shipping that often needs support underneath it. A feature flag is a switch that turns a capability on and off while the code stays deployed, which lets a half-finished slice live in the codebase while staying hidden from users. Team structure matters too. Finishing a slice end to end requires product, design, and engineering in the same group, so without a cross-functional team the two-week promise falls apart before it starts.

"Let's ship title search this cycle and push the filters to the next one."

A proposal to finish one slice rather than get two features halfway there.

"Can we slice this vertically? Right now there's a screen but nothing behind it."

A request to re-cut the work into something a user can complete end to end.

"Let's see whether slice one is useful on its own before we decide to build slice two."

Whether the next piece gets built at all depends on the response to this one.

At Pagedeck this came up while the team was rebuilding document search. The original plan searched titles, body text, and file attachments at once, with filters for author and date range, and the estimate was seven weeks. Mia proposed cutting it into three slices and shipping title search first. Theo moved attachment search to the very end, since searching inside files meant reworking how documents were stored.

Two weeks after title search went out, more than half of all users had used it. The team built body-text search as planned, and attachment search, the third slice, drew so few requests that it never got built that year. Seven weeks of planned work finished in four — not because anyone worked faster, but because the team found out which slice it didn't need.

The most common mistake is hearing this as permission to ship unfinished work. The word "slice" sitting next to "ship only part of it" makes it sound like trading quality for speed. It's the opposite. Every slice that goes out satisfies the full definition of done; what shrinks is scope, not completeness. Teams that miss the distinction start attaching the name to features rushed out without tests, and a few weeks later they're spending every cycle repairing what they already shipped instead of adding anything new.

The second mistake is assuming design can wait. If pieces get attached one at a time, the reasoning goes, the overall shape can be worked out later. But the decisions about where future pieces will attach have to be made before the first slice is built. A team that knows attachment search is coming will store documents in a way that leaves room for it; a team that doesn't will rebuild the first slice from scratch to make the second one possible. Set the skeleton up front and add flesh one piece at a time — that's closer to how this actually works in practice.