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 Chunking Theory: A release sequencing method where every deployment groups exactly one new capability with two to four refinements to existing work, aimed at moving a single business metric. You don’t ship features — you ship results. Each chunk leaves the product more solid than it found it.
Why feature lists fail
A feature list has no theory of causation. It tells you what your team will build. It doesn’t tell you which number that work will move, when you’ll know if it moved, or whether the product underneath can hold the new weight.
Three failure modes follow directly.
You over-build before validation. When everything on the backlog feels equally worth doing, teams ship fifty things in a year and learn nothing until the very end — because they never drew a line between a specific feature and a specific outcome. The cash is low by the time you find out if anyone actually wanted it.
Refinement gets permanently deferred. On a feature backlog, new features always beat maintenance. New features feel like progress. Fixing the flow that’s losing users, cleaning up the surface that confuses support, shoring up the API that gets slow under load — that’s “cleanup,” it goes to the bottom, it moves further down every sprint. The product rots under the weight of everything you shipped without ever going back to fix. Users churn for reasons you never diagnose.
You lose signal. Each release is isolated. You ship a feature, you check some dashboards, you move on. Without a single target metric per release, you can’t tell which change moved which number. You’re flying without instruments, then making the next decision based on the same gut feeling that produced the backlog in the first place.
The mechanism, step by step
Chunking forces a specific structure onto every release. Here’s how I run it.
1. Name one number. Before touching the backlog, pick the one metric that matters most right now. Not three metrics — one. Retention, or conversion, or revenue. Pre-launch, it’s activation: getting someone to experience the core value the first time. Write it down. If you can’t name one number, that’s the problem you solve before writing a line of code.
2. Find the smallest sellable new capability. What’s the single new thing you could add this cycle that someone would pay for — or that materially changes the target number? Not the most interesting thing technically. Not the feature the founder is most excited about. The smallest thing that moves the needle. This becomes the new capability in the chunk.
3. Bundle the refinements. Pick two to four improvements to what already exists. These aren’t features. They’re the work that makes the current product more solid: a fix to a flow that’s losing users, a performance improvement people will notice, a UI element that generates support tickets. Make them mandatory, not optional. They ship in the same release.
4. Ship the whole chunk together. Not the new capability first, refinements in the next sprint. Together. This is the only mechanism that makes refinement actually happen. If it’s optional, it won’t happen. If it has its own sprint, it’ll get reprioritized. It has to be part of the same commit.
5. Measure before you start the next chunk. After each chunk ships, check the target number. Did it move? By how much? That’s your signal. It shapes the next chunk — not the roadmap you wrote six weeks ago.
TitanFlow: from zero to App Store in 90 days
In September 2020, I co-founded TitanFlow — a real-time options flow platform for retail traders. The space was dominated by expensive, desktop-only tools built for professionals. During the retail trading boom, traders were making decisions on their phones, during market hours, from their phones. Nobody owned mobile options flow.
Fifty things the platform could do. Real-time feeds, push alerts, watchlists, dark pool data, trend detection, unusual activity flags, multi-asset coverage, social features, portfolio tracking. The question was which of those fifty to build first, and in what order.
Chunking gave a clear answer. First: find the smallest sellable core. One live feed of options flow that retail traders would actually pay for. Not customizable. Not pretty. Just the one feed that was valuable enough that someone would hand over a credit card. That was the MVP — the thing in your hand.
We seeded the beta through specific Discord servers and subreddits where active retail traders actually lived. One thousand signups by the next morning. That was signal. Not feature votes or survey responses — actual people committing their contact information for access to a specific thing.
After launch, we sequenced in chunks:
Chunk 1 → daily retention. New capability: saved watchlists — a reason to open the app every morning instead of just when something interesting happened. Refinements: faster feed refresh, cleaner data labels, fixed mobile layout issues. Target number: daily opens. Did it move? Yes. Users started coming back before market open.
Chunk 2 → engagement. New capability: push alerts when a specific signal fired. Refinements: tighter filters, longer history, better sweep/block classification labels. Target number: session frequency during market hours. The goal was getting traders to keep the app running in the background, not just check it occasionally.
Chunk 3 → revenue. New capability: dark pool data — the second data type that justified a higher paid tier. Refinements: smoother onboarding, cleaner billing flow, a proper upgrade path from free to Pro to Elite. Target number: paid conversion rate. If the upgrade was friction, the data didn’t matter.
First version on the App Store in under 90 days. Peak daily active users around 5,000. Zero paid acquisition — community was the channel. Acquired by a private trading firm in 2023, specifically for the visualization libraries and UI.
What we didn’t do is as important as what we did. We didn’t try to ship all fifty features in year one. We didn’t build the full platform in a vacuum and discover at the end whether anyone wanted it. We shipped the core, measured what happened, and let the numbers tell us what to add next. The foundation never rotted because every chunk forced improvement of what was already live.
The same principle in a different register: CardSell
CardSell was a gift-card exchange platform. When I came in, fraud was running at 30 to 40 percent of transactions. The obvious fix is to add a fraud detection layer — buy a model, build a review queue, add steps. That’s feature-first thinking applied to a trust problem.
The actual problem was the transaction flow itself. The wrong signals were being collected at the wrong moments. Friction landed on legitimate sellers rather than fraudsters. The fix wasn’t a new feature — it was restructuring what already existed so the offer pipeline became the control point: create offer, check quote, run fraud check, accept or reject, execute card sale, update payout state. Each step gated by the right signal at the right time.
That’s chunking applied to a product workflow rather than a feature backlog. You don’t add until the foundation is solid enough to hold it. You fix the mechanism, then build on top of it.
Fraud dropped to near zero. Transaction volume grew 4x.
The deeper lesson: “ship new features” and “fix what’s broken” are not competing priorities. Chunking makes them the same release.
How to apply it this week
Pick one project where the backlog feels longest and the direction feels haziest.
- Name one metric. Not “we want to grow.” Which number, specifically? Write it on a sticky note and put it somewhere visible.
- Find the smallest new thing that moves it. Strike everything from the backlog that doesn’t connect to that metric. What’s left is your candidate list. Pick the smallest.
- Find two existing things to fix. What’s already live that’s losing people? Where does support get the most questions? Pick two concrete improvements — not vague “polish,” specific things that are wrong right now.
- Ship them together. Set a date. Hold to it. The goal is a chunk out the door, not a perfect release.
- Measure for one week before planning the next chunk. Write down what the metric did. That number drives the next decision.
If you’re at the start of a build and need help naming the first metric and finding the sellable core, that’s exactly what the Sequencing Audit covers. We map the current product, name the number that matters most, and chunk the next 90 days into a sequence you can actually ship.
Related: The Wallet Test — the validation gate that runs before you write the first chunk. Distribution Before Development — how to prove you can reach buyers before the chunking starts.