A roadmap that lists features with dates is a promise built on guesses. The moment you learn something new, such as a customer insight, a technical surprise or a shift in the market, the promise breaks, and trust in the roadmap goes with it.

The fix is not to stop planning. It is to plan in a way that is honest about what you know, what you are still learning, and what you are trying to achieve.

1. Plan around outcomes, not outputs

An output is something you build, like "add templates". An outcome is a change in customer behaviour or business results, like "new users create their first project faster". Starting from outcomes keeps the team focused on the problem and leaves room to find the best solution.

A simple format for an outcome is:

We want [this type of user] to [do this], measured by [this metric].

For example: "We want new teams to invite a colleague in their first week, measured by the share of new accounts with two or more active users." Features then become options for reaching the outcome, not the plan itself.

2. Use Now / Next / Later

The Now / Next / Later format, popularised by Janna Bastow, replaces dates with horizons:

  • Now: work that is underway or about to start. It is well understood, and this is the only horizon where dates make sense.
  • Next: problems you plan to tackle soon. The solution is still being shaped.
  • Later: themes and opportunities you are watching. They are not commitments.

The further out an item is, the less detail it should have. That matches how much you really know.

3. Show confidence, not false precision

Not every item on a roadmap is equally certain. Mark each one as high, medium or low confidence, and note the evidence behind it, such as customer interviews, usage data or a prototype test. This helps stakeholders understand why something may move, and it keeps the team honest about assumptions.

4. Protect room for discovery and maintenance

If every hour is planned for new features, discovery work and technical upkeep get squeezed out, and the roadmap gets worse over time. Many teams reserve a share of capacity for these, often starting around one fifth, and adjust from there. Treat the number as a starting point and tune it to your product's age and risk.

5. Review on a regular rhythm

  • Every few weeks: review progress on Now, and adjust Next with what you learned.
  • Every quarter: revisit your outcomes and check whether they are still the right ones.
  • Always: keep a short decision log noting what changed, why, and who agreed. It saves long debates later.

A one-page roadmap template

For each item, capture:

  1. The outcome it supports and how you will measure it.
  2. The problem and who has it.
  3. The evidence you have so far, and your confidence level.
  4. An owner and the main risks or dependencies.
  5. The horizon (Now, Next or Later).

Common mistakes to avoid

  • Treating the roadmap as a sales promise. Share direction, and keep commitments separate.
  • Too many things in Now. If everything is in progress, nothing finishes.
  • No owner for each item. Unowned items drift.
  • Ignoring technical debt. It slows every future item, so it belongs on the roadmap.