<aside>

At a Glance | Shape the Work | Place Bets | Build and Ship | After Shipping

</aside>

<aside>

A repeatable system to ship meaningful work every cycle

Turn raw ideas into shipped product on a fixed schedule, with variable scope and full team ownership. Run cycles end to end without runaway bets or bloated backlogs.

What You'll Find Inside

Why execution breaks - the symptoms this fixes.
The three phases - Shape, Bet, and Build, plus how work flows between them.
The operating model - who owns each phase and the key question to answer.
Each phase in depth - shaping, betting, and building step by step.
Quick reference - every term in one place.

When to Use This

Work runs forever → cap the downside with fixed-time bets.
Backlogs pile up → replace grooming with a betting table.
Nobody owns outcomes → hand a whole bet to one small team.

Why Execution Breaks

Most teams share the same symptoms as they grow:

Work drags on with no end in sight
Product managers have no time to think strategically
Founders ask: "Why can't we ship like we used to?"
Backlogs grow into piles of guilt nobody will ever clear
Work gets chopped into tickets and nobody owns the outcome

The root cause is the operating model, so the fix is a better operating model. This playbook has three phases: Shape → Bet → Build.

Simple Execution Process

---
config:
  layout: elk
  elk:
    nodePlacementStrategy: NETWORK_SIMPLEX
---
flowchart LR
    A(["Raw idea"]) e1@==> B["Shape"]
    B e2@==> C["Bet"]
    subgraph Cycle["<b>The Cycle: 6-week build + Cool-down</b>"]
        direction LR
        C e3@==> D["Build"]
        D e4@==> E(["Ship"])
        E e5@==> F["Cool-down"]
    end
    F e6@==>|"next betting table"| C

    e1@{ animation: slow }
    e2@{ animation: slow }
    e3@{ animation: slow }
    e4@{ animation: slow }
    e5@{ animation: slow }
    e6@{ animation: slow }

    classDef idea fill:#F4F5F7,stroke:#091E42,stroke-width:2px,color:#091E42
    classDef shape fill:#FFF5E6,stroke:#D97706,stroke-width:2px,color:#78350F
    classDef bet fill:#EAE6FF,stroke:#403294,stroke-width:2px,color:#2A215E
    classDef build fill:#E1F0FF,stroke:#0052CC,stroke-width:2px,color:#003366
    classDef ship fill:#FFE1ED,stroke:#651F70,stroke-width:2px,color:#3D1244
    classDef cooldown fill:#E3FCEF,stroke:#006644,stroke-width:2px,color:#003D29

    class A idea
    class B shape
    class C bet
    class D build
    class E ship
    class F cooldown

</aside>

<aside>

The Operating Model at a Glance

Phase	Who	Output	Key question
Shape	Small senior group, working independently	A pitch: problem, appetite, rough solution, risks removed	Is this defined enough to bet on?
Bet	Stakeholders at a betting table	A cycle plan: which pitches get built, by whom	Is this the best use of the next cycle?
Build	Small integrated team (1 designer + 1-2 engineers)	Shipped work within the time box	Can we ship a version of this we're proud of, on time?

<aside>

The core principle: fixed time, variable scope. </aside>

How to Adopt This

Option	Best when	How
One six-week experiment	You can protect one team's time	Shape one pitch, guarantee zero interruptions, kick off the build, aim for one piece done early
Start with shaping	Someone else controls engineering time	Shape one well-bounded pitch and push it through the existing process. Let the results argue for more
Start with cycles	The team runs two-week sprints	Switch to six-week cycles first. Breathing room creates appetite for better shaping

<aside>

Fix shipping before fixing discovery. The best customer insight is worthless if you can't turn it into a shipped product.

</aside>

<aside>

Phase 1: Shape the Work

Shaping happens on a separate track from building. It makes an idea concrete enough for a team to execute, and rough enough to leave room for their judgement.

Step 1: Set boundaries

Set the appetite first. How much is this idea worth? A small batch (1-2 weeks) or a big batch (a full cycle)? If it's bigger than one cycle, narrow the problem until it fits.
Default response to any raw idea: "Interesting. Maybe some day." A soft no keeps options open. Important ideas always come back.
Narrow the problem. Ask "what's really going wrong?" instead of "what could we build?" Dig for the specific moment a workflow breaks down. A "we need a calendar" request often turns out to be "help me see free time slots."
Watch for grab-bags. "Redesign the Files section" and anything labelled "2.0" are grab-bags, and nobody knows what done looks like. Split them into specific, single-problem pitches.

Step 2: Rough out the elements

Work at the right level of abstraction. Wireframes are too concrete this early and box in the designer. Single-sentence ideas are too vague and leave the team guessing. Two tools hit the middle:

Breadboarding. Words and arrows only: places (screens), affordances (buttons, fields, copy), and connection lines. Play out the flow and let it surface the hard questions.
Fat marker sketches. When the idea is visual, sketch with strokes so thick that detail is impossible. This keeps you debating structure instead of styling.

Step 3: Find risks and rabbit holes

Well-shaped work has a thin-tailed risk profile: it might run a week over, and that's the worst case. One unexamined rabbit hole can eat a third of the budget. So slow down and stress-test:

Walk through the use case in slow motion. Where are the gaps?
Does this need technical work we've never done before?
Are we assuming a design solution exists that we haven't actually sketched?
Patch holes by dictating a simpler trade-off up front, declare tricky cases out of bounds, and cut nice-to-haves from the core.
Present the concept to a technical expert. Ask "is X possible in six weeks?" instead of "is X possible?" Everything is possible. Little is possible in six weeks.

Step 4: Write the pitch

Five ingredients, every time:

Ingredient	What it covers
Problem	The raw idea or a single specific story showing why the status quo fails
Appetite	The time budget, stated as a constraint on the solution
Solution	The core elements, drawn so people without context can see it
Rabbit holes	Tricky details called out and patched in advance
No-gos	What we are deliberately excluding to fit the appetite

A problem with no solution is unshaped work. A solution with no problem is a debate with no referee. Pitch both together.

</aside>

<aside>

Phase 2: Place Bets

Bets, and zero backlogs

Pitches go to a betting table held during cool-down, with decision-makers in the room and no approval step afterwards.
On the table: new pitches from the last cycle, plus anything someone deliberately revived and lobbied for. That's it. No backlog grooming, ever.
If a pitch loses, let it go. Anyone who cares can track it themselves and lobby again. Important ideas return on their own.

What a bet means

Bets have a payout. Something meaningful ships at the end of the cycle.
Bets are commitments. The team gets the full cycle, uninterrupted. Pulling someone away "for one day" kills momentum worth far more than a day.
Bets cap the downside. The most you can lose is one cycle.

The circuit breaker

Bets that don't ship within the cycle get no extension by default. This one policy:

Kills runaway bets before they eat the roadmap
Signals the shaping was flawed, so rethink the approach instead of funding the same hole twice
Motivates teams to make hard scope calls all cycle long

Cadence

Six-week cycles. Long enough to finish something meaningful, short enough that the deadline is felt from day one. Two-week sprints drown teams in planning overhead.
Two-week cool-down between cycles: fix bugs, explore ideas, hold the betting table.
Bet one cycle at a time. Even multi-cycle visions get funded six weeks at a time, with something working at each checkpoint.
Bugs compete like everything else. True crises get immediate attention. Everything else waits for cool-down, a pitch, or an annual bug smash. </aside>

<aside>

</aside>

<aside>

</aside>

<aside>

</aside>

<aside>

Playbooks

</aside>