Revolutionizing Product Direction: A Deep Dive into Product Roadmaps Relaunched

In today’s volatile business landscape, where uncertainty reigns supreme and change is the only constant, the traditional product roadmap has often become a relic of a bygone era. C. Todd Lombardo, Bruce McCarthy, Evan Ryan, and Michael Connors’ Product Roadmaps Relaunched: How to Set Direction While Embracing Uncertainty boldly declares that the old ways are dead and introduces a revitalized approach to product roadmapping. This book serves as an indispensable guide for product professionals, challenging them to move beyond static, feature-laden plans and embrace a dynamic, strategic communication tool. It asserts that a truly effective roadmap isn’t just a document; it’s a leadership tool that aligns entire organizations, inspires teams, and excites customers by focusing on value delivery and problem-solving rather than just outputs and deadlines. Through comprehensive coverage of core concepts, practical frameworks, and real-world examples, this summary will break down every important idea, example, and insight, ensuring you grasp the full power of this relaunched paradigm.

Relaunching Roadmaps

This foundational chapter immediately confronts the outdated perceptions of product roadmaps, arguing for a radical transformation. It establishes that a modern roadmap is not a rigid project plan but a strategic communication tool that guides an entire organization towards its strategic goals by articulating a product vision and the value to be delivered. The authors emphasize that simplicity is critical for success, but simplicity doesn’t mean easy.

What is a Product Roadmap?

A product roadmap, in the authors’ view, is a clear articulation of how you intend to achieve your product vision. Its core purpose is to focus on the value you aim to deliver to both your customers and your organization, thereby garnering support and coordinating effort among all stakeholders. This simple definition is crucial, as it steers away from the common pitfall of roadmaps becoming mere feature lists.

Key Terms Defined for Clarity

To ensure a shared understanding, the chapter defines fundamental terms that will be used throughout the book:

• Product: Broadly, this refers to anything you deliver that provides value to your organization’s customers, encompassing artifacts like smartphones, services like pizza delivery, or even experiences.
• Stakeholder: This term includes all internal and external colleagues and partners involved in the product’s development, marketing, sales, and service, such as sales, marketing, engineering, finance, suppliers, and resellers.
• Customer: This refers to the recipient of the value your product provides, encompassing both the buyer and the user. The book notes that while often the same, these roles can be distinct, especially in B2B contexts.

The Evolution and Missteps of Traditional Roadmaps

The concept of a “roadmap” dates back to the 1890s with bicycles, evolving to include automobile travel and later technology development in the 1980s (e.g., Motorola, Intel). These early technology roadmaps, prevalent in the semiconductor industry, focused on specific deliverables and deadlines to inform purchasing and planning. However, the accelerating pace of technological change and the adoption of lean and agile practices have rendered this traditional, fixed approach problematic.

The core issue is that traditional roadmaps try to predict an unpredictable future, leading to:

• Missed dates and broken promises.
• Outdated features by the time they’re shipped.
• A lack of strategic context, leaving teams focused on output without understanding the “why.”

This frustration has led many product teams to abandon roadmaps entirely, yet this leaves a critical “strategy gap” unaddressed.

Requirements for a Relaunched Roadmap

The authors identify key requirements for a modern, effective product roadmap that adapts to the lean and agile world:

• Strategic Context: It must explain the “why” behind the product, linking to the company’s overall vision and goals. This combats “shiny object syndrome” and ensures funding and support.
• Value Focus: It must center on the value delivered to customers and the organization, moving beyond just shipping features to achieving measurable business outcomes. This helps avoid “feature factory” syndrome.
• Embrace Learning: It should acknowledge uncertainty and commit to outcomes, not just outputs. This allows for adaptation and creative problem-solving, fostering trust with stakeholders.
• Rally Organization Around Priorities: It must align diverse departments like marketing, sales, and engineering around a shared product plan. This prevents disjointed efforts and missed market opportunities.
• Excite Customers: It should be a tool to engage customers, solicit feedback, and validate direction, transforming promises into shared intent. This fosters trust and ensures relevance.

Equally important are what a relaunched roadmap should not be:

• Not a Promise: It shouldn’t make commitments that product teams cannot confidently deliver.
• Not Wasteful Planning: It shouldn’t require excessive upfront design and estimation.
• Not a Project/Release Plan: This is crucial. A roadmap is a strategic document; project and release plans are tactical.

The chapter concludes by asserting that this heroic feat is indeed possible, having been observed in dozens of organizations globally. By focusing on guiding principles, outcomes over features, ROI-based prioritization, stakeholder alignment, and continuous communication, roadmaps can effectively set direction while embracing uncertainty.

Components of a Roadmap

This chapter delves into the anatomy of a powerful product roadmap, illustrating how various elements combine to tell a compelling story of value and direction. It emphasizes that while every roadmap is unique, certain primary components are essential, while secondary components can enhance clarity, and complementary information provides crucial context without formally being part of the roadmap itself. The illustrative example of the Wombat Garden Hose Co. helps bring these concepts to life.

Primary Components: The Essentials

These are the non-negotiable elements for any effective product roadmap:

• Product Vision: This is the guiding principle, articulating how a specific type of customer will benefit from the product when it is fully realized and widely adopted. It’s the proverbial “North Star.”
• Business Objectives: These define the measurable goals the product aims to achieve for the organization. They explain the “why” in concrete terms, inspiring stakeholders and justifying resource allocation.
• Themes: These are high-level customer needs, problems, or jobs to be done. Focusing on themes shifts the roadmap’s emphasis from specific outputs (features) to desired outcomes (value), making the goal of development clear.
• Timeframes: Instead of precise dates, broad timeframes like “Now,” “Next,” and “Later,” or calendar quarters, are used. This provides guidance while preserving flexibility and communicating relative priority without overcommitment.
• Disclaimer: A crucial caveat that explicitly states everything on the roadmap is subject to change. This protects against accusations of broken promises and manages expectations, making it clear that the roadmap is a statement of intent, not a contract.

The Wombat Garden Hose Co. example illustrates how these primary components come together. Starting from a company vision (“making landscapes beautiful”) and market insights (insufficient irrigation), a product vision emerges (“perfecting water delivery”). This then leads to themes derived from customer problems (e.g., “indestructibility” due to kinks and leaks), organized into broad timeframes, all underpinned by a clear disclaimer.

Secondary Components: Adding Depth for Specific Stakeholders

These components are optional but can significantly enhance a roadmap’s utility by addressing specific stakeholder concerns without cluttering the core message.

• Features and Solutions: While themes focus on “what” needs to be solved, features are the specific deliverables proposed to solve those needs. They are included to show how you intend to deliver on themes, providing a more tangible sense of the planned work.
• Stage of Development: Labels like “discovery,” “design,” “prototyping,” or “pre-production” indicate the maturity of a theme or feature. This helps stakeholders understand the level of certainty and whether there’s still room for input. The Spotify example (think it, ship it, tweak it) is cited here.
• Confidence: An indication of your certainty in delivering a particular item or theme within a timeframe. This can be expressed as percentages (e.g., 75%) or visually (e.g., a decreasing gradient bar), further managing expectations and signaling the tentative nature of future plans.
• Target Customers: If the product serves diverse customer types, explicitly identifying which themes apply to which customer segments helps ensure balanced focus and guides stakeholder conversations.
• Product Areas: For large or complex products, annotating themes or features by specific product components or areas (e.g., “user interface,” “platform”) helps organize the roadmap and align internal development teams.

The Wombat roadmap is then revisited, showing how adding features and solutions (only for the “Indestructibility” theme, as it’s nearing shipment), stage of development, and new target markets (for future themes like “Infinite Extensibility”) enriches the narrative. The authors stress selectivity, as too much detail can obscure the main message.

Complementary Information: Essential Context, Not Formal Roadmap Elements

This category includes information that, while not formally part of the roadmap itself, is crucial for discussions with stakeholders and provides valuable context. These are often presented as separate slides or documents that accompany the roadmap.

• Project Information: Details like schedule, resources, status, dependencies, and risks are vital for development teams and executives, allowing them to plan execution.
• Platform Considerations: This includes scalability requirements, infrastructure needs, and technical platforms, essential for engineering teams to understand the underlying architecture required.
• Financial Information: Relevant for executives and investors, covering aspects like market opportunity and profit & loss (P&L), connecting product plans to business outcomes.
• External Drivers: Information on regulatory changes, competition, or key events (e.g., conferences) helps marketing, sales, and legal teams align their external strategies.

The chapter concludes by showing various real-world roadmap examples (Gov.uk, Chef Automate, GitHub, Bazel, Office 365) that demonstrate the flexible forms and content that successful roadmaps can take, reinforcing that there’s no single “template” but rather a collection of powerful components to be assembled thoughtfully. The key is always to convey what’s coming and why, aligning action with vision.

Gathering Inputs

Before embarking on the crucial task of roadmapping, it is imperative to gather and constantly refresh all relevant information and context. This chapter underscores that effective product decisions stem from a deep understanding of the product’s life cycle, the broader market, and the nuanced needs of both customers and internal stakeholders. Without this foundational work, roadmaps risk being built on assumptions and leading to costly mistakes.

Understanding Your Product’s Life Cycle

A product’s stage of life significantly influences its roadmap. The authors identify five primary phases:

• New: Often associated with startups, this phase focuses on outlining and driving the creation of the first version of a product. Roadmaps here address initial assumptions, rapid prototyping, and testing for validation.
• Growth: This phase centers on scaling an existing product to reach as many customers as possible. Roadmaps prioritize activities to address scale, improve user experience, and sometimes remove unnecessary features. Risk and uncertainty are lower as the customer base is known.
• Expansion: Here, the company seeks opportunities to extend the core product or line into new areas, introducing fresh functionality while remaining linked to the core. Kayak.com’s expansion from flights to hotels and cars is a prime example.
• Harvesting (Cash Cow): These products are maintained, with roadmaps focusing on continuous improvement based on customer feedback to keep the product useful and relevant. Google AdWords is cited as a cash cow.
• End-of-Life: This phase involves strategic planning to wind down and remove a product from the market, requiring careful communication and alignment across stakeholders.

Gathering Input from Your Market

A successful product requires a comprehensive understanding of its business ecosystem.

• Understand Your Ecosystem: Every team member should grasp the business landscape. Tools like Alex Osterwalder’s Business Model Canvas or Ash Maurya’s Lean Canvas are recommended for identifying core business pillars (e.g., problem/solution, value proposition, customer segments, revenue model). The authors suggest Lean Canvas for startups/new products and Business Model Canvas for existing/growing businesses.
• Define the Problem and Expected Outcome: A seasoned product professional focuses on problems and the desired outcomes of solving them. Steve Blank’s Customer Development Model emphasizes sequencing:
  • Customer Discovery: Understanding deep customer problems before thinking about solutions.
  • Customer Validation: Proving target audience willingness to pay for a solution.
  • Customer Creation: Demonstrating growing demand and a sustained sales pipeline.
  • Company Building: Establishing formal company structure as product and sales strengthen.

Gathering Input from Your Customers

Intimately knowing your customers is paramount for effective product development.

• Customer Roles: Focus on the jobs and functions a user performs (e.g., student, instructor for Lynda.com).
• User Types: Addresses how a user interacts with the product or their permissions (e.g., end user, general admin, manager).
• Users Versus Buyers: Differentiating between who uses the product and who pays for it is critical, especially in B2B contexts (e.g., VP of Sales buys Salesforce, sales reps use it daily).
• Roles Versus Personas: Personas are detailed representations embodying characteristics, feelings, and preferences of a user set, helping build empathy. While roles categorize customers, personas deepen the understanding of why they need what they need. The key is to get out of the building and interact directly with customers.

Gathering Input from Your Stakeholders

Internal collaboration is as crucial as external understanding.

• The Product Core: This small group (product manager, designers, engineers) is responsible for designing, building, shipping, and maintaining the product.
• Expanding Circles of Collaboration: Beyond the core, numerous other stakeholders contribute. The book provides a table detailing how various stakeholders (e.g., Sales, Marketing, Customer Support, Research, Finance) benefit from and contribute to the roadmap.
• Involving Stakeholders: Product teams should involve stakeholders at different points to ensure buy-in and greatly improve product quality. Jackie Bavaro (Asana) describes merging internal stakeholder lists to create an overall prioritized list reflecting the “Voice of the Customer,” which then informs broader themes for the roadmap.

The chapter concludes by stressing that these inputs are essential for informed decision-making. Neglecting this foundational work, whether through hubris or laziness, leads to designing for fictional scenarios and ultimately product failure. The product leader’s role is to synthesize these diverse inputs into the roadmapping process.

Establishing the Why with Product Vision and Strategy

This chapter highlights the profound importance of defining the “why” behind a product through a clear vision and a robust strategy. It asserts that roadmaps gain meaning and effectiveness when they are anchored by guiding principles that provide direction, articulate desired outcomes, and inspire the entire organization. Without this foundational “why,” roadmaps risk becoming aimless lists of tasks.

Guiding Principles: Mission, Vision, and Values

The chapter establishes common definitions for terms often conflated:

• Mission Defines Your Intent: A mission is the present purpose driving an organization to realize its vision. It includes four key elements: value (to the world), inspiration (for the team), plausibility (realistic and achievable), and specificity (relevant to the business). Examples like Coca-Cola and Starbucks missions are used to illustrate their aspirational, outward-facing nature.
• Vision Is the Outcome You Seek: A company vision describes a longer-term future reality or world, focusing on the benefits for the people served and the organization itself. It answers “who” (target customer) and “why” (benefits/needs addressed), and sometimes “how it’s different.” Airbnb’s “create a world where you can belong anywhere” is a prime example.
• Values Are Beliefs and Ideals: Values are the guiding beliefs that shape an organization’s culture and dictate how people behave. They act as a compass, determining what’s right or wrong for the business, informing how the vision and mission are pursued (e.g., InVision App’s “Question Assumptions. Think Deeply.”).

The core message is that roadmaps need to be embedded within these guiding principles. A roadmap is a strategic document that translates vision into action.

Product Vision: Why Your Product Exists

The product vision clarifies the fundamental reason a product is brought to market and what its success means. It’s the destination.

• Connecting to Organizational Vision: A product vision must support and derive from the broader corporate vision (e.g., Google Search’s vision supporting Google’s mission).
• Value Proposition Template: The chapter adapts Geoffrey Moore’s “Value Proposition Template” as a structured way to articulate a product vision:
  • For: [target customer]
  • Who: [target customer’s needs]
  • The: [product name]
  • Is a: [product category]
  • That: [product benefit/reason to buy]
  • Unlike: [competitors]
  • Our product: [differentiation]
  • Supports our: [objective(s)]
• Condensing to a Vision Statement: This information can then be compressed into a concise statement focusing on the “who,” “what problem it solves,” and “why” (benefit). Example for Wombat Garden Hose: “A world where American landscape enthusiasts can have a more predictable and automatic watering system that can perfect their lawns with an effective water delivery system.”
• Duality of Company and Customer Benefit: A product vision should acknowledge both the customer’s benefit (e.g., a better experience) and the company’s benefit (e.g., profit, market share). Marty Cagan emphasizes an inspiring product vision as a powerful recruiting and motivational tool.

Product Strategy: How You Achieve Your Vision

Product strategy acts as the bridge from vision to roadmap specifics, often being a main contributor to overall business strategy.

• Objectives and Key Results (OKRs): This framework, popularized by Andrew Grove (Intel) and widely used by companies like Google, is a powerful way to define product strategy:
  • Objectives: Specific, qualitative goals.
  • Key Results: Quantitative measures of progress towards objectives.
• Guidelines for OKRs in Roadmapping:
  • Every roadmap item must link to at least one objective.
  • Limit to a manageable number (fewer than five recommended).
  • Focus on outcomes, not output.
• The 10 Universal Business Objectives: The authors distill business objectives into a list of 10 universal categories that apply to almost any product, suggesting corresponding Wombat themes and key results:
  • Sustainable Value (e.g., Support core value, Create barriers to competition)
  • Growth (e.g., Grow market share, Develop new markets)
  • Profit (e.g., Support higher prices, Lower costs)
• Outcome Versus Output: This is a critical distinction. Output is the stuff you produce (e.g., features), while outcome is the difference your stuff makes (e.g., keeping a child safe). Roadmaps should focus on desired outcomes to avoid becoming a “feature factory” that ships without achieving meaningful results.
• Timing: The chapter strongly advocates for broad timeframes (Now, Next, Later) over specific dates on the roadmap. Precise dates are for release and project plans, not the strategic roadmap, as they invite missed expectations and hinder flexibility.

The chapter concludes by reaffirming that guiding principles (vision, strategy, goals) are essential ingredients for a compelling roadmap. Framing product timing and deliverables within these buckets helps establish, explain, and align the roadmap, ensuring efforts are directed towards measurable outcomes.

Uncovering Customer Needs Through Themes

This chapter asserts that identifying customer needs is the single most important aspect of the roadmapping process. It advocates for roadmaps to express these needs through themes and subthemes, moving beyond mere feature lists to truly solve customer problems. The chapter details various methods for uncovering these needs and ensuring they are rigorously vetted and tied back to strategic objectives.

Expressing Customer Needs

The core principle is that every item on the roadmap should address an actual customer need, problem, or job to be done. This focus is crucial for efficiency, avoiding irrelevant development, and delivering high value. The chapter reiterates the distinction between the product roadmap (high-level needs, “why”) and the release plan (detailed solutions, “how”).

Themes and Subthemes: The Core of Needs-Based Roadmapping

• Themes are high-level organizational constructs defining what’s important to your customers. They represent overarching customer needs or problems.
• Subthemes are more specific, granular needs that fall under a broader theme. A theme can group multiple subthemes.
  • Example: Theme: Address key usability issues; Subthemes: Pagination, Menu navigation, Save status.
  • Garden Hose Example: Theme: Indestructibility; Subthemes: No kinks, No leaks.
    The authors emphasize that themes represent gaps or pains in the customer’s experience, whether something missing (need) or something broken (problem).

Key advantages of organizing roadmaps by theme and subtheme:

• Helps the team say “no” to unnecessary solutions.
• Shifts focus from competitive catch-up to competitive advantage.
• Creates a better narrative for sales and marketing.
• Simplifies solution development.
• Provides development teams with more freedom and flexibility.
• Makes the roadmap easier to read and use due to fewer items.

Ways to Uncover Themes and Subthemes

• User Journeys and Experience Maps:
  • User Journey Maps help understand every step a user takes when solving a problem, from initial realization to resolution. They uncover snags and pain points, which form the basis for themes. James Kalbach’s Mapping Experiences is recommended.
  • Experience Maps go deeper, plotting user actions across customer types and phases, revealing emotions, technology needs, and helping identify most important points.
  • Lyft Example: The customer journey from “need to go from A to B” through “travel” uncovers pain points like finding taxis, leading to themes like efficient transport.
• Existing Product Needs: For established products, continuously revisiting user journey maps is crucial. Teams often fall into the trap of accepting feature requests at face value instead of asking “why” it matters or what deeper problem it solves. Regular review ensures understanding evolves with customer behavior.
• System Needs (Infrastructure): Not all needs come from customers. System or infrastructure needs (e.g., backend functionality, operational tooling) must also be accounted for. These are sometimes called technical or nonfunctional needs. The mobile physical therapy app example (Billing & Payments theme requiring API integration subthemes) illustrates this.
• Opportunity-Solution Trees: Teresa Torres’s visualization helps organize ideas and distinguish solutions from problems. It starts with a clear desired outcome (business objective), then identifies opportunities (themes), which lead to solutions (features), and finally experiments to validate those solutions. This hierarchy simplifies decision-making and focuses efforts.

Using Job Stories and User Stories to Support Themes

These frameworks help describe customer needs without jumping to solutions.

• User Stories (Agile): “As a [user type], I want [desire] so I can [result].”
• Job Stories (Jobs-to-be-Done): “When [situation/motivation], I need [desire] so I can [result].”
• Theme Format: The authors propose a simpler format for themes: “Ensure [result] for [stakeholder].” (e.g., “Make mobile experience as good as desktop for users.”) The point is to justify each theme by answering “why.”

Themes Are About Outcomes, Not Outputs

This section re-emphasizes the crucial distinction:

• Output: The stuff you produce (e.g., HTML5 redesign).
• Outcome: The difference your stuff makes (e.g., make mobile experience as good as desktop).
  Translating proposed outputs into themes leaves room for better, less disruptive solutions. The risk of an output-focused roadmap is creating a “feature factory” without achieving desired outcomes.

Relating Themes Back to Your Objectives

Every theme on your roadmap must be tied to at least one strategic objective. This ensures focus and prevents distraction.

• Roadmapping Hierarchy: Vision → Objectives → Themes/Subthemes. Each level builds incrementally on the one before.
• Linking Themes to Objectives: Use methods like color-coding objectives and tagging themes with the associated color (e.g., “theme card”).
• Reviewing Objectives: When planning major roadmap updates (e.g., moving from “Next” to “Now”), always revisit and reconsider your strategic objectives, as they will evolve over time. This ensures the roadmap remains aligned with the current business direction.

The chapter concludes by reinforcing that uncovering, vetting, and linking customer needs (themes) to strategic objectives is fundamental. Staying disciplined in this process—avoiding the temptation to jump to solutions—ensures the product adds real value and leads to better products.

Deepening Your Roadmap

This chapter builds upon the foundational primary components of a roadmap by detailing how secondary components can add crucial clarity and value for specific stakeholders. While optional, these additions improve communication, aid buy-in, and encourage more critical thinking about each roadmap item. The authors emphasize the importance of balancing detail—enough to inform, but not so much as to overwhelm.

Features and Solutions: How They Can Work with Themes

While themes focus on needs, features are the solutions built to address them. Features can appear on a theme-based roadmap in specific scenarios:

• Probable Solutions: When a likely solution is evident, even if not fully vetted. This provides a helpful starting point for exploration (e.g., QuickBooks for billing needs).
• Infrastructure Solutions: Backend or system-level needs often transition quickly into specific solutions, especially when defined and vetted internally by the engineering team (e.g., “Solr Proof of Concept” for a search engine).
• Carryover Solutions: Features or themes from previous plans that were incomplete due to time or resource constraints.

Where Features Appear: Features should be added as subthemes rather than replacing themes. This maintains the context of why the solution is being implemented. The Buffer social media tool’s public roadmap is given as an example of a feature-level roadmap, highlighting the common but sometimes risky practice of showing highly specific deliverables externally.

Key Questions for Features: Before adding features, product teams should ask:

• Is there enough understanding and confidence in a particular solution?
• Are there validated carryover or infrastructure needs?
• Are there mandates from decision-making stakeholders?
• What is the likelihood of change for this solution (i.e., confidence)?

Using Stage of Development

Communicating a product’s development stage helps manage expectations and inform resource allocation.

• Labels like “discovery,” “design,” “prototyping,” “pre-production,” “alpha,” or “beta” clearly convey where an item stands in its lifecycle.
• The Spotify example of tagging items as “think it,” “ship it,” or “tweak it” is a simple yet effective way to indicate status and implicitly differentiate themes from features (since “think it” items are clearly unresolved themes).

Key Questions for Stage of Development:

• Do themes/features go through distinct, longer-than-roadmap-timeframe stages?
• Is this detail helpful for managing stakeholder expectations (or is “confidence” enough)?

Communicating Confidence

Since predicting the future is impossible, 100% confidence in roadmap items is unrealistic.

• Implied Confidence: Closer timeframes (e.g., “Now”) inherently suggest higher confidence than distant ones (“Later”).
• Explicit Confidence Scores: Attaching a percentage (e.g., 75%) or a decreasing gradient bar to timeframes or individual items quantifies certainty and manages expectations (e.g., Predictive Index example).
• Confidence Separation Line: A visual line in the “Now” column to distinguish between “confident to deliver” and “aspirational” items.

Key Questions for Confidence:

• Does the roadmap have specific timeframes?
• Are items far enough in the future to warrant reluctance in commitment?
• How regularly does the team hit projected dates?
• Do stakeholders assume written items are promises?
• Is stage-of-development information already sufficient for confidence?

Identifying Target Customers

When a product serves multiple customer types (e.g., student, teacher, administrator), indicating which themes or features apply to which customer types is valuable.

• Methods: Simple tagging/labeling or creating separate rows (swim lanes) for each customer type.
• Purpose: Ensures balanced focus on different customer needs and aids stakeholder discussions.

Key Questions for Target Customers:

• Are there distinct customer types with different needs?
• Is balancing these needs important?
• Are certain customer types more important than others?
• Will clarifying customer types help guide stakeholder conversations?

Tagging Product Areas

For complex products, annotating items by internal product areas (e.g., “user interface,” “platform,” “APIs”) helps organize development and ensures comprehensive coverage.

• Methods: Color coding, text labels, or separate rows.
• Caution: Avoid information overload. Prioritize which labels are most important for stakeholders.

Key Questions for Product Areas:

• Does the product have distinct, communicable areas?
• Are there separate business objectives for individual areas?
• Is it important to show work across all or specific areas?
• Will marking product areas guide stakeholder conversations?

Secondary Components Summary: Strive for Balance

The authors reiterate that these components are supplementary. The key is to experiment and find the right balance of detail for your unique team, product, and ecosystem. Too much information can be overwhelming, while too little causes confusion. A well-scrutinized, well-organized roadmap, even with selective secondary components, leads to improved communication, increased team confidence, and ultimately, better products.

Prioritizing–with Science!

This chapter champions the use of objective, collaborative prioritization frameworks to ensure that product teams work on the most impactful initiatives. It argues that effective prioritization is crucial for navigating resource limitations, avoiding “shiny object syndrome,” and gaining alignment among stakeholders, ultimately leading to higher ROI and organizational success.

Why Prioritization Is Crucial

• Opportunity Cost: Resources are always limited. Not prioritizing means risking never getting the most important things done. The authors introduce the “law”: Always assume you may have to stop work at any time. This forces ruthless prioritization of high-value tasks first. Bruce McCarthy’s anecdote about redirecting a sales effort from low-profit small businesses to high-ROI national accounts illustrates this.
• Shiny Object Syndrome: A common pitfall where priorities shift constantly. Every new feature or project has hidden carrying costs (retesting, documentation, training, support, marketing, sales enablement). Doing too many things in parallel slows everything down due to increased communication, coordination, and mental switching costs.
• Exponential Test Matrix Growth: As features are added, the number of test combinations grows exponentially (2^n – 1). This overhead further demonstrates why limiting features and focusing is critical.

Bad (but Common) Ways to Prioritize

The chapter warns against several common prioritization pitfalls:

• Your, or someone else’s, gut: Lacks rigorous analysis, leads to frequent changes of mind, and disconnects from market reality.
• Analyst opinions: Analysts may lag current trends; internal research is often more insightful.
• Popularity (customer requests): Giving customers exactly what they ask for often leads to unfocused products with poor usability. Customers often can’t articulate their true underlying needs (Steve Jobs’ quote about showing people what they want).
• Sales requests: Prioritizing only to close immediate deals leads to short-term thinking and non-strategic feature development, potentially creating products only one company needs.
• Support requests: While valuable for usability, focusing solely on support issues might neglect critical functionality needed to attract new customers.
• Competitive me-too features: Chasing competitors feature-for-feature turns products into commodities, leading to a race to the bottom on price and profitability. Differentiation is key.

Prioritization Frameworks

Fortunately, effective, objective frameworks exist:

• Critical Path: Identify the absolute “must-have” items that solve the most painful customer problems (dissatisfiers). If these are not met, customers won’t adopt the product. This helps define an MVP (Minimum Viable Product). Evan Ryan’s BarnManager case study illustrates focusing on secure digital record keeping as the critical path.
• Kano Model: Classifies customer expectations into three categories to guide prioritization:
  • Expected Needs (Dissatisfiers): Minimum requirements; if missing, customers are dissatisfied (e.g., car windshield wipers).
  • Normal Needs (Satisfiers): Things that satisfy but aren’t strictly necessary (e.g., intermittent wipers).
  • Exciting Needs (Delighters/Wows): Go beyond expectations (e.g., rain-sensing wipers).
    Over time, expectations rise, shifting “exciting” features to “normal.” Useful for prioritizing add-ons and enhancements.
• Desirability, Feasibility, Viability (DFV): A Venn diagram approach where ideas are scored (e.g., 1-3 scale) across three criteria:
  • Desirability: Value to the customer.
  • Feasibility: Ease for the organization to implement.
  • Viability: Value to the organization (e.g., revenue, profit).
    Ideas scoring high across all three rise to the top (e.g., a hybrid car drivetrain scores high).
• ROI Scorecard: For longer lists of features, this quantifies differences in priority using the formula: Value / Effort = Priority.
  • Value: Defined as Customer Needs + Organization’s Goals. This allows for multiple value drivers beyond just revenue. A simple 0-2 scale is often sufficient for deliberate imprecision.
  • Effort: What it takes for the whole company to deliver (not just engineering). T-shirt sizing (XS-XL) is recommended for rough, relative estimates to avoid frightening engineers with premature commitment.
  • Risks & Unknowns: A confidence percentage can discount expected ROI for risky items.
    The Plush Life scorecard example illustrates ranking feature ideas based on their contribution to multiple goals (sales, margins, LTV) versus effort.
• MoSCoW: While not a prioritization method itself, it’s a clear way to categorize priorities for the development team to define release criteria:
  • Must have: Essential for launch (critical path).
  • Should have: Important, painful to leave out.
  • Could have: Wanted, but first to cut if risks arise (“if easy”).
  • Won’t have: Out of scope for this release (but possibly future).

Limitations of Scoring Approaches

The authors acknowledge that numerical prioritization methods can be controversial, sometimes leading to a false sense of confidence or being used to justify political decisions. However, they argue that scorecards often force teams to clarify, articulate, and align on their strategy and value proposition, leading to more rational discussions about trade-offs. The frameworks are aids to decision-making, not the decision itself.

Dependencies, Resources, and Promises: Priorities set by these frameworks may need adjustment due to external factors like resource availability, technical dependencies, or prior commitments to stakeholders (board, key customers). These factors don’t change the priority but can affect the scheduling of items.

The chapter concludes that companies consistently focusing on a few highly leveraged initiatives learn faster, grow larger, and become successful. It encourages using these frameworks thoughtfully and maintaining flexible timeframes. With priorities established, the next step is to achieve buy-in and alignment.

Achieving Alignment and Buy-in

This chapter emphasizes that even the most meticulously crafted roadmap will fail if the people funding, executing, and receiving its output don’t believe in it. It highlights that alignment and collaboration are crucial for a roadmap’s success, distinguishing them from the often-problematic pursuit of consensus. The chapter then details three primary mechanisms for achieving this buy-in: shuttle diplomacy, meetings and workshops, and software applications.

Alignment, Consensus, and Collaboration Defined

• Alignment: A concerted effort where people understand the issues and their roles, even if they have differing opinions. It’s about shared intent, not universal agreement.
• Consensus: Everyone reaches a mutually agreed-upon decision. In practice, this often leads to lengthy discussions, diluted decisions, and a lack of individual accountability. The authors explicitly state: “you do not need consensus to get your roadmap in place.”
• Collaboration: Individuals cooperate towards a common goal or outcome. They work together for a shared purpose, even if they don’t concur on every step, as long as they agree on the final outcome.

The core message is that for a roadmap, you need alignment and collaboration, not consensus.

Shuttle Diplomacy

Inspired by Henry Kissinger’s negotiations, this approach involves meeting with each stakeholder individually to build trust, gather input, and navigate compromises before a group meeting.

• Why it Works:
  • Manages politics: One-on-one settings reduce pressure to “perform” or “impress” others.
  • Builds trust and rapport: By listening sympathetically and asking “why,” you give authorship to the plan.
  • Uncovers hidden agendas/unwritten goals: Stakeholders are more likely to reveal true concerns privately.
  • Facilitates compromise: Easier to find common ground without a public audience.
• How to Engage (The GROW Model): Use GROW as a guide for one-on-one conversations:
  • Goals: What are they trying to accomplish?
  • Reality: What’s currently on their plate? What are recent challenges?
  • Options: What do they think should be on the roadmap? What options have been discussed?
  • Way forward: Which options best help achieve their goals? What are their top priorities?
• Shuttle Diplomacy Canvas: A tool for tracking these meetings, noting desired outcomes, motivations, metrics, top priorities, and political considerations for each stakeholder. This is a guide for the product manager, not a shared document.
• What’s Difficult: It’s time-consuming, though keeping meetings short and informal helps. Rapport and location (in-person is preferable) can also be challenges.

Meetings and Workshops

Once shuttle diplomacy is complete, a cross-functional meeting or workshop can solidify final buy-in.

• When it Works: Best when there’s a culture of constructive disagreement and general agreement on overall organizational strategy.
• Presenting Recommendations: In larger, hierarchical organizations, this might involve a formal presentation of recommendations to a steering committee or executives (e.g., Emily Tyson at NaviHealth, where teams did “homework” on inputs, sizing, and business cases before presenting).
• Co-creation Workshop: A more collaborative approach where stakeholders collectively figure out the roadmap. Can follow shuttle diplomacy or, for smaller teams, be the starting point.
  • Clear Plan and Outcomes: Essential before holding, typically aiming to finalize the roadmap for the upcoming period (often quarterly).
  • Workshop Agenda:
    • Hopes and Fears: Elicit emotional aspirations and roadblocks (Post-it notes).
    • Vision and Goals: Articulate or revisit product vision (e.g., using the “MadLibs” prompt or the Cover Story exercise from Gamestorming).
    • Back-plan: Start from the envisioned future and work backward step-by-step to the present, ensuring realistic changes.
    • Sizing and Prioritizing: Use exercises like the $100 test (from Gamestorming) to “invest” in customer needs, breaking themes into desirability, feasibility, and viability for targeted investment.

Software Applications

Many teams use digital tools to aid alignment, especially for distributed teams.

• Examples: ProdPad, Roadmunk, Aha!, ProductPlan, JIRA, Slack, Google Docs, Asana, Trello.
• How they help: Facilitate tracking progress, commenting, approval workflows, and consolidating multiple roadmaps (e.g., Vanessa Ferranto’s use of JIRA at Zipcar for tracking objectives and ensuring cross-functional alignment through weekly meetings; Sameena Velshi’s use of Roadmunk).
• Crucial Note: No team relied solely on software; some form of face-to-face meetings (or strong virtual equivalents) remain necessary for true alignment.

The chapter concludes by stressing that regardless of the methods used (shuttle diplomacy, co-creation workshops, or software), the goal is always to get the team and organization aligned on product direction. Once this is achieved, the roadmap can be formalized, published, and distributed.

Presenting and Sharing Your Roadmap

This chapter focuses on the crucial final steps of the roadmapping process: effectively presenting and sharing your roadmap to inspire, align, and gather feedback from various internal and external stakeholders. It emphasizes that a well-communicated roadmap is a powerful tool for driving excitement about the product’s future.

Why to Share Your Roadmap Internally

Broad internal sharing is vital for several reasons:

• Inspiration: A compelling product roadmap, rooted in a strong product vision, paints a picture of a successful future, motivating everyone in the organization to contribute. It helps people connect their work to a larger purpose.
• Alignment: The roadmap informs and aligns the planning activities of every department—sales, marketing, support, manufacturing, operations, finance, etc. It ensures everyone is “pulling in the same direction with the same timing,” like coordinated rowers.
• The IKEA Effect: Involving people in the development and refinement of the roadmap (through co-creation workshops or shuttle diplomacy, as discussed in Chapter 8) significantly increases their buy-in and ownership. People value what they help create.

Why to Share Your Roadmap Externally

While potentially daunting, external sharing can be highly beneficial:

• Customer Engagement: If customers are inspired by your vision and align their plans with yours, it can be transformational. Jeff Bussgang’s experience at Open Market, where a re-architecture was framed around extensibility to meet customer needs, is a prime example of successfully gaining customer patience and advocacy during a difficult period.
• Preparation for Change: For enterprise software or hardware, customers need to understand upcoming changes to prepare their own organizations (e.g., for integrations, training, or product cycles).
• Advocacy: Engaged customers can become powerful advocates, smoothing internal politics and purchasing roadblocks for future releases.

The Risks of Sharing

Sharing roadmaps isn’t without its challenges, which must be carefully managed:

• Overpromising and Underdelivering: The biggest fear. The authors (and Janna Bastow, CEO of ProdPad) argue that honesty and transparency about priorities and uncertainties can build trust, allowing customers to be forgiving if plans change. The roadmap is an intent, not a contract.
• The Osborne Effect: Announcing future products too early can cannibalize sales of current products, as customers wait for the next version. This is more common with hard goods that aren’t easily upgradable.
• Competition: Revealing plans can give competitors an advantage. However, for certain industries (e.g., component manufacturers like Analog Devices), sharing detailed roadmaps with customers is a necessity for securing long-term business due to customer planning cycles. Samuel Clemens (InsightSquared) notes that internal roadmaps are often never shared externally, but staff can use the information to respond to customer inquiries.

Managing Risk with Janna Bastow’s Chart: The chapter references a useful chart by Janna Bastow that illustrates how much detail and which initiatives to share by role. Generally, the further from the core product development team, the less detail (features, dates) should be shared, and less about brand-new directions or internal infrastructure.

Multiple Roadmaps? Not So Fast!

Instead of creating entirely separate roadmaps for each audience, the authors recommend a modular approach. Build the specific details relevant to each group on top of the common foundation of your product vision, strategy, and themes. This might mean starting with universal slides for all audiences, then adding specific slides tailored to individual groups, incorporating complementary information. This maintains organizational alignment while addressing diverse interests.

Presenting the Roadmap to Stakeholders

Effective presentation requires careful preparation and a strategic flow:

• Preparation Checklist:
  • Identify your audience: Their role, prior exposure to the roadmap, and existing input.
  • Clarify your goals: What do you need from this meeting (input, alignment, informing)?
  • Determine audience concerns: What level of detail is necessary?
  • Assemble components: Select relevant primary, secondary, and complementary information.
• Suggested Presentation Sequence:
  • Start with the “why” (product vision), ensuring everyone is on board before moving to details.
  • Cover recent progress, including emotional anecdotes or customer quotes to humanize the data.
  • Show near-term plans, clarifying critical needs, prioritization rationale, and alignment with business objectives. Use stories from sales/support.
  • Propose longer-term plans, reinforcing alignment with company objectives.

The chapter ends with a case study of Chef.io’s roadmap presentation, illustrating how they moved from a top-down, feature-heavy 2013 roadmap to a more flexible, theme-based model in ProdPad, which informed a public slide-based presentation that included disclaimers, key metrics, and staged development cycles (“Considering,” “In development,” “Released”) to manage customer expectations without over-committing. The key takeaway is the shift from a prescriptive “here’s what we’ll build” to a communicative “here’s where we’re going and why.”

Keeping It Fresh

This chapter squarely addresses the inevitability of change in product development, asserting that roadmaps, like living organisms, must evolve to survive in dynamic environments. It provides practical guidance on managing both planned and unplanned changes, emphasizing clear communication to maintain stakeholder trust and alignment.

Roadmap Evolution

The chapter uses the metaphor of Darwin’s Galapagos finches to illustrate how species (and roadmaps) evolve in response to environmental stimuli. A stable environment leads to little change, but most markets are dynamic due to technological advances, competition, shifting customer needs, and even changes in company mission. Gillian Daniel’s experience at smartShift Technologies, where increasing costs led to a shift in business objectives (adding “increase profit”) and subsequently in roadmap priorities, exemplifies this responsive evolution. The concept of punctuated equilibrium (long periods of stability interspersed with rapid change) is presented as a good metaphor for managing roadmap evolution with minimal disruption.

How Far Out Should Your Roadmap Go?

The timeframe of a roadmap should directly correlate with the pace of change in its market and product’s stage of life:

• Faster pace / Discovery stage: Shorter roadmaps (e.g., months).
• Slower pace / Maturity/Decline stage: Longer roadmaps (e.g., years, like Intel’s 2-3 year public roadmap).
  Startups, where future plans are highly uncertain, often favor simple “Now, Next, Later” formats. It’s impractical to detail long-term plans that will likely change.

Planned Change

The authors confidently state that stakeholders (customers, partners, sales, board) expect and understand roadmap changes, especially if these changes are justified by market shifts or strategic adjustments. A roadmap is explicitly not a contract. As long as the essential vision is shared, stakeholders are generally supportive of considered changes, especially when their interests are clearly being served.

Change Frequency: The refresh rate of the roadmap should match its time scale. If a roadmap is laid out in quarters, it should be revisited and updated quarterly. This involves regularly re-examining visions, strategy, goals, and themes.

Unplanned Change

Unexpected delays and external pressures are inevitable. The chapter introduces the Iron Triangle (Schedule, Scope, Resources, Quality) as a framework for managing these trade-offs:

• Schedule: The most obvious response to delays, but not always the best if it means missing commitments or market windows.
• Scope: If schedule is fixed, reducing what’s planned for delivery (e.g., fewer features, reduced capacity). Henry Ford’s black-only Model T paint decision to accelerate manufacturing is a classic example.
• Resources: Adding more resources, which typically inflates budget and starves other priorities. This is problematic in software development (“adding manpower to a late software project makes it later,” Brooks’s The Mythical Man-Month), favoring small teams (Amazon’s two-pizza rule).
• Quality: The variable that suffers when schedule, scope, and budget are held constant despite slippage. This leads to defects, bugs, and technical debt, ultimately slowing future progress.
  • When to Compromise on Quality: Surprisingly, compromising on quality can be acceptable for Minimum Viable Products (MVPs), especially for unproven ideas where rapid learning is paramount. The goal is to collect validated learning with least effort, iterate quickly, and only invest in higher quality/scale once success is proven.

Special Requests: Handling “slip-in” requests (often from sales for “special” customers) requires asking three questions:

1. What problem is this request trying to solve?: Get to the root customer need, not just the requested feature.
2. Does solving that need align with our objectives?: Does it contribute to the defined strategic goals?
3. Is it more important than what’s on the roadmap now?: Evaluate trade-offs objectively (using prioritization methods from Chapter 7). Swapping out an item of similar scope is often the least disruptive approach.

External Pressures: Competitors, economic shifts, new regulations, or changing fashions inevitably impact strategy. Roadmaps must adjust. A business can stay the course if the core problem remains, but the route to get there should be flexible.

Changes in Strategy: Sometimes, a business realizes its entire strategy or goals are wrong. This necessitates a pivot—a “change in strategy without a change in vision” (Eric Ries). Intel’s shift from memory chips to microprocessors is a historical example. Pivoting often requires revisiting the product vision entirely and explicitly communicating fundamental changes.

Communicating Change

Clear and broad communication of “why,” “what,” and “when” is critical for roadmap updates.

• Why: The most important part. Don’t shy away from explaining the reasons for change (e.g., market shifts, new learnings, achieving a goal). This builds trust and prevents cynicism.
• What and When: Specify how strategy shifts affect deliverables. Changes can be small (affecting release plan), broad-reaching (moving themes), or fundamental (pivoting). Broad and fundamental changes require updating the roadmap, informing stakeholders, and obtaining buy-in.
• Roadmap Changes Example (Wombat Garden Hose): The chapter walks through an example where “no-leak connections” for a 20-foot hose are prioritized, while the 40-foot model is delayed. Crucially, a strategic opportunity in fertilizer delivery (based on early customer feedback) causes “Fertilizer Delivery” to move from 2019 to H2 2017. This leads to previewing a new strategic vision (“To perfect the landscapes of affluent Americans by perfecting nutrient delivery”) for the executive team.
• Forks in the Road: Companies often face strategic choices (e.g., grow down-market vs. differentiate up-market). Roadmaps can incorporate optionality and decision criteria (thresholds based on key results) to define which path will be followed based on initial product performance.

The chapter concludes by emphasizing that while change is unavoidable (“Everyone has a plan ’til they get punched in the mouth,” Mike Tyson), following the book’s process allows roadmaps to evolve. Regular reassessment and clear communication of “why, what, and when” changes occur are key to success.

Relaunching Roadmaps in Your Organization

This concluding chapter serves as a practical guide for implementing the relaunched roadmapping paradigm within any organization. It acknowledges the common frustrations with traditional roadmaps and offers a structured, incremental approach to assess current practices, gain buy-in for change, train stakeholders, and continuously evolve the process.

How to Get Started: A Six-Step Process

The authors propose a methodical approach to adopting the new roadmapping philosophy:

1. Assess Your Situation and Choose an Approach:
   • Start by defining the problem with your current process (or lack thereof).
   • Use the “Roadmap Health Assessment Checklist” (14 questions covering strategic context, value focus, learning, prioritization, customer engagement, and avoidance of overpromising/overplanning). Each question is scored 0-2 (0=no, 1=maybe, 2=yes), with negative scores for overpromising/overplanning.
   • Score 18+ (Great Shape): Use Approach A (Course Corrections) to tweak and enhance.
   • Score 12-17 (Reasonably Good Shape): Use Approach A, but recognize significant improvements are needed.
   • Score 11 or lower (Broken/No Process): Use Approach B (The Full Relaunch).
2. Get Buy-in for Change from Key Stakeholders:
   • Change requires alignment. Review Chapter 8 on shuttle diplomacy and co-creation workshops.
   • Involve stakeholders in the Roadmap Health Assessment itself. This fosters shared understanding and agreement on the necessity for change.
   • Focus on aligning on the necessity for change, even if agreement on how to change is not immediate.
3. Train Your Stakeholders How to Contribute:
   • Acknowledge that this is a new approach for many. Explain what’s different, why, and how it will be better.
   • Borrow principles and steps from this book. Resources are available at www.productroadmapping.com. Roadmapping is a collaborative effort, and stakeholders need to understand their part.
4. Start Small and Work Incrementally:
   • For Approach A (Course Corrections): Pick one area for improvement (e.g., a prioritization model, defining short-term objectives). Aim for a goal achievable in a few weeks to demonstrate early success and build momentum.
   • For Approach B (Full Relaunch): While comprehensive, limit the initial scope. A roadmap workshop (like a Design Sprint, ideally led by an expert facilitator) can define initial vision, objectives, and themes in a few days. Initially, involve only the product core (product people, engineers, designers), gradually expanding the circle of stakeholders once confidence is gained.
5. Evaluate Your Results and Align on Next Steps:
   • Just as you evaluate product releases, assess changes to the roadmapping process.
   • Gather stakeholders periodically to review changes and seek feedback on their effects (intended or not).
   • Use a cross-functional product steering committee (meeting every 3-6 weeks) to review progress and align on next steps. This team can also inform roadmap planning based on actual product results.
   • Emphasize that the process will continue to evolve, acknowledging roadblocks and learning from them.
6. Keep Relaunching:
   • Recognize that change is hard, especially across organizational boundaries.
   • Don’t give up. The authors have seen positive changes in diverse organizations.
   • Gillian’s Story of Roadmap Change at smartShift Technologies illustrates the full cycle: defining vision and business objectives, using a scorecard for prioritization (adding “profit” to the scorecard based on post-launch analysis), employing shuttle diplomacy for alignment, empowering product managers to publish strategy-focused roadmaps, and adapting the roadmap based on market and business results.

Postscript: Continuous Learning and Collaboration

The book encourages readers to:

• Share their learning with other product professionals.
• Talk regularly with peers to understand their roadmapping processes, challenges, and solutions.
• Look outside their market/industry (e.g., digital product teams connecting with physical product teams, B2C with B2B) to gain fresh perspectives and adopt effective practices.
• Utilize www.productroadmapping.com to continue learning and sharing experiences.

The final message is clear: change is inevitable, and no plan is immune. But by embracing the iterative, adaptive process outlined in this book, organizations can create roadmaps that evolve, successfully achieving their vision of products that truly improve the world for their customers.

Key Takeaways

Product Roadmaps Relaunched fundamentally shifts the conversation around product planning from rigid, feature-driven schedules to dynamic, value-driven strategic tools. The core lesson is that a modern product roadmap is a living document that tells the story of why you are building what you’re building, and how it will achieve your vision, rather than simply what and when. It’s about outcomes, not just outputs. This strategic focus fosters alignment, inspires teams, and engages customers, making the product development process more effective and resilient in an uncertain world.

Core Lessons:

• Outcomes over Outputs: Roadmaps should focus on customer needs, problems, and desired business outcomes (themes) rather than simply listing features and release dates. This prevents “feature factories” and ensures real value delivery.
• Vision-Driven Strategy: Every item on the roadmap must clearly tie back to a compelling product vision and measurable business objectives. This provides critical context, drives alignment, and justifies resource allocation.
• Embrace Uncertainty: Roadmaps are not contracts or predictions. Use broad timeframes, communicate confidence levels, and be transparent about the iterative nature of product development. Expect and plan for change, rather than fighting it.
• Prioritization is Scientific, Not Arbitrary: Employ objective frameworks like the ROI Scorecard, Kano Model, or Desirability/Feasibility/Viability to make informed decisions about what to build first, considering value, effort, and risk.
• Alignment is Paramount: Achieve buy-in across all stakeholders (internal and external) through collaborative methods like shuttle diplomacy and co-creation workshops. Give stakeholders authorship in the plan to reduce friction and build trust.
• Continuous Evolution: Roadmaps are living documents that must be regularly revisited and updated to reflect market changes, new learnings, and shifts in strategy. The process of roadmapping itself is iterative.

Next Actions:

• Assess your current “roadmap health”: Use the checklist provided in Chapter 11 to objectively evaluate where your organization stands. This is your baseline.
• Define (or redefine) your Product Vision and Business Objectives: Ensure these are clear, compelling, measurable, and widely understood by all relevant stakeholders. This is the “why” that anchors everything.
• Shift to Themes: Start thinking about customer needs and problems as your core roadmap items. For every feature request, ask “What problem does this solve?” or “What outcome are we trying to achieve?”
• Experiment with a Prioritization Framework: Pick one of the objective methods (e.g., ROI Scorecard) and apply it to a small set of current initiatives. See what insights it reveals and how it changes your discussions.
• Plan a Buy-in Process: Identify your key stakeholders and plan a structured approach (e.g., a series of one-on-one “shuttle diplomacy” meetings or a small co-creation workshop) to engage them in the roadmap development.

Reflection Prompts:

• How often does our current product planning process lead to missed deadlines or features that don’t quite hit the mark for customers?
• If I asked five different people in my organization to explain our product’s core strategy for the next year, how consistent would their answers be?
• Are we genuinely focusing on solving customer problems, or are we primarily building features that competitors have or that a loud stakeholder requested?