पाठशाला Pathshala · उत्पाद Utpād, The product · Lesson 07 · Build
The roadmap as a set of bets, not a list of features
A list of features promises that every item will work. A set of bets names the metric each one should move, the time it is allowed and the evidence that will stop it.
Pathshala, The Founder Library · 11 October 2026 · 8 min read
A roadmap that lists twelve features for the quarter makes a promise nobody can keep: that each of them will be built on time and that each will do what it was meant to do. The first half is a scheduling problem. The second half is a forecasting error, and it is the one that sinks product teams.
This lesson replaces the list with a set of bets. It gives the evidence for why most ideas miss, the one-line form every bet should take, the way to group bets into themes a board and a team can both read, a worked quarterly roadmap for an Indian software company, and the review that turns the quarter into learning rather than a list of what slipped.
Why a list of features fails
The best evidence on how often product ideas work comes from companies that test every change. In a 2009 paper on online experimentation at Microsoft, Ronny Kohavi and his colleagues reported that only about one third of ideas improved the metrics they were designed to improve. These were ideas from experienced teams at one of the best-resourced software companies in the world, chosen because someone believed in them. There is no reason to think a seven-person team in Bengaluru picks better.
A feature list cannot hold that fact. It treats shipping as success, so a feature that ships and moves nothing is ticked off and forgotten, and the team learns nothing from the quarter except that it was busy. Marty Cagan’s argument against roadmaps makes the same point from the other end: a roadmap tells teams what to build without making clear the problem it is meant to solve. His suggestion is to hand each team a prioritised business objective and let it decide how to meet it, and he quotes General Patton’s rule, which sums up the whole lesson: do not tell people what to do; tell them what you need accomplished.
None of this means a startup should stop planning. Customers, investors and the team need to know where the product is going, and sometimes a date really is a date: a GST change with a statutory deadline, a contract that names a delivery. Those are commitments and belong on the page as such. Everything else is a bet and should be written as one.
What a bet looks like on paper
A bet fits in one sentence with five parts. The change: what will be built or altered. The user: who it is for, narrowly. The metric: the one number it should move, already measured. The size: from what to what, by when. The kill criterion: the reading at the halfway mark that would make you stop. Written out: we believe that letting clinic receptionists book a follow-up from the bill screen will raise the share of patients with a second appointment from 18 to 25 per cent within six weeks of release; if it has not reached 20 per cent by week three, we stop.
The sentence does three jobs a feature name cannot. It forces the team to check that the metric is measured today, which kills a surprising number of bets before they start. It makes the size explicit, so a bet promising a one-point move on a minor metric can be compared with one promising ten points on the [north star](/library/north-star-metric-and-its-input-tree). And it decides in advance what failure looks like, so nobody has to argue the result afterwards.
The fourth part of the discipline is the time budget. Basecamp’s Shape Up calls it appetite and builds the whole method around it: work runs in six-week cycles followed by two weeks of cool-down, a small betting table decides what runs in the next cycle, and a project that does not finish in its cycle gets no automatic extension. That last rule, which the book calls the circuit breaker, is what caps the cost of a bad bet. Basecamp prefers the word betting to planning because, in its words, it sets different expectations.
Themes, not features
Bets are too fine-grained to be the roadmap a customer or a board reads. Group them into themes: two to four problems the company has chosen to work on this quarter, each tied to one metric. A theme is written as a problem or an outcome, never as a solution: new clinics take too long to book their first appointment; small clinics leave in month four. The bets under it are the team’s current best guesses at moving it, and they are allowed to change.
For the time axis, drop dates beyond the current quarter. Janna Bastow of ProdPad describes sketching a three-column roadmap in 2012 that later became Now, Next and Later: commitment is firm for what is directly ahead and loose for what is further away. Her line on how it fits with goals is the one to keep: the roadmap shows the plan and the [OKRs](/library/okrs-for-team-of-ten) carry the commitment. In practice the Now column holds this quarter’s themes and bets in full, Next holds the themes you expect to pick up with no bets yet, and Later holds problems you know exist and have chosen not to solve.
A worked quarterly roadmap
A Pune company sells appointment and billing software to 400 dental clinics at ₹2,500 a month, about ₹1.2 crore of annual revenue. Its north star is clinics that book at least twenty appointments a week. The team is two engineers, a designer and a founder who does product. Last quarter’s roadmap was a list of nine features; seven shipped, and the north star did not move.
This quarter has three themes. Theme one, first value faster: the median new clinic takes eleven days to book its first appointment in the software; the metric is the share booking one within three days. Bets: import the existing patient list from a photo of the register; pre-load the clinic’s working hours from its Google Business listing. Theme two, the month-four leak: 6 per cent of clinics cancel in their fourth month. Bets: the follow-up booking from the bill screen described above; a weekly WhatsApp summary to the clinic owner of appointments and revenue. Theme three, a second line of revenue: paid reminder messages to patients. One bet: a painted-door upgrade button in the reminders screen to measure how many clinics click before anything is built.
Five bets, each with a six-week appetite, run in two cycles across the quarter with one engineer on each at a time and the designer across both. One commitment sits outside the bets: a change to the invoice format that a state regulation requires by a date, scheduled first and not counted as a bet. The board sees three themes, three metrics and a date for the commitment. The team sees five hypotheses and their kill criteria.
Run the figure at the defaults: five bets at one-in-three odds. The chance that every one pays is under half a per cent; the chance that at least one does is about 87 per cent; the expected number is between one and two. That is a good quarter, and a feature-list roadmap would report it as a failure because three items did not work. The other reading matters too. With a single bet the chance of a quarter that moves nothing is two in three. Spreading effort across several smaller bets is not indecision; it is how a team with ordinary odds makes a good quarter likely.
A feature list promises that everything will work. A set of bets promises only that you will find out what did, and do more of it.
Reading the results and killing bets
At week three of each cycle, read every bet against its kill criterion. Three outcomes are possible. The metric is moving at or above the predicted rate: keep going and consider doubling the time in the next cycle. It is moving but below the threshold: the bet failed its own test, so stop or reshape it into a new bet with a new prediction, never extend it quietly. It is not measurable yet because the feature has not reached users: that is a scheduling failure, and the fix is a smaller first release, not a later reading.
Write down the result of every bet, including the ones that died, in a single running document: the sentence, the reading, the decision. After two quarters this is the most valuable product document the company owns. It shows which kinds of change move which metrics for these customers, and it makes the next quarter’s odds better than a third.
Three habits ruin the method. Bets with no baseline: if the metric is not measured today, the first bet is instrumenting it. Themes written as solutions, which smuggle the feature list back in under a nicer heading. No kill criterion, which turns the halfway review into a debate between the person who built it and everyone else.
The quarterly and weekly ritual
In the last week of each quarter, spend half a day: read the bet log, choose two to four themes from the problems with the largest gap between where the metric is and where it must be, and write two or three bets under each in the five-part sentence. Check that every metric is already measured. Put any true commitments with dates in their own row. Publish the Now, Next and Later view to the team and the board on one page.
Every Monday, in the [weekly metrics review](/library/weekly-metrics-review-one-page-one-hour), read each live bet’s metric beside its prediction. At week three of each cycle, apply the kill criteria and record the decisions. At the end of each cycle, take a short cool-down to fix what broke and to shape the next bets. A team that does this for four quarters will have tested twenty ideas, kept the six or seven that worked and stopped the rest early, which is a better record than any feature list has ever produced.
The odds in the figure are a simplification: real bets are not independent and their chances differ. The method is Kohavi’s, Cagan’s, Basecamp’s and Bastow’s; the sources are below and the worked company is illustrative.
Sources
- Ron Kohavi et al., Online Experimentation at Microsoft, 2009 — Only about one third of ideas improve the metrics they were designed to improve (section 5).
- Marty Cagan, The Alternative to Roadmaps, SVPG
- Basecamp, Shape Up, chapter 8: The Betting Table
- Janna Bastow on inventing the Now-Next-Later roadmap, ProdPad blog, October 2022