Product Roadmaps Relaunched: How to Set Direction While Embracing Uncertainty

Why this book exists

For decades, software roadmaps were drawn as Gantt charts: features down the left axis, quarters across the top, blocks of color showing what would ship when. The format was inherited from physical product development and construction project management, where dependencies were stable and uncertainty was low. Software adopted the format reflexively, and for a long time it was the default in every PM tool, every executive deck, and every customer commitment.

The format was wrong, and everyone knew it but no one wanted to say so. Features promised in Q3 routinely slipped to Q4, then to next year, then disappeared. Features no one had committed to in any quarter suddenly appeared because a customer demanded them. The Gantt-chart roadmap became an artifact of fiction, updated quarterly to reflect what the team was actually doing and never matching what the team had previously promised.

C. Todd Lombardo and his co-authors had spent years consulting with product teams trying to fix this. They saw the same pattern repeatedly: teams promised what they could not deliver, executives demanded the promises anyway, and the resulting roadmap was a political artifact rather than a strategic one. The book is their attempt to provide an alternative format and to give PMs the vocabulary, templates, and political playbook needed to actually transition to it.

The book has been widely adopted. Most modern PM tools (Productboard, Aha, ProductPlan) ship with theme-based and Now/Next/Later templates inspired by the book. Most modern product organizations have moved away from Gantt-chart roadmaps in favor of one of the patterns the book describes. It is the definitive modern roadmap text.

The core argument: roadmaps are communication, not contracts

The book's central reframe is that a roadmap is a strategic communication tool, not a delivery contract. The roadmap exists to help different audiences — customers, sales, marketing, engineering, executives — understand the product's direction and the team's bets. It does not exist to promise that specific features will ship on specific dates.

The reason this matters is that any specific feature-date commitment more than 8-12 weeks out is more likely to be wrong than right. The team will learn new information from the market, from users, from competitors, from internal stakeholders. The right response to learning is to update the plan. But if the plan was published as a commitment, updating it damages trust — the team is breaking promises. If the plan was published as a communication of direction, updating it is just normal strategic adjustment.

The shift from contract to communication is more than semantic. It changes how the roadmap is constructed (themes over features), how it is presented (multiple audience-specific views over a single master document), how it is updated (continuously over quarterly), and how it is received by stakeholders (as direction over commitment).

Teams that successfully make the shift report dramatically less friction with executive stakeholders, dramatically more flexibility to respond to market learning, and dramatically less reputational damage from missed dates. Teams that try to make the shift without genuinely changing the underlying culture (treating it as a format change only) often regress to the feature-list pattern under stakeholder pressure.

The Now/Next/Later format

The simplest of the modern formats and the one the book most often recommends as a starting point. The roadmap is divided into three columns:

Now. What the team is currently working on. These are the items that are in active development this sprint or this month. The team has high confidence in them and they are tied to specific deliverables.

Next. What the team plans to work on after the Now items. These are committed in principle but not yet in active development. The team has medium confidence — the items will likely happen but the specifics may shift as the team learns more.

Later. What the team intends to work on after Next. These are directional — the team believes these are important but has not yet committed to specifics. The Later column represents the strategic horizon without false precision.

The Now/Next/Later format is powerful because it communicates direction without committing to dates beyond what the team can honestly commit to. The audience can see what is currently happening, what is coming up, and what the team is thinking about for the future. The format is honest in a way that Gantt charts are not, because it acknowledges the diminishing certainty as the time horizon extends.

The book includes templates for the Now/Next/Later format and dozens of real examples from companies that have adopted it. The format is now standard at companies as varied as Google, Spotify, and many enterprise SaaS firms.

The theme-based roadmap

A more sophisticated format that the book describes in detail. Instead of a roadmap composed of features, the roadmap is composed of themes — strategic outcomes the team is pursuing. Examples of themes: "improve activation for new users," "reduce time to value in onboarding," "expand into international markets," "build trust with enterprise buyers."

Each theme has supporting initiatives, which may be features but may also be other types of work (content, partnerships, infrastructure investment). Each theme has a target outcome (a metric to move, a quality to improve). The roadmap communicates which themes the team is pursuing this quarter, next quarter, and over the longer horizon.

The theme-based format is powerful because it forces the roadmap conversation to be about strategy rather than features. When executives ask "why is feature X on the roadmap," the answer is "because it supports theme Y, which is one of our three strategic priorities this year." When executives ask for feature Z to be added, the question is "which theme does it support, and is that theme one of our strategic priorities?" The conversation moves from individual feature negotiation to strategic prioritization, which is the right conversation to have.

The book includes worked examples of theme-based roadmaps from real teams, with discussion of how themes were chosen, how supporting initiatives were prioritized, and how the team communicated the format to stakeholders.

The GO product roadmap

A third format the book describes. The GO (Goal-Oriented) format organizes the roadmap around vision, goals, and metrics, with specific releases hanging off each goal.

The structure: at the top is the product vision (a multi-year aspiration). Under the vision are 3-5 strategic goals (annual outcomes). Under each goal are specific releases with target metrics. The reader can trace from individual release back through goal to vision, which makes the strategic logic explicit.

The GO format is more rigorous than Now/Next/Later but more committal than pure theme-based. It works well for teams with relatively stable strategic direction and clear metric targets.

Multiple audience-specific views

A key insight in the book is that different audiences need different roadmap views. The mistake teams make is producing a single master roadmap and showing it unchanged to every audience, which forces the team to compromise across audiences that genuinely need different information.

The audience-specific views the book recommends:

Customer-facing roadmap. Shows directional themes and high-level capabilities being invested in. Avoids specific feature names or dates that would create false expectations. May include opt-in waitlists for upcoming capabilities.

Sales-facing roadmap. Shows a deeper feature pipeline with rough timing, so sales can make informed conversations with prospects about what is coming. May include "in development," "planned," and "considering" tiers with explicit caveats about timing.

Engineering-facing roadmap. Shows technical work, dependencies, and sequencing detail that the team needs to plan sprints. Often closer to a backlog than a roadmap, with explicit sprint or release allocations.

Executive-facing roadmap. Shows strategic themes, metric targets, and key bets. Focuses on the why and the outcome rather than the what and the when. Often presented in a quarterly business review format with strategic context.

Each view is derived from the same underlying strategy and prioritization, but rendered differently for each audience. The roadmap PM maintains all views and keeps them consistent at the strategic level even though they differ at the detail level.

How to transition from Gantt-chart to modern roadmap

The book devotes significant pages to the political and organizational change required to make the transition. The transition is not just a format change; it is a renegotiation of expectations with stakeholders.

The recommended sequence:

1. Educate stakeholders on the why. Before changing the format, explain why feature-date commitments beyond a quarter are usually wrong, citing the team's own history of missed dates. Build agreement that the new format is more honest.
2. Pilot with one audience. Start by changing the customer-facing or sales-facing roadmap to a theme-based or Now/Next/Later format. Keep the internal executive roadmap unchanged initially. Measure reaction.
3. Expand the new format to additional audiences. As pilot audiences become comfortable, extend the new format. The executive-facing roadmap is usually the hardest transition and should come last.
4. Hold the line on commitments. As the new format takes effect, refuse to make feature-date commitments beyond a quarter out. Be polite but firm. Reference the format change explicitly.
5. Demonstrate value. Track how often the new format's flexibility allowed the team to adjust productively. Use those examples in stakeholder communication.

The transition typically takes 6-12 months and is rarely complete. Some stakeholders never fully accept the new format and continue to push for date commitments. The PM's job is to maintain the new format while accommodating reasonable requests for more specific information when warranted.

Common objections and how to handle them

"Sales needs feature dates to close deals." Partly true, but sales often closes deals more effectively when they can talk about strategic direction rather than specific feature dates. Feature-date promises are a frequent cause of post-sale customer dissatisfaction when dates slip. Theme-based commitments give sales material to discuss without creating slippage liabilities.

"Customers demand feature dates." Some do, but most customers are most concerned about whether the product will solve their problem, not whether feature X ships in Q3 vs Q4. Theme-based communication can convey commitment to solving the customer's problem without committing to specific feature mechanics.

"Executives want predictability." Executives want to know that the team has a coherent plan and is making progress. Theme-based roadmaps with explicit outcome metrics give them that. Feature-and-date roadmaps give them false predictability that erodes trust each time dates slip.

"Engineering needs commitments to plan capacity." Engineering needs commitments at the sprint and quarter level, where the team has high confidence. Beyond a quarter, engineering planning becomes increasingly speculative; the new format honestly reflects that.

"Marketing needs to plan launches." Marketing can plan launches for committed near-term work with high confidence. Beyond a quarter, marketing should plan more flexibly. Theme-based roadmaps with rough timing give marketing enough to plan campaigns around themes rather than specific features.

The book provides detailed scripts for each of these objections and discusses how to handle them in stakeholder conversations.

The role of metrics and outcomes

A theme-based roadmap is anchored in outcomes. Each theme has a target metric and a target value. "Improve activation" without a metric is too vague; "improve D7 retention from 35% to 45%" is testable. The metric anchors the theme and gives the team a way to measure progress.

Outcome anchoring also disciplines the prioritization conversation. When considering whether to add a new initiative to a theme, the team asks: how would this initiative move the theme's outcome metric? If the answer is "modestly," the initiative may not deserve inclusion. If the answer is "significantly," the initiative is a strong candidate.

The book is explicit that outcome metrics should be lagging where possible (actual business outcomes like retention, revenue, conversion) but can be supported by leading indicators that the team uses to track in-quarter progress. The full stack of metrics — leading and lagging, team-level and product-level — gives the team visibility into whether the strategy is working.

Worked examples from the book

The book includes case studies from companies that have adopted the modern roadmap format. A few highlights:

A B2B SaaS company's transition. The company had a long history of feature-date promises and missed dates that had damaged enterprise customer trust. The PM team transitioned to a theme-based roadmap over twelve months, starting with a customer-facing communication change and working up to executive presentations. Within eighteen months, customer NPS had improved and the team's ability to respond to market shifts had improved dramatically. The book describes the transition in detail, including the political setbacks and recoveries.

A consumer mobile app team's adoption of Now/Next/Later. The team had been struggling with constant pressure from executives for more specific feature commitments. The Now/Next/Later format gave the team a way to communicate honestly while preserving flexibility. The book describes the template the team used and the executive communication that accompanied each quarterly update.

A platform team's use of the GO format. A team building a developer platform needed to communicate to both internal developers (who needed specific capability commitments) and external partners (who needed strategic direction). The GO format with vision, goals, and releases provided the appropriate level of detail for each audience.

What the book does badly

The book has some limitations:

The templates can feel prescriptive. The book offers specific roadmap templates that work in specific contexts but may not fit every team's needs. Some teams over-apply the templates rather than adapting them.

The political playbook is U.S. corporate. The book assumes a relatively mature, relatively collaborative stakeholder environment. Teams operating in more hierarchical or more political environments may find the transition advice difficult to apply directly.

The treatment of AI/ML products is light. The book predates the explosion of AI products. AI roadmaps have additional complexities (model performance uncertainty, data dependencies, regulatory constraints) that the book does not address.

The book is heavy on description, light on critique. The authors present the modern roadmap format as clearly better than the Gantt-chart format, which is true in most cases but not universally. Teams in industries with stable long-term dependencies (regulated industries, hardware, infrastructure) may legitimately need more feature-date detail than the book suggests.

How to use the book in practice

The most effective adoption pattern:

1. Read the book once cover to cover. Understand the philosophy and the available formats.
2. Pick a single format to pilot. Now/Next/Later is the lowest-friction starting point for most teams. Theme-based is the better long-term destination for most teams.
3. Pilot with one audience. Customer-facing is often the safest pilot because customer expectations are most easily reset.
4. Build template and communication assets. Steal directly from the book's templates and adapt to the team's brand and style.
5. Maintain the pilot for a full quarter. Allow the new format to demonstrate value before deciding whether to expand.
6. Expand to additional audiences. Iterate quarterly until the new format is the default across all audiences.

Teams that follow this pattern usually complete the transition within twelve months. Teams that try to flip all audiences simultaneously usually face too much stakeholder resistance and revert.

The book's place in the modern PM canon

Product Roadmaps Relaunched is one of the most-recommended modern PM books, alongside Inspired, Continuous Discovery Habits, The Lean Startup, and Lean UX. Its specific niche is the roadmap artifact and the strategic communication that surrounds it. No other book covers the topic with the same depth and tactical rigor.

It pairs well with: Impact Mapping by Gojko Adzic for the strategic content of the roadmap, Empowered by Marty Cagan for the operating model that supports outcome-driven roadmaps, Continuous Discovery Habits by Teresa Torres for the discovery work that feeds the roadmap, and Outcomes Over Output by Joshua Seiden for the philosophy underlying outcome anchoring.

Together these books form a coherent modern PM curriculum for the roadmap and prioritization function.

How to introduce the format to skeptical executives

The most common point of resistance is the executive who wants feature-date predictability and views theme-based roadmaps as evasion. The book's recommended approach:

1. Acknowledge the executive's need for predictability. Do not dismiss it. Explain that the team shares the goal of predictability and is trying to deliver it more honestly.
2. Show the historical accuracy data. Pull the team's past three to four quarterly roadmaps and compare the original feature-date commitments to what actually shipped. The data usually shows that 30-50% of features slipped by at least a quarter. This is the empirical case for change.
3. Propose a hybrid for the transition. Commit to specific features and dates for the current quarter (where the team has high confidence). Use theme-based commitments for everything beyond the current quarter. This gives the executive predictability where it is actually achievable and honesty where it is not.
4. Track the outcome. Six months in, show the executive that the team has been able to respond more effectively to market shifts and that committed quarterly work has shipped more reliably.

This pattern has converted many initially skeptical executives. The key is the empirical case for change — the historical data on missed dates — not the theoretical argument for theme-based planning.

Closing thought

The Gantt-chart roadmap was a borrowed format that did not fit the work it was applied to. Software does not have stable long-term dependencies the way physical product development does, and software teams learn from market response in ways that traditional project planning does not anticipate. The modern roadmap formats — Now/Next/Later, theme-based, GO — fit the work. They are more honest, more flexible, and more strategically useful.

The transition is hard because the Gantt-chart format is deeply embedded in stakeholder expectations and tool defaults. But teams that make the transition consistently report better outcomes: less wasted work, more responsive strategy, better stakeholder trust, and clearer strategic communication.

Product Roadmaps Relaunched is the manual for making the transition. Read it once for the philosophy, reference it repeatedly during the transition, and pair it with the other modern PM texts. The roadmap function is one of the most visible PM artifacts; getting it right pays dividends in every direction.

A worked walkthrough: converting a feature list to themes

Consider a SaaS team whose current roadmap is a list of 22 features across four quarters. The team is converting to a theme-based format. The first step is to group the features by the strategic outcome they support.

After analysis the team identifies four themes: improve activation (currently the team's weakest funnel stage), reduce churn in months 4-6 (where the team sees a churn cliff), expand to enterprise customers (a strategic growth bet), and improve platform reliability (a foundational investment). Each feature is mapped to one of the four themes. Two features do not fit any theme and are flagged for cutting; the team confirms in conversation that those features were on the roadmap because of legacy commitments rather than current strategy and removes them.

The team writes each theme as an outcome statement with a target metric. Improve activation: lift D7 retention from 35% to 45%. Reduce churn cliff: reduce month 4-6 churn from 12% to 7%. Expand to enterprise: ship three named features required by enterprise sales (the team allows feature-level specificity here because enterprise sales contracts depend on specific capabilities). Improve platform reliability: reduce P1 incidents from 8/quarter to 2/quarter.

The new roadmap then displays the four themes as the primary structure, with the features as supporting initiatives under each theme. The team produces three audience views: customer-facing (themes only, no feature names except for major launches), sales-facing (themes plus feature names with rough timing), executive-facing (themes plus metric targets plus a quarterly progress view).

The team presents the new format to the executive team. The presentation acknowledges that the format change requires the executives to trust the team's prioritization more than they had to with the old feature-list format, and explains why the new format is more honest. The executive team agrees to pilot for a quarter.

At the end of the quarter, the team reports on theme-level progress. Activation lifted from 35% to 40% (partial progress against the 45% target). Churn cliff was unchanged (the team learned that the underlying cause was different from initial hypothesis). Enterprise expansion shipped two of three features. Platform reliability hit the target. The executive review focuses on the strategic explanations of theme progress rather than on individual feature dates, which everyone agrees is a more productive conversation.

The format takes hold. By the end of year, the roadmap is fully theme-based, the executive reviews are strategic rather than tactical, and the team's ability to respond to mid-quarter learning has improved noticeably.

A note on continuous discovery and theme refinement

Themes are not set in stone. As the team conducts discovery work (per Teresa Torres' framework), it learns new things about user opportunities that may suggest theme refinements. A theme of "improve activation" may sharpen into "improve activation for users who arrive via paid search" if discovery reveals that the activation problem is concentrated in that segment. A theme of "reduce churn cliff" may broaden into "improve overall retention" if discovery reveals that the cliff is symptomatic of a broader retention issue rather than a specific cohort problem.

The book recommends quarterly theme review as a discipline. Each quarter, the team reviews the active themes against the latest discovery findings and decides whether to keep, refine, retire, or add themes. This keeps the roadmap connected to current understanding rather than frozen in past assumptions.

How specific companies have applied it

Several mid-stage SaaS companies have publicly described their adoption of theme-based roadmaps. Intercom, Drift, Productboard, and Atlassian have all published articles on their roadmap practices, and all reference the patterns the book describes. Larger companies — Salesforce, HubSpot, Asana — have adopted variants of the theme-based format internally even when their external customer roadmaps maintain more traditional feature lists for sales reasons.

The pattern across these companies: the internal roadmap is theme-based and outcome-anchored; the external roadmap is whatever format best serves the customer audience, sometimes themes and sometimes feature commitments with explicit caveats. The dual-format pattern lets the team operate with the discipline of theme-based planning while accommodating customer expectations that have not yet evolved.

A final note on courage

Behind all the format and template advice is a simpler truth: the modern roadmap requires courage. The PM must be willing to refuse specific feature-date commitments under stakeholder pressure, must be willing to defend theme-based language against criticism, must be willing to update and even retire themes publicly when the data demands it. The format is a tool; the courage is what makes the tool work.

Teams that maintain the modern format over years build a reputation for strategic clarity and honest communication. Teams that fold under pressure and revert to feature-list roadmaps end up in the same trust-erosion cycle they were trying to escape. The book provides the playbook; the courage is the PM's contribution.

Annotated highlights worth marking

• The chapter on the Now/Next/Later format, including the template.
• The discussion of audience-specific views and why a single master roadmap fails.
• The case study on the B2B SaaS company's twelve-month transition.
• The chapter on handling executive objections to theme-based roadmaps.
• The discussion of outcome metrics as the anchor for each theme.

On stakeholder education as an ongoing job

The book is realistic that the transition from Gantt-chart to modern roadmap is not a one-time conversation. Stakeholders cycle in and out, new executives join, new sales hires arrive, and each new stakeholder brings expectations shaped by their previous companies' formats. The PM owning the roadmap is therefore continuously educating stakeholders about why the modern format exists and why it serves their interests.

The recommended posture is patient repetition. Each new stakeholder gets the same explanation: here is the format, here is why, here is what you can expect to see, here is how it serves your needs. Over time the explanation becomes part of onboarding, of sales training, of executive briefings. The format eventually becomes the company's default rather than the PM team's preference.

On tooling: software for modern roadmaps

The PM tooling landscape has matured significantly since the book was first published. Tools that natively support theme-based and Now/Next/Later roadmaps include Productboard, Aha, ProductPlan, Roadmunk, and Airfocus. Notion, Coda, Asana, and ClickUp can be configured to support the formats with custom views. Even Google Slides and PowerPoint can be used for static roadmap presentations, especially for the executive-facing view.

The choice of tool matters less than the discipline of maintenance. A team using a sophisticated PM tool but updating it once a year has a worse roadmap than a team using Google Slides but updating monthly with clear annotations. The tool is a substrate; the discipline is the content.

For teams choosing tools, the book recommends evaluating on: support for multiple audience views from a single source of truth, support for theme-and-initiative hierarchy, support for outcome metrics alongside themes, support for versioning and change history, and integration with the team's existing issue tracker (Jira, Linear) so that engineering work links back to roadmap themes.

On the customer-facing roadmap specifically

The customer-facing roadmap is the most carefully constructed of the audience views, because mistakes here have the highest cost. Customer commitments are quoted back in support tickets, social media posts, and procurement documents long after the team has moved on. The book recommends a defensive posture: communicate themes and directional language, avoid specific feature names that customers will treat as commitments, and explicitly label timing language as directional.

A common pattern: a "currently improving" section that lists themes the team is actively investing in this quarter; a "considering" section that lists themes the team is exploring for future investment without commitment; and a "recently shipped" section that celebrates completed work. Specific feature names appear only in the recently shipped section, where they are factual rather than predictive.

The discipline of avoiding specific feature names is hard. Marketing wants to publicize specific features. Sales wants specific names to discuss with prospects. Customers ask for specific names so they can plan around them. The PM's job is to redirect each of these requests to the directional language and explain why specificity at distance is harmful.

On versioning and update cadence

A modern roadmap is a living document. The book recommends an explicit update cadence — at least quarterly for the executive-facing view, monthly or sprint-aligned for the engineering-facing view, and as-needed (with quarterly minimum) for the customer-facing and sales-facing views. Each update should be versioned and dated; stakeholders should be able to see what changed from one version to the next.

The transparency of versioning matters because it normalizes the fact that roadmaps change. When stakeholders see that the team updates the roadmap regularly, with clear annotations about what was added, removed, or shifted, the change feels like strategic responsiveness rather than broken promises. When stakeholders only see the latest version with no change log, every difference from prior expectations feels like a breach.

Some PM tools (Productboard, Aha) support roadmap versioning directly. For teams using simpler tools (Notion, Google Slides), the versioning discipline must be maintained manually — saving prior versions and annotating changes in release notes. Either approach is fine; the discipline is what matters.

On choosing the right horizon for each section

A subtle decision in roadmap design is the time horizon to give each section. Now is usually a month or a sprint; Next is usually a quarter or two; Later is usually beyond the next two quarters. But teams should tune these horizons to their own cadence and uncertainty profile.

Teams that operate in high-uncertainty environments (early-stage startups, fast-moving consumer apps, AI products) may have Now horizons of two weeks and Later horizons that begin at the next quarter. Teams in stable environments (enterprise SaaS, regulated industries) may have Now horizons of a quarter and Later horizons that begin at the next year. The right tuning is the one that matches the team's actual confidence at each horizon.

The book recommends explicit communication of the horizons. Roadmap headers should label what time period each column represents. Without explicit labels, stakeholders fill in their own expectations, often optimistically, which produces disappointment when the actual delivery is slower.

On retiring themes gracefully

Themes have lifecycles. A theme that was the team's strategic focus this year may be deprioritized next year as the team's strategy evolves. Retiring a theme cleanly is an underdiscussed roadmap skill.

The pattern: when a theme is being retired, communicate the retirement explicitly. Acknowledge what the theme accomplished, why it is being retired (objective reached, strategic pivot, sunset of supporting product area), and what is taking its place. Avoid the silent removal — having a theme simply disappear from the next roadmap without comment — which leaves stakeholders confused about what happened and damages trust in the roadmap's strategic clarity.

Graceful retirement also creates space for celebrating accomplishments. A theme of "improve activation" that achieved its target deserves explicit acknowledgment before being retired. Teams that celebrate the wins build cultures of strategic patience, where multi-quarter focus is recognized and rewarded.

A deeper look at the discovery-to-roadmap pipeline

A theme-based roadmap is only as good as the discovery work that feeds it. The themes should emerge from real understanding of user opportunities and business goals, not from internal speculation. Teams that adopt the modern roadmap format without also adopting modern discovery practice often produce themes that are well-formatted but poorly grounded.

The recommended pipeline: continuous discovery (per Teresa Torres' framework) surfaces user opportunities and validates which opportunities have business potential. Strategic prioritization (often via Impact Mapping or similar) groups opportunities into themes that connect to business goals. The theme-based roadmap then communicates the prioritized themes to stakeholders, with supporting initiatives that the team commits to in the current and next quarter.

The pipeline keeps the roadmap connected to user reality and to strategic intent. Without the discovery foundation, the themes become abstract aspirations. Without the strategic prioritization, the themes become a long list of equally-weighted directions. Both failures produce roadmaps that look good on the surface but do not drive disciplined execution.

On the role of the roadmap PM

Roadmap ownership is a specific PM skill that is sometimes treated as a junior responsibility but should not be. The PM who owns the roadmap is responsible for the strategic communication of the entire product organization to its stakeholders. The artifact is high-visibility and shapes how the team is perceived by executives, customers, sales, marketing, and engineering.

The skills required: strategic clarity (the ability to distill a complex set of priorities into a few themes), political dexterity (the ability to negotiate with stakeholders who want more specific commitments), communication craft (the ability to write roadmap descriptions that are clear and compelling), and discipline (the ability to enforce the format against pressure to add unjustified items).

Strong roadmap PMs are highly valued at mature product organizations. The role is sometimes split — a director-level PM owns the roadmap strategy and a more junior PM owns the artifact maintenance — but the strategic responsibility belongs at a senior level.

On the relationship between roadmap and OKRs

OKRs and roadmaps are complementary planning artifacts that sometimes get confused. OKRs articulate the objectives and the key result metrics the team is committing to. The roadmap articulates the work the team will pursue to achieve those metrics. The theme-based roadmap is the bridge: each theme corresponds to an objective, and each theme's supporting initiatives are the work expected to move the key result metrics.

The most common mistake teams make is to set OKRs and roadmap independently, producing inconsistency between what the team has committed to measuring and what the team is actually working on. The integrated approach the book recommends: set OKRs first, then derive the theme-based roadmap from the OKRs. Each theme should correspond to one or more OKR objectives. Each initiative under a theme should plausibly move the relevant key results.

The integrated approach also resolves the perennial tension between OKR ambition and roadmap reality. If the team is committed to a key result that the roadmap initiatives cannot plausibly achieve, either the OKR was too ambitious or the roadmap is missing critical work. The mismatch surfaces the problem and forces a renegotiation between team and leadership.

How AI-era PM teams are adopting modern roadmaps

For PM teams building AI products in 2025-2026, the modern roadmap formats are especially valuable. AI feature development has high inherent uncertainty — model performance, latency, cost-per-inference, evaluation criteria are all unknowable until significant investment. Feature-date commitments for AI features more than a quarter out are almost always wrong, often by more than is true for traditional features.

Theme-based and Now/Next/Later roadmaps accommodate this uncertainty gracefully. A theme of "embed AI-powered assistance in the core workflow" can hold whether the specific AI mechanic is a chatbot, an inline suggestion, or a background automation — the team can adjust the mechanic as they learn what works without breaking the strategic commitment. An AI-era PM trying to use Gantt-chart roadmaps will find themselves constantly revising commitments and damaging stakeholder trust; one using theme-based roadmaps will communicate honestly about both the direction and the uncertainty.

Closing reflection

Of the roadmap formats in active use, the theme-based and Now/Next/Later formats described in this book are the ones most aligned with how software product work actually unfolds. They are honest about uncertainty, flexible in response to learning, and strategic in their framing. The Gantt-chart format that they replace is a relic of a different industry's planning conventions; its persistence in software is a cultural artifact rather than a functional necessity.

For PMs and product leaders who own roadmaps, this book is essential reading. The transition it describes is one of the highest-leverage organizational changes a product team can make. The book provides the philosophy, the formats, the templates, and the political playbook for making that change successfully. Read it, adapt it, and ship a better roadmap.