Essay

The chunking theory

Most roadmaps are just a list of features in a spreadsheet, ranked by whoever argued loudest in the last planning meeting. That’s the problem. A feature list tells you what you’ll build. It doesn’t tell you what will actually change for the business, or for the product underneath it, once you’ve built it.

Chunking is the fix I use instead. Every release groups one new capability with two to four refinements to what already exists, and the whole group is aimed at a single number: retention, conversion, revenue, whatever matters most right now. If a piece of work doesn’t fit a result, it waits. It doesn’t matter how good the idea is in isolation.

The reason this works is that it forces two things to happen at once that usually get treated as competing priorities. New ground gets advanced, because there’s a new capability in every chunk. Old ground gets hardened, because the refinements are mandatory, not optional cleanup you’ll get to “later.” Later never comes. If refinement isn’t part of the chunk, it doesn’t happen, and the product rots under the weight of everything you shipped without ever going back to fix.

In practice: say you’re building a trading-signal app. Fifty things it could do. Build all fifty and you ship in a year having learned nothing until the very end. Chunking finds the smallest sellable core first — one live signal traders will actually pay for — then sequences everything after it in small groups, each one tied to a number. Add saved watchlists plus feed-speed fixes, and you’re chasing daily retention. Add push alerts plus better filters, and you’re chasing engagement. Add a second data type plus cleaner billing, and now you can charge more.

None of those releases is “just a feature.” Each one is a bet on a specific outcome, with the maintenance work baked in instead of deferred. That’s the whole theory: stop shipping features, start shipping chunks that move one number and leave the product a little more solid than they found it.