Skip to main content
A bet is a hypothesis, a specific wager on how to address a need. It’s the most important level in the tree because it bridges strategy and delivery: it’s a strategic decision in the Planning Tree and a delivery commitment in the Delivery Map. In the API a bet is stored as type: "approach".

​
What makes a good bet?

A bet should stand on its own as something that could succeed or fail. If it only makes sense as part of delivering something else, it’s a job, not a bet. The test: “Is this a coherent bet you could pursue independently?” Good bets:
  • “Chunked upload with resume” (hypothesis: handle large files gracefully)
  • “Inline chat for AI drafting” (hypothesis: conversation is better than forms)
  • “Barcode scan with live lookup” (hypothesis: cameras are faster than typing)
Bad bets:
  • “Create database table”. That’s an implementation step (a job)
  • “LLM monitors brain” + “Notification UI” + “Encode heuristics” as three separate bets. These are pieces of one bet. Combine them into “Proactive coaching from canonical sources” with the pieces as jobs.

​
Key fields

​
Measure

Every bet should have a measure. How you’ll know it paid off.
  • “99.9% upload success rate for files up to 2GB”
  • “Users create 3+ nodes per session via chat”
  • “80% of new users complete the wizard”

​
Size

Relative weight of the bet, not a time estimate.

​
Lifecycle status

This is distinct from job completion. A bet with all MVP jobs done is still in validation. It’s live and being measured, and it moves to resolved only when the measure shows it paid off.

​
Bets have seasons, not lifespans

A bet might ship MVP jobs in one iteration, go quiet while other work progresses, then come back for polish based on feedback. In the Delivery Map, the bet only appears as a column when it has jobs in the selected iteration. No active jobs means no column, no noise. The anti-pattern is a bet that has jobs in every iteration continuously. That means it was scoped as an open-ended project rather than one testable hypothesis. Split it.

​
Common pitfalls

​
Infrastructure without a consumer

A bet that describes infrastructure (“generic API layer”, “flexible abstraction”) without a feature that uses it in the same iteration is premature. Design for growth, but build for now. The simplest version that unblocks real functionality is the right scope. The abstraction layer can wait until you have a second use case.