Bets

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.

​

One parent, and the other needs it serves

A bet sits under one need: the one it is scoped against, the one its Kano, size and measure describe. Some builds help more than that. An export layer might serve both “finance can get numbers without an engineer” and “account managers can hand a partner a report”. Don’t split it into two bets to give each need a child. That hides the shared work. Place it under the need it serves most directly and mark the others as also served (the serves field). The bet shows +1 needs on its card, and the other need shows +1 from elsewhere, so it doesn’t look neglected. If a bet ends up serving three or more other needs, look again. Either it’s infrastructure whose own need hasn’t been written yet, or those needs overlap and should merge. “Also serves” is not “depends on”. A dependency says one bet can’t start until another lands. Serving says one build helps several needs.

​

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.