Phase 1: Frame

What: Define a testable hypothesis and set its learning horizon.

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: A framed hypothesis (1–2 pages max):

• The question: What do we want to learn?
• Why it matters: How does this connect to customer value or risk reduction?
• The hypothesis: What do we think will happen?
• Success criteria: What evidence would prove or disprove this?
• Learning horizon: How long will it take to close this loop? Some learnings need hours, others days, others weeks. Be honest about the timescale before you start building.
• Context: Background that helps agents and humans understand intent.

The goal of this framing is clarity about our beliefs and blind spots, not comprehensiveness and a false sense of confidence.

Good framing saves tokens

When agents do the building, framing isn't just an intellectual exercise. It has a direct economic cost. A vague hypothesis 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 hypothesis 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.

Technical context belongs close to the code

Framing is a collaboration, not a solo activity. The person with customer insight frames the what and the why: what do we believe, why does it matter, what would prove us wrong. But the technical context, the codebase knowledge, architecture constraints, existing patterns, dependencies, belongs to whoever is closest to the code. That's usually an engineer, an agent with the right context window, or both.

On a team, this is where the PM-engineer collaboration is most valuable. The PM doesn't need to know the codebase to frame a good hypothesis. The engineer doesn't need to know the business strategy to provide the right technical context. Each brings what the other can't, and the result is a spec that's useful to both humans and agents.

Solo builders: you're doing both, but be deliberate about it. Frame the hypothesis first (product thinking), then layer in the technical context (engineering thinking). Don't let the codebase dictate the question you're asking.