Phase 1: Frame

What: Write the Spec: a complete functional description of the feature from the business and user perspective, with a bet and a testable hypothesis.

Thinking mode: Product thinking. Understanding what matters to customers and the business. On a team, anyone with customer insight can lead this; PMs often do, but engineers and designers who talk to users bring equally valuable perspective. Solo builders: this is you asking "what do I actually need to learn?" before opening your editor.

Inputs: Customer signals, business priorities, open questions, previous learnings.

Output: The Spec. A single document that contains:

• Bet: What are we committing to this loop and why?
• Hypothesis: The testable claim inside the bet. What do we expect to observe if the bet pays off?
• User stories: What does the user need and why?
• User journey: How does the user move through the feature?
• Business rules: What constraints govern behavior?
• Visual and interaction notes: How should it look and feel?
• Edge cases and error states: What can go wrong?
• Success criteria: What evidence would prove or disprove the hypothesis?
• Success metrics: What numbers would we track?

The Spec describes the feature completely from a user and business perspective, without prescribing technical implementation. It is the single source of truth that Slice consumes to design the exposure plan and Build consumes to construct the feature. The goal is clarity about our beliefs and blind spots, not comprehensiveness and a false sense of confidence.

How big should a Spec be?

A Spec can cover one feature or several connected features, as long as they share the same hypothesis. The test: if you can split the Spec in two and each part can be tested with its own hypothesis, they are two loops. If splitting it makes one part meaningless without the other, it belongs in a single Spec.

A Spec that requires ten features to test a single hypothesis is probably hiding a hypothesis that is too broad. If you can't state precisely what you'd observe if the bet pays off, the scope is likely too wide. Narrow the hypothesis and the Spec will shrink with it.

Bets, hypotheses, beliefs

LDD uses three words for three grain sizes of claim, and the difference matters.

• A bet is what you're putting effort on this loop. It carries commitment: time, attention, and opportunity cost. At the end of the loop you'll double down on it, pivot it, or abandon it.
• A hypothesis is the testable claim inside the bet. It states precisely what you expect to observe if the bet pays off, and what evidence would refute it.
• A belief is a smaller, per-exposure-level claim that Slice produces. Each exposure level validates one belief; together, they accumulate the evidence that resolves the bet's hypothesis.

You place one bet per loop. The bet contains one hypothesis. Slicing breaks that hypothesis into a sequence of beliefs tied to progressive exposure steps.

Good framing saves tokens

When agents do the building, framing isn't just an intellectual exercise. It has a direct economic cost. A vague bet produces vague specs, which produce agent drift: the agent builds something, you correct it, it rebuilds, you correct again. Each round costs tokens and time.

A well-framed bet with clear success criteria and good context means the agent understands what you want on the first pass. This is context engineering in practice: the quality of the frame determines the efficiency of the build. Cheap building doesn't mean free building.

When you arrive with a solution

Most people arrive at Frame with a feature idea, rather than a question. A solo builder wakes up convinced the app needs a dashboard. A PM brings "we need advanced filters" to the team. A stakeholder says "customers want an export to PDF."

None of them are wrong for having the idea. But each is operating from a hidden assumption: "I already know the problem, and I already know the right solution." That assumption is the real hypothesis, and it hasn't been tested yet.

When you arrive at Frame with a solution in mind, the first job is digging out the assumption underneath it, rather than framing the solution itself. Ask: what would have to be true for this feature to matter? The stakeholder who wants PDF export might be assuming customers need to share reports offline. The PM who wants filters might be assuming users can't find what they need. The solo builder who wants a dashboard might be assuming users need an overview before taking action.

A hypothesis is testable, a feature is not. Frame the hypothesis, not the feature. If the hypothesis holds, the feature might still be the right solution, or a better one might emerge. If it doesn't hold, you just saved yourself a build cycle.

The goal is making the implicit explicit, rather than slowing people down or dismissing their ideas. Most unvalidated decisions start here, as assumptions that never got surfaced rather than as deliberate bets.

Which bet to place first

LDD doesn't include a prioritization framework. Strategy, vision, and roadmap live above the loop, and they should inform what you test next. On a team with a product strategy, the loop serves the strategy, not the other way around.

But you still need to decide: of all the bets you could place, which one first?

When reality already chose for you

Sometimes the market makes the decision obvious. A prospect is waiting for something specific before they buy. A customer is churning because of a gap you haven't addressed. A pain point is blocking your own progress every day. In these cases, the bet is already in front of you. Don't overthink it. Frame it and start the loop.

When you have competing bets and no obvious urgency

Ask three questions:

• Cost of ignorance: Which unknown hurts most if you keep ignoring it? A team building on an unvalidated assumption for three months is accumulating risk. The bet that reduces the most risk wins.
• Speed to close: Which bet can you close in the shortest learning horizon? If two bets matter equally, pick the one you can learn from in hours rather than weeks. Faster loops compound faster.
• Decision value: Which answer would change what you do next? Some learnings are interesting but don't alter your path. Prioritize the bet whose answer actually shifts your next move.

These three lenses work for teams and solo builders alike. They work as a quick sense-check rather than a scoring model, to avoid the trap of running fast loops on the wrong questions.