We stay close to our customers/users and bet on opportunities for improvement, not solutions. Building is fast and cheap now; the rabbit holes and the cost of maintaining what we build are as expensive as they’ve ever been. So we slow down on purpose in one place: before the build.

When someone spots a problem, they write one page: what is going wrong, for whom, and how much time it is worth spending to fix (/craft-a-bet). We call that page a bet. On Tuesdays we read the new bets together, and each gets a yes, a not yet, or a no. A taken bet gets shaped: the solution is sketched and pressure-tested with the right people before anyone builds. Some bets need a whiteboard brainstorm for that; others arrive with a solution in mind and need it pushed on. The write-up from shaping is our PRD, everyone can comment on it, the build runs, it ships, and after a set time to learn we say plainly whether it helped.

Find where you are:

You noticed a problem. Ask what happens if it waits.

1. It can't wait. Fix it now. On call and the usual urgency criteria, unchanged. No bet, no documentation, before or after.
2. It can wait and it's small or continuous. Make it a Linear ticket with the Upkeep label. See Reserve Capacity.
3. It's already sold, with a date attached. Make it a Linear ticket with the Promise label, an owner, and a due date (think commitment to Super RCM project workflows).
4. It's big, or it changes how something works. Write a bet, with a teammate or with /craft-a-bet. Rewrites, migrations, and overhauls are never exempt.
5. Can't tell? Write the bet anyway. Fifteen minutes, it's a good check that we agree on the opportunity, and folding is a win.

Every Monday, the whole mix gets declared. Twenty minutes at the Weekly Engineering Sync: one row per person, one column per project, every cell a percent and the work — 80% Analysis Pages (Bet). Bets, Promises, and Upkeep land in the same grid, so nobody has to guess whether a bet is actually getting the week it was wagered. We aim for 90% and leave the last 10% for bugs and surprises. This is the declaration; nobody audits your days.

You wrote a bet. It becomes a row in the Book, where anyone can see every bet and where it stands. Bring it to Office Hours, where we push on it together. A bet that needs more information first goes exploring: one owner, the questions to answer, and a date it comes back. Bets are taken at Product Weekly.

A bet was taken. Now comes shaping, the solutioning step: the bet page holds the problem, shaping holds the solution. Not always the bet writer's job: whoever carries it runs one live session, working from the bet page, with the right people in the room, usually a senior engineer and the person closest to the customer pain. Walking in with solutions already in mind is welcome. The session is as long as it needs: a whiteboard brainstorm when the problem is open, a short pressure-test when the solution is in hand. /shape-a-bet preps the session and turns it into the write-up (Shaping Template): this is the PRD building process. The wager is calendar time for the people on it at normal focus: two weeks means two real weeks. Taken Tuesday means building by next Monday.

✅ Build Ready. The write-up is our PRD, and this is its review: rabbit holes addressed, fish to fry later named, page circulated for comments. This is where Warren signs off. The build clock starts here, not at the yes. If no solution fits the time we bet, the bet comes back to Product Weekly instead of quietly growing.