Phase 2: Slice
Design the Exposure Plan - what to reveal, to whom, and in what sequence.
What: Design the Exposure Plan: what to reveal, to whom, and in what sequence. Each level tests a belief that contributes to the hypothesis.
Thinking mode: Design thinking meets product thinking. Figuring out the smallest thing you can expose that still answers the question, and to whom. This is where product perspective and engineering perspective are most powerful together. On a team, this is a conversation, not a handoff. Solo builders: what's the thinnest version you can put in front of real people to find out if you're right, and who should see it first?
Inputs: The Spec (from Frame): the complete functional description of the feature, with its bet and hypothesis.
Output: The Exposure Plan:
- Exposure levels: What sequence of reveal + reach will you use to validate the hypothesis?
- Belief per level: What specific claim does each level test, and how does it contribute to the hypothesis?
- Learning horizon per level: How long will each step take to produce clear signal?
- Acceptance criteria: What must be true at each level to advance to the next?
- Non-goals: What are you explicitly not exposing yet (even if it's already built)?
- Reveal controls: Feature flags, canary releases, role-based toggles, or other mechanisms that gate who sees what at each level.
Why slice what you expose, not what you build?
Building everything at once is fine. If an agent can build the whole feature in an afternoon, there's no reason to artificially constrain it. But building everything is not the same as exposing everything.
The bottleneck was always learning rather than building, and learning requires clear signal. When you release ten assumptions to users at once and something doesn't work, you can't tell which assumption was wrong. You've shipped a lot, and learned nothing.
Slicing in LDD is about controlling what you expose for validation, not necessarily what you build. Build big if the cost is low. But expose progressively, so you can read the signal clearly at each step.
Progressive exposure
Slicing has two dimensions that move together:
- What you reveal: how much functionality you make visible. A basic flow, a partial feature, the complete experience.
- Who sees it: how much reach you open up. Your team, a small group of real users, a broad rollout.
The output of slicing is a progressive exposure plan: a sequence of steps where each one advances in functionality, reach, or both. Each step has its own belief to validate and its own learning horizon.
This can be as lightweight as three lines in a note:
- Internal team, basic flow: does it work as expected? (hours)
- 20 real users, basic flow: do they use it? (days)
- Broad rollout, full feature: does it move the metric? (one to two weeks)
You don't need to plan every step upfront. Plan enough to know where you're starting and what the next step might look like. After each validation, you decide: advance in reach, advance in functionality, advance in both, adjust, or abandon. The plan adapts as you learn.
Build big, show little
Two forces push in the same direction here. Users can't absorb ten assumptions at once, so exposing everything collapses signal. Agents can't carry context between slices of a single feature without drift, so building a feature incrementally corrupts the feature itself. Both problems resolve the same way: build the whole feature in one coherent pass, then reveal it in controlled steps. The product still grows feature by feature; what doesn't get sliced is any single feature.
Feature flags, canary releases, progressive rollouts, role-based toggles: these are all reveal controls, mechanisms for controlling exposure rather than rationing code. The whole feature might exist behind a flag, but you only turn on one level of exposure for real users. You validate one belief. Then the next. Then the next.
And don't worry about "wasting" build effort. Building, rebuilding, and refactoring now takes minutes to a few hours, not days or weeks. If the validation tells you the whole thing was wrong, you throw it away and rebuild in a different direction. The code is cheap. The learning is what you keep.
For solo builders, even if you vibe-coded the whole thing in one session, you can still deploy it progressively and watch what happens at the first exposure level before opening the next. The loop requires you to learn small, rather than to build small.
The internal cycle
A progressive exposure plan runs within a single bet. The bet and its hypothesis stay the same across exposure levels; what changes at each step is the belief being validated and the strength of evidence you collect.
The execution of this plan happens in Validate, where each exposure level is revealed and tested with a micro-decision after each level: continue, adjust and retry, or cut to Decide. You only return to Build if validation surfaces something that needs real code changes, and you only return to Frame when the bet is closed or when the evidence changes the question itself.
One bet, one hypothesis, progressive exposure, growing confidence. That's the rhythm.
When the reveal doesn't fit the horizon
Frame and Slice are coupled, not strictly sequential. The horizon set in Frame constrains the reveal, but the reveal also stress-tests the horizon. If the exposure plan you actually need won't fit the time the bet was given, you have three honest moves, in this order of preference:
- Shrink the reveal. Fewer exposure levels, or collapse beliefs that don't independently change the bet. The sequence often has more steps than the bet actually needs.
- Narrow the bet. Test a smaller hypothesis that fits the time you have. A tighter bet is usually more learnable than a broad one.
- Revise the horizon. If the bet is genuinely worth more time, push the horizon out, but treat that as a deliberate return to Frame, not drift.
What you should not do is keep the original horizon and ship a reveal that can't gather the evidence. That produces ceremonial validation: the loop closes on schedule with data too thin to decide on.