Essay / Product & Entrepreneurship
A Roadmap Is a Bet Portfolio, Not a Promise
A roadmap can explain strategic choices without pretending uncertainty has disappeared. Make bets, dependencies and review points explicit before promises.
A roadmap can look certain because the uncertainty has been removed from the slide. Features appear in neat columns. Dates align. Dependencies are implied by the order. The result is easy to present, but it may conceal the very decisions the team needs to discuss.
I find a roadmap more useful when it explains where the team is choosing to spend attention and why. Some choices are commitments. Others are investigations. Some depend on evidence that has not arrived yet. Showing those differences makes the plan more credible, even if the picture becomes less tidy.
Calling the work a portfolio of bets does not mean avoiding accountability. It means being precise about what is known, what is being risked, and when a decision will be revisited.
A roadmap should make uncertainty visible, not hide it behind dates.
Begin with an outcome that can be challenged
Imagine a product team considering three pieces of work: a faster onboarding flow, a new integration, and a reporting dashboard. A feature list makes them look like three comparable items. Their underlying reasons may be completely different.
The onboarding work might address an observed point where new users abandon setup. The integration might be required by one promising customer segment. The dashboard might be based mostly on internal intuition. Those differences matter when deciding what to do next.
For each item, describe the intended outcome and the evidence behind it. Faster setup is not an outcome by itself unless it helps users reach something useful. A new integration is not strategic merely because another product offers it. A report is not valuable simply because the data exists.
An outcome should be specific enough that later observations can challenge the reasoning. Otherwise every shipped feature can be described as progress, even when it does not change the situation that justified the work.
Separate commitments from options
A contractual delivery, a security correction, and an exploratory prototype do not belong under the same promise language. They have different obligations and different room for adjustment. A roadmap should make that distinction visible to its audience.
A commitment needs a scope, an owner, and an understanding of what happens if the date is at risk. An option needs a reason to remain under consideration and a condition that would make it worth pursuing. An investigation needs a question and a bounded way to obtain evidence.
Basecamp’s betting-table chapter describes choosing among shaped proposals for a coming cycle rather than automatically carrying every idea forward as a permanent backlog obligation. The useful idea here is deliberate commitment: potential work must earn a place in the next period of attention.
That principle can be adapted without adopting a whole planning method. A small team can simply label items clearly and review whether old possibilities still deserve space. An idea should not gain priority merely by surviving in a document for a long time.
Give each bet a bounded investment
A bet needs an appetite: how much time, complexity, or organizational attention is reasonable before the team learns more? This is different from estimating every task as though the complete solution were already known.
For the integration example, the first investment might be a limited compatibility investigation and a working path through one representative operation. That could reveal whether the destination API supports the necessary permissions and recovery behavior. It would be premature to promise a complete integration suite before answering those questions.
Boundaries also help prevent an exploratory item from becoming an indefinite project. Define what the investigation will produce: a tested constraint, a prototype, a decision record, or a recommendation to stop. The output should support a next decision rather than merely demonstrate that time was spent.
When the investment limit is reached, review the evidence. Continuing may be sensible, but it should be a new decision with an explicit reason. Quiet extensions make the original budget meaningless and hide the cost from other possible work.
Dependencies are more than arrows
A roadmap arrow can imply that completing one feature makes the next one straightforward. In practice, a dependency may be technical, organizational, or evidential. Each type needs a different response.
A technical dependency might require a stable data contract. An organizational dependency might require another team to approve access. An evidential dependency might mean that a dashboard should only be built if an earlier experiment shows that users need the underlying decision support.
Writing the dependency in words often exposes the difference. “Needs identity service” is less useful than “requires a supported way to grant and revoke access for external collaborators.” The latter describes a capability that can be evaluated and potentially delivered in several ways.
Track who owns resolving the dependency and what observation will show that it is satisfied. A date attached to an unresolved external assumption does not turn it into a plan. It turns it into a risk that should be visible while there is still room to respond.
Balance the kinds of uncertainty
A portfolio perspective helps compare work that serves different purposes. Some items protect current reliability. Others improve an established workflow. Others explore a new customer or use case. A team that only chooses one category may create a predictable imbalance.
There is no universal percentage that every team should assign to each category. The appropriate balance depends on the product’s condition, obligations, and strategy. A service with recurring failures may need a different allocation from a stable product testing a new market.
What matters is making the tradeoff discussable. If every available period is consumed by new features, when will operational debt be addressed? If every period is consumed by maintenance, what evidence is being gathered about future value? The roadmap should expose the choice rather than make it appear accidental.
Pricing and packaging decisions can belong in this conversation too. They may require product changes, customer research, and operating work. A roadmap limited to visible interface features leaves important strategic bets outside the planning system.
Choose review points before enthusiasm takes over
A good review point asks whether the original reasoning still holds. It should not be a ceremonial demonstration where the only acceptable outcome is approval to continue.
For onboarding, the review might compare whether representative users can complete the intended task and explain where they became confused. For the integration, it might assess the reliability of one complete operation and the cost of handling exceptions. For the dashboard, it might ask whether the information changes an actual decision.
Write those questions while the work is still a proposal. Once a team has invested heavily, it becomes easier to substitute evidence of effort for evidence of value. A predefined review question gives the discussion something firmer to return to.
Stopping or narrowing a bet should preserve what was learned. Record the constraint, the evidence, and any conditions under which revisiting the idea would make sense. Otherwise the same attractive proposal may return later with its previous failure modes forgotten.
A stopped bet can be a successful decision if it makes the next allocation of effort better.
Communicate certainty honestly
Different audiences need different detail, but they should not receive incompatible versions of the truth. Customers may need to know what is committed and when they will hear more. Engineers need the assumptions and dependencies. Leadership needs the relationship between investment and intended outcome.
The same underlying record can support those views. Use dates where a date represents a real commitment. Use review windows where the next meaningful event is a decision. Use clear language for options that remain uncommitted. Avoid a polished external roadmap that silently upgrades every possibility into a promise.
A roadmap is useful when it helps people choose and coordinate. Its quality is not measured by how little it changes. It is measured by whether changes follow understandable evidence and whether commitments remain visible. That makes the document a tool for strategy rather than a calendar that accumulates disappointment.