A Roadmap Item Is a Bet, Not a Promise

The bet is this. A roadmap slot further out than the next build cycle records four fields, and the date on the slot is the day someone reads those fields again. The fields are the problem, the evidence with the day it was observed, the appetite, and the kill test.

The non-goal is narrower than it sounds. This memo does not pick a scoring formula, and it does not clear the calendar of dates. A date a customer, a contract, or a regulator already holds is a promise. It belongs on a different list, staffed as an obligation, with no kill test based on the age of an interview.

How old is the evidence behind this slot?

Take a checkout team in October. The roadmap says the new card step ships this month. The line has been there since the planning meeting in February. Everyone in the room can say what the project is. Few of them can say, without opening a doc, when the reason was last checked.

The reason is a pile of observations, and each observation has its own birthday. Five customer interviews on 14 January, all of them stuck on the card step. A funnel cut on 2 March showing about a third of checkouts leaving at that step. A copy change on the same screen in July, shipped by another squad, which nobody folded back into the pitch. Support tickets from 28 September that mention a declined-card message, which is a different pain from the January interviews.

The October slot does not know any of that. It knows a name and a month. The name makes the pile feel like one object, "the card-step project," and the month makes the object feel due. Due is a property of the calendar. It is not a property of the evidence.

Watch the clock. The January interviews lose their force long before the playhead reaches October. The March funnel follows. The September tickets show up late, and they are about declined cards, not about the layout the January customers described. The slot at the bottom never fades. That is the failure. The plan kept a constant, and the world did not.

A team that starts the build in October because the roadmap says October is spending a quarter on a justification it has not re-read. Maybe the funnel recovered after the July copy change. Maybe it got worse. The slot cannot tell you. Someone has to look, and the date is the moment they look, or the moment they skip looking and call the skip a plan.

The slot and the evidence are different objects

A slot is a row. It has a label, an owner, and a date. Sometimes it has a status, which is usually a word like committed or planned, and that word is doing more work than the row deserves. Committed, on a roadmap, often means the room agreed to type the line. It rarely means anyone renewed the evidence.

Evidence is a set of observations. An interview is evidence. A funnel rate over a named window is evidence. A ticket count is evidence. A competitor's launch is evidence of a kind, weaker than a customer's words, and it ages even faster. Each of these has a source and a day. Strip the day off and the observation can no longer be checked. "Customers hate the card step" can be true in January and false in August, and the sentence does not change when the world does.

Teams collapse the two objects because the collapse is convenient in a meeting. One row fits on a slide. Four fields plus a date of observation do not. The slide wins, the row ships into the quarter, and from then on the conversation is about staffing the row. Staffing is a real problem. It is the second problem. The first problem is whether the row should still exist when the staffing conversation starts.

The cost of the collapse is quiet, which is why it lasts. Nobody files a bug called stale roadmap. The team builds a capable card step. The metrics move a little, or they do not. The retrospective talks about execution. Execution was fine. The input was a reason whose birthday nobody checked.

There is a second cost, paid by the next quarter. A slot that rolls forward teaches the room that dates are soft and names are permanent. People stop treating the date as a moment of decision. The name stays, the month shifts, and the interviews from January get treated as settled. An observation does not become settled by surviving on a slide.

Fix the time and let the scope move

An estimate asks how long the work will take. An appetite asks how much time the problem is worth. They feel similar in a planning doc because both come out as a number of weeks. They bind opposite ends of the work.

Ryan Singer's Set Boundaries, in the Shape Up book from Basecamp, names the second question appetite and treats it as a time budget. Basecamp sets that budget in two sizes. A small batch is what one designer and one or two programmers can finish in one or two weeks. A big batch is the same shape of team for six weeks. If the problem cannot fit a six-week appetite, they narrow the problem until it can, or they do not bet. The default reply to a new idea, before it has been shaped, is a soft no. Interesting, maybe some day. The idea does not earn a row just by being said out loud.

The cycle that holds those bets is six weeks of building, then two weeks of cool-down with nothing scheduled. Cool-down is when the betting table meets. Singer's chapter The Betting Table is explicit about why they say bet instead of plan. A bet has a payout, defined by the pitch, so the six weeks are supposed to finish something rather than fill a time box. A bet is a commitment of uninterrupted time. If you say six weeks, the team gets six weeks, and a request for "just one day" is a broken commitment because momentum does not survive the day out. A bet caps the downside. The most you can lose is the time you bet.

The cap is enforced by what they call a circuit breaker. If the team does not ship inside the appetite, the project does not get an extension by default. The time already spent is gone. More time requires a new pitch at the next betting table, because missing the cycle means the shaping was wrong, not that the team is owed another cycle. They also only bet one cycle ahead. Scraps of unfinished work do not cross the boundary under the old name. Bets, Not Backlogs drops the central list entirely. A pitch that is not chosen is let go. A problem that matters comes back as a fresh pitch when someone is willing to lobby for it again.

An estimate lets the date slip. An appetite keeps the time fixed and moves the scope.

I would take the appetite and the circuit breaker even if I kept a quarterly roadmap and never adopted the rest of Shape Up. The transferable piece is the direction of the constraint. Time is the input. Scope is what flexes. A roadmap of estimates runs the constraint backwards. The feature name is fixed, the date is a hope, and when the hope fails the same name occupies the next quarter at a larger size. That is how a six-week problem becomes a two-quarter program without anyone deciding the problem was worth two quarters.

Shape Up does not, by itself, tell you to re-read customer interviews on the morning you start. It mostly refuses to put the interviews on a list that sits for nine months. One cycle ahead is a structural answer to stale evidence. If your company publishes a quarter or a half anyway, you still need a rule for the rows that will sit. Appetite tells you what you are allowed to spend. It does not tell you whether the reason survived the wait. That is the next field.

Four fields make the bet checkable

A slot that might sit longer than a cycle has to carry enough to be rejected later by someone who was not in the original room. Four fields do that. A solution sketch can ride along. It is not one of the four, because a sketch does not tell you whether to start.

The problem is the pain, stated so a stranger can recognise it. "Card step loses checkouts" can be checked against a funnel. "Rebuild the card step" cannot. The second sentence is a solution that has already won. Write the pain.

The evidence is the observations, each with a source and the day it was observed. "Customers hate checkout" is not evidence in this sense. Five interviews on 14 January, and a funnel cut on 2 March, are evidence. The day is the field the rest of the system is built to notice. Lose the day and the kill rule has nothing to compare against.

The appetite is the time budget, written before the team invents extra scope to seem thorough. Six weeks, or two, or whatever this company can actually protect from interruption. An appetite of "Q4" does not name a number of weeks. It does not cap anything.

The kill test is the observation that means you do not start. The funnel recovered without a build. The interviews described a pain the September tickets do not match. The evidence is older than one cycle. A kill test you cannot observe is a slogan. "If it no longer feels right" is not a kill test. A rate, a ticket pattern, or an age is.

The problem, the dated evidence, the appetite, and the kill test.

A pitch written so a checker can read it looks like this. The checkout example is the one from the opening, frozen at the January and March observations, before anyone asks whether October should still honour them.

bet:
  problem: card step loses checkouts
  evidence:
    source: five interviews and the funnel
    observed: 2026-01-12
  appetite: 6w
  kill: funnel recovered, or evidence older than one cycle

The checker does not decide the kill test. A person does, because the kill test points at the world. The funnel recovered or it did not, and no function in the repo knows that unless you feed it a measurement on purpose. What the checker can refuse is a start with a missing field, or a start whose evidence is older than the age this team chose. Here the age is 90 days, because this team's published plan is a quarter. A team on six-week cycles would pass a shorter age. Ninety days is their encoding of the cycle. It is not a law of product work.

func (b Bet) Validate(today time.Time, maxAge time.Duration) error {
	switch {
	case b.Problem == "" || b.Appetite == "" || b.Kill == "":
		return errors.New("problem, appetite, and kill test are required")
	case b.Observed.IsZero():
		return errors.New("evidence needs the day it was observed")
	case today.Sub(b.Observed) > maxAge:
		return fmt.Errorf("evidence from %s is older than the cycle", b.Observed.Format("2006-01-02"))
	default:
		return nil
	}
}

Run that on 4 October with maxAge of 90 days and the YAML above. The evidence date is 12 January. The function returns the age error, and the slot does not start. That is the whole point of putting the day in the pitch. The October roadmap said start. The fields said the reason is from another season. The team can still revive the problem, with September's tickets as the new evidence, under a new pitch. They cannot pretend January is still October.

Two limits are worth stating so the function does not get asked to do a job it cannot see. It does not notice that the September tickets describe declined cards rather than the layout the interviews described. A person reading the source does. And it does not notice that a July copy change may have moved the funnel. If that change matters, it belongs in the kill test as something a person checks, or as a newer observed date once someone re-measures. The function's honesty is that it only knows the fields you stored.

Which path spends the quarter?

Both paths consume the same designers and the same quarter. They differ in what the date means, and in what happens when the work misses.

On the scheduled path, the date means the feature exists in production. January's interviews remain the justification because they are what the room remembers, and nobody is paid to reopen them. Scope grows when the build reveals edge cases, because the date is a promise and the promise is protected by adding time or people. If the date slips, the row moves to next quarter under the same name. The name accumulates attachments. Other teams plan around it. Sales mentions it. Killing it in week ten feels like breaking a commitment, because the roadmap taught everyone to treat the row as one.

On the re-check path, the date means a person opens the four fields. If the evidence is older than the cycle, or the kill test has already fired, the slot stops. Appetite stays at six weeks. Scope is what moves, including the option of shipping a narrower card step or shipping nothing. A miss does not roll forward. Someone who still believes the problem writes a new pitch, with a new observed date, and that pitch competes with whatever else showed up during the cycle. Attachment to the unfinished work is not evidence. It is attachment.

One path protects the date. The other reads the four fields and lets a miss die unless it is pitched again.

I would spend the quarter on the re-check path for anything that is not already a promise to someone outside the team. The cost is real, and it should be named rather than waved off. You will throw away shaping work. You will disappoint a stakeholder who heard the feature name in February and repeated it to a customer in June, even though nobody had authority to promise it. You will look unreliable to people who equate a roadmap with a contract. Those people are not wrong about the pain. They are wrong about which document created it. The roadmap created the expectation by listing a date next to a name and calling the pair a plan.

The scheduled path has a cost too, and it arrives later, which is why rooms prefer it. You will ship work the evidence no longer supports, because the date has no kill test. You will expand a six-week appetite into a two-quarter program without a decision that the problem is worth two quarters. You will fill the next roadmap with survivors, which are last quarter's misses under slightly new names. Survivors crowd out problems that showed up last month and still have fresh evidence. The queue sorts by age of the row, not by age of the reason.

A scoring formula does not rescue the scheduled path. Multiply reach, impact, confidence, and effort, and you get an ordering of ideas as they looked on the day someone typed the numbers. Confidence in that formula is a judgment the scorer writes down. It is not the day of an interview, and it does not expire when the interview does. Re-scoring every quarter helps only if someone goes back to the source. Most re-scoring meetings edit the number. They do not reopen the recording.

A dated promise earns its place

Some dates are the product. Missing them is the failure, separate from whether an interview still holds.

A migration window you already announced to customers is a promise. A filing date is a promise. A conference demo you sold tickets against is a promise. A contract that names a behaviour and a day is a promise. These do not belong in the bet list, because a circuit breaker would be a decision to break your word. They also do not belong as fake bets with a kill test you have no intention of honouring. Write them on a promise list. Staff them. Cut other scope to protect them. Say, in the same document, that the date is an obligation and that the evidence question is closed.

The failure mode is mixing the lists. A real obligation inherits a kill test and gets cancelled because the interviews are old, which is how you betray a customer in the name of discipline. Or a stale idea inherits the urgency of a contract, which is how January's card-step layout becomes unkillable once someone mentions it next to a renewal. Two lists, two rules. Bets die when the evidence dies or the appetite is spent. Promises die when the obligation is met or explicitly renegotiated with the person who was promised.

The checkout story in this piece is composite. The interviews, the funnel, the July copy change, and the September tickets are arranged to show the age problem. They are not a report of one company. The six-week cycle, the two-week cool-down, the appetite sizes, the uninterrupted time, and the circuit breaker are Basecamp's, from Shape Up, in the chapters linked above.

Write the kill test into the pitch

The re-check is a small ritual at the start of the slot, before anyone writes code. Read the problem out loud and ask whether a stranger would recognise the pain. Read the observed date and compare it with today. Read the kill test and ask whether it has already fired. Read the appetite and ask whether the room is about to approve a larger one without saying so. If the evidence is stale, stop. Revive the problem only with a new observation and a new date. If the kill test has fired, stop and do not sneak the work in as a "small" version under the old row.

The same ritual is the close of this memo. Four situations come up, and each one has a single action. The action is taken before kickoff, not in the retrospective after the build.

A reviewer who is told that some roadmap is "committed" can ask four questions. What is the problem, in the user's words? What was observed, and on what day? What appetite caps the downside? What observation would make you not start? A team with crisp answers has a bet. A team that points at the quarter and the feature name has a promise it never made on purpose, which is worse than a promise it would stand behind.