A now, next, later roadmap sorts work into three broad time horizons: what the team is working on now, what comes next and what it plans to explore later. The authors of Product Roadmaps Relaunched recommend broad timeframes such as calendar quarters or now, next and later, because they give guidance while preserving flexibility. Exact dates far in the future tend to be read as promises, which is risky for work that is still uncertain. A quarterly layout works the same way when the later quarters are treated as later. Source: C. Todd Lombardo, Bruce McCarthy, Evan Ryan and Michael Connors, Product Roadmaps Relaunched (2017).

A roadmap explains which problems the team will solve and why they matter, while a release plan details how and when specific work will ship. Product Roadmaps Relaunched describes a good roadmap as a strategic communication tool, a statement of intent and direction, and notes that a release plan requires rigorous scope definition and engineering capacity planning. Keeping the two apart lets the roadmap stay steady while the release plan changes sprint by sprint. Link each roadmap item to its release plan or backlog so people can find the detail. Source: C. Todd Lombardo, Bruce McCarthy, Evan Ryan and Michael Connors, Product Roadmaps Relaunched (2017).

Lead with outcomes, meaning the problems you want to solve and the results you expect, and treat features as possible answers. Marty Cagan argues that at least half of product ideas will not work, and the ones that do usually take several iterations to deliver value. A list of features with dates commits the team to solutions before anyone knows whether they work. Naming the problem behind each item keeps the team free to change the solution. A stream can carry the outcome, with the items under it as the current best ideas. Source: Marty Cagan, Inspired, 2nd Edition (2017).

Review it on a steady rhythm, often monthly, and update it whenever you learn something that changes priorities. Roman Pichler suggests tying roadmap reviews to the team's cadence: with two-week sprints, hold a bigger review at the end of every second sprint, which works out to about once a month. Mature products in stable markets can be reviewed less often. Products still searching for their market need more frequent reviews. Date each version so readers know how current it is. Source: Roman Pichler, Strategize (2016).

Many teams share a version with customers, and it works best with a clear note that plans can change. Product Roadmaps Relaunched lists a disclaimer as a core part of a roadmap, a short statement that the content is subject to change, which protects both the company and the customer from accusations of broken promises. Share themes and near-term items with confidence and keep later items broad. Remove internal details such as revenue targets and unannounced partners before the roadmap leaves the company. Source: C. Todd Lombardo, Bruce McCarthy, Evan Ryan and Michael Connors, Product Roadmaps Relaunched (2017).