Strategize: Product Strategy and Product Roadmap Practices for the Digital Age Summary

Introduction

Strategize by Roman Pichler offers a comprehensive guide for product managers, product owners, entrepreneurs, and others responsible for creating and managing successful digital products in a rapidly evolving landscape. The book aims to empower product people to move beyond just tactical execution and make informed strategic decisions that lead to impactful products. Pichler breaks down the often-overlooked, yet crucial, practices of defining a product strategy and building an actionable product roadmap.

This summary captures every essential concept, technique, and tool presented in Strategize, translated into plain language. It provides a structured overview, ensuring that whether you’re new to product strategy or looking to refine your approach, you’ll gain a clear understanding of how to connect vision, strategy, and tactics to drive product success in the digital age. Every idea from the book is included here, organized for maximum readability without complex or lengthy lists.

Part 1: Product Strategy

This section delves into the foundational principles and practices for developing a winning product strategy. It emphasizes the importance of making the right strategic decisions before focusing on tactical execution. The chapters cover key concepts, methods for strategy development, and crucial validation techniques.

Strategy Foundations: Setting the Stage for Strategic Thinking

This chapter introduces the core concepts needed to build a solid product strategy. It explains what a product strategy is, how it connects to a larger vision, and how business goals and innovation types influence product direction. Understanding these foundations is essential for creating an effective strategy.

Understanding What a Product Strategy Is

A product strategy acts as a high-level plan to achieve a long-term product goal, outlining the who, what, and why of the product. It provides a big-picture view to guide tactical development and avoid getting lost in details.

Defines the Market: It specifies the target customers and users the product aims to serve and the problems it solves or benefits it provides.
Highlights Key Features and Differentiators: The strategy identifies the crucial aspects that create value and make the product stand out from competitors, not a comprehensive list of all features.
Captures Business Goals: It explains how the product benefits the company, such as generating revenue, reducing costs, or increasing brand equity, providing the rationale for investment.
Guides Decision-Making: The strategy helps product teams prioritize and make consistent choices that align with the overall product direction.
Is Not Static: A product strategy evolves as the product grows and matures, requiring regular review and adjustment, typically at least quarterly.

Thinking Big and Describing Your Vision

The product vision is the ultimate, aspirational reason for creating a product – the positive change it should bring about. It serves as the product’s true north and a source of motivation.

The Vision is the “Why”: It articulates the higher purpose or impact the product aims to have in the long term.
Motivates and Unites: A clear vision inspires the people working on the product and fosters a shared sense of purpose, facilitating collaboration.
Provides Guidance: Even when facing challenges, the vision offers direction and helps teams stay focused on the ultimate goal.
Effective Vision Qualities: An effective vision is big (broad enough to allow for strategy changes), shared, inspiring, and concise (easy to communicate and remember).
Vision vs. Strategy: The vision is the long-term “why,” while the strategy is the high-level “how” to achieve that vision.
Capturing the Vision: The vision can be expressed as a brief statement or slogan, making it easy to share and understand.

Finding Out How Vision, Strategy, and Tactics Relate

Vision, strategy, and tactics form a hierarchy, with each level guiding the one below it, yet also being influenced by feedback from the lower levels.

Vision Guides Strategy: The overarching vision provides the direction and context for developing the high-level product strategy.
Strategy Directs Tactics: The product strategy informs the tactical details needed for development, such as user stories, design, and technical decisions.
Tactics Inform Strategy: Insights gained from tactical work, including customer feedback and development progress, can lead to adjustments in the product strategy.
Strategy Influences Vision: If a valid strategy to achieve the current vision cannot be found, the vision itself may need to be re-evaluated or changed.
Different Levels of Detail: The vision is aspirational and high-level, the strategy provides the direction and approach, and tactics are the concrete steps for execution.
Table Summary: The book provides a table illustrating the level (Vision, Strategy, Tactics), description, and sample artifacts for each.

Letting the Business Strategy Guide the Product Strategy

A product exists to create value for the company, so the product strategy must align with and support the overall business strategy. This ensures the product contributes to the company’s broader objectives.

Product as a Means to an End: Products are built to help the business achieve its goals and implement its strategy.
Business Strategy Defines Direction: The business strategy sets the context for which markets to target, what types of innovation to pursue, and how the company competes.
Alignment Ensures Support: A product strategy that supports the business strategy is more likely to receive the necessary resources, funding, and management backing.
Vision Alignment: Just as the product strategy aligns with the business strategy, the product vision should be in line with the overall company vision or mission.
Starting Point: If a clear business strategy exists, the product strategy should be derived from it; if not, the product strategy might act as a business strategy, especially for startups.
Avoiding Misdirection: Without alignment, the product could move in a direction that doesn’t contribute to or even hinders the company’s success.

Being Clear on Your Innovation Strategy

Understanding the type of innovation a product represents—core, adjacent, or disruptive—is crucial as it significantly shapes the product strategy, the required resources, and the acceptable level of risk.

Innovation Ambition Matrix: This tool, based on the newness of the product and the market, helps classify innovations.
Core Innovations: These optimize existing products for established markets, leveraging existing skills and assets with low risk and high predictability.
Adjacent Innovations: These involve taking existing strengths to new markets or creating new products for existing markets, with medium risk and requiring new insights and potentially new skills.
Disruptive Innovations: These create new products for new markets (often by addressing non-consumption), carrying high risk but offering significant long-term growth potential and requiring an entrepreneurial mindset.
Impact on Strategy: The innovation type determines the appropriate attitude (conservative vs. inquisitive vs. entrepreneurial), organizational setup (business as usual vs. dedicated team vs. incubator), technology approach, and the level of research and validation required.
Financial Forecast Reliability: Core innovations allow for reliable financial forecasts, adjacent ones make it difficult, and disruptive ones make it impossible; for the latter, focus on the risk of inaction.
Organic Growth: Companies need to invest in adjacent and disruptive innovations to secure future growth.

Taking Advantage of the Product Life Cycle Model

The product life cycle model describes how products evolve over time through development, introduction, growth, maturity, and decline. Understanding the current stage informs strategic decisions aimed at maximizing product success and longevity.

Stages of Life: The model includes Development, Introduction, Growth, Maturity, and Decline, marked by events like launch, Product-Market Fit (PMF), and end of life.
Goal in Development: Find a valid strategy resulting in a beneficial, feasible, and economically viable product, often involving validation and potential pivots.
Goal in Introduction: Achieve PMF and rapid growth by adapting and improving the product, potentially bridging a “chasm” for mainstream adoption.
Goal in Growth: Sustain growth by penetrating the market, fending off competitors, and managing the product’s increasing size and complexity.
Goal in Maturity: Extend the life cycle by revitalizing the product (e.g., enhancing features, entering new markets, bundling) or managing a gradual decline by optimizing costs.
Goal in Decline: Minimize investment and eventually discontinue the product as profits drop.
Strategic Inflection Points: The transitions between stages, particularly from introduction to growth (PMF) and from growth to maturity, are crucial moments for strategic decisions.
Life Cycle Extension: Techniques like adding features, unbundling, repositioning, or bundling can move a product back into the growth stage.

Capturing Your Strategy with the Product Vision Board

The Product Vision Board is a simple yet powerful tool designed to structure, communicate, test, and refine a product strategy collaboratively.

Five Key Sections: The board consists of Vision, Target Group, Needs, Product, and Business Goals.
Vision: Captures the overarching goal or positive change the product aims to bring about.
Target Group: Describes the market segment, customers, and users.
Needs: States the value the product creates, the problem it solves, or the benefit it provides for the target group.
Product: Explains what the product is, its key differentiators, and its technical feasibility.
Business Goals: Defines the desired benefits for the company, such as revenue or cost reduction.
Facilitates Communication: The visual format makes the strategy easy to share and understand among stakeholders.
Supports Collaboration: Can be used in workshops to collaboratively define and refine the strategy.
Testing and Refining: Helps identify areas of the strategy that need validation and adjustment.

Complementing Your Strategy with a Business Model

A product strategy should be complemented by a business model, which explains how the product will generate value for the company beyond just defining business goals.

Monetization: The business model clarifies how the product will make money, such as through subscriptions, freemium, advertising, or bait and hook.
Extended Product Vision Board: Pichler offers an extended version of the Product Vision Board with additional sections for Competitors, Revenue Sources, Cost Factors, and Channels to capture the business model alongside the strategy.
Competitors: Describes the competitive landscape, including strengths and weaknesses of rivals.
Revenue Sources: Outlines how money will be generated (licenses, subscriptions, ads, etc.).
Cost Factors: Identifies the costs associated with developing, marketing, selling, and supporting the product.
Channels: Explains how customers will be reached for marketing, sales, and delivery.
Business Model vs. Business Case: The business model explains how value is created and captured; the business case quantifies the expected financial performance over a specific period.
Importance of Business Model: Understanding the business model is essential to ensure the product is economically viable and worthwhile for the company.

Choosing the Right Key Performance Indicators (KPIs) for Your Product

Key Performance Indicators (KPIs) are essential metrics for measuring a product’s performance and determining if its business goals are being met, moving beyond guesswork to data-driven decisions.

Making Goals Measurable: KPIs link directly to the business goals outlined in the product strategy, requiring those goals to be specific and quantifiable.
Avoiding Vanity Metrics: Focus on metrics that truly indicate performance and value creation rather than those that merely look impressive without providing real insight.
Selecting Relevant Indicators: Choose a small number of metrics that effectively measure progress towards the business goals, avoiding the temptation to track everything.
Sensitivity to Life Cycle: Be aware that the relevance and measurability of certain KPIs change throughout the product life cycle (e.g., profit measures become relevant later).
Quantitative and Qualitative: Combine “hard” data metrics (like daily active users) with qualitative insights (like user feedback) for a balanced view of performance.
Lagging and Leading Indicators: Use lagging indicators (like revenue) to understand past performance and leading indicators (like code quality or team motivation) to anticipate future outcomes.
Holistic View: Look beyond just financial and customer metrics to include product, process, and people indicators for a comprehensive understanding of product health and potential.
Leveraging Trends: Analyze how KPIs change over time or compare across groups to identify meaningful trends that inform strategic adjustments.

Tracking the Product Performance with a Product Scorecard

A product scorecard or dashboard is a tool for collecting and visualizing the relevant data from chosen KPIs to track product performance in a structured and holistic way.

Balanced Scorecard Approach: Pichler recommends a balanced product scorecard that considers four perspectives: financial, customer, product and process, and people.
Financial Perspective: Includes metrics like revenue, cost, profit, customer lifetime value, and cash flow.
Customer Perspective: Covers indicators like market share, adoption rate, engagement, retention, Net Promoter Score (NPS), cancellation rate, complaints, and feedback.
Product and Process Perspective: Tracks metrics related to user interaction (most/least used features, user journeys), product quality (code complexity, bugs, test coverage), and development process effectiveness.
People Perspective: Measures team motivation, knowledge and skills, stakeholder engagement, and management sponsorship.
Visualizing Data: The scorecard provides a central place to display KPI data, making it easy to see performance at a glance.
Regular Review: The scorecard should be reviewed regularly (though the frequency for different metrics may vary) to inform strategic adjustments and identify areas for improvement.

Complementing KPIs with Operational Metrics

While KPIs measure overall product performance against business goals, operational metrics provide more granular insights into how well specific product goals are being met within individual releases or sprints.

Three-Tiered Goal Structure: Business goals (strategy level) inform product goals (roadmap level), which in turn inform sprint goals (tactical level).
Product Goals: These are specific benefits major releases aim to deliver, captured on the product roadmap along with relevant metrics for measuring their attainment.
Sprint Goals: These are the objectives for individual development iterations, derived from the product goals and having their own success criteria.
Measurable Goals: Operational metrics make product and sprint goals quantifiable, allowing teams to determine if they are being met.
Connecting Levels: Feedback and data from lower levels (sprint metrics, product goals met) can influence higher levels (roadmap, strategy).
Avoiding Confusion: Operational metrics should complement, not replace, KPIs; they serve different purposes at different levels of planning.

Engaging the Stakeholders

Securing the support and buy-in of internal stakeholders is vital for product success, as they are involved in developing, releasing, and providing the product. Effective engagement ensures a shared understanding and commitment to the product strategy.

Identifying Stakeholders: Determine who has a stake in the product, including representatives from various business functions and the development team.
Power-Interest Grid: This tool helps analyze stakeholders based on their power (ability to influence or veto) and interest in the product.
Players (High Power, High Interest): These are key partners who should be closely involved in creating, validating, and reviewing the strategy and roadmap.
Subjects (Low Power, High Interest): These individuals feel affected and are keen to influence but cannot veto decisions; they can be valuable allies.
Context Setters (High Power, Low Interest): Often senior managers who affect the product’s environment but have little direct interest; they should be consulted regularly.
The Crowd (Low Power, Low Interest): Individuals who only need to be kept informed of significant changes.
Collaborative Strategy Workshop: A recommended approach to create an initial strategy with key stakeholders, fostering shared ownership and leveraging collective knowledge.
Leadership is Key: The product manager must lead the engagement process, fostering collaboration while being decisive and willing to say no when necessary.

Reviewing and Updating the Product Strategy

A product strategy is not static and must be regularly reviewed and adjusted to remain valid in a changing environment. This ensures the strategy stays relevant and continues to guide the product effectively.

Importance of Review: Regularly assessing the strategy prevents blindly executing an outdated plan that no longer reflects market realities or product performance.
Key Review Factors: Consider product performance (measured by KPIs), competitor actions, relevant trends (technology, regulatory), and changes in company goals and capabilities.
Frequency of Review: The review frequency depends on product maturity and market volatility, ranging from monthly (for young products in dynamic markets) to quarterly or every three to six months (for mature products in stable markets).
Stakeholder Involvement: Include key stakeholders in strategy reviews to keep them informed, leverage their insights, and maintain buy-in.
Strategy and Execution Link: Issues in executing the product roadmap can signal that the strategy may no longer be valid, highlighting the interconnectedness of strategy and execution.
Potential Outcomes: Reviews can lead to smaller strategy adjustments or more drastic changes like pivoting or discontinuing the product.

Strategy Development: Crafting a Winning Strategy

This chapter focuses on practical techniques for developing a product strategy, including identifying the target audience, defining the product’s value, and differentiating it in the market.

Segmenting the Market

Segmenting the market involves dividing potential customers and users into distinct, homogenous groups to create a focused product with a compelling value proposition.

Purpose of Segmentation: It allows for focused product development, avoiding the attempt to please everyone and potentially satisfying no one.
Clear-Cut and Homogenous Segments: Segments should be clearly defined, with individuals within a segment responding similarly to the product.
Segmentation Approaches: Market segmentation can be based on customer properties (demographics, psychographics, behavior, geography, industry, company size) or the benefits the product provides (needs, problems solved).
Choosing the Right Approach: For adjacent and disruptive innovations, prioritize benefit-based segmentation; for core innovations, customer properties are often more appropriate.
Avoiding Mistakes: Do not blindly follow predefined segments or discard ideas just because they don’t fit existing categories.

Picking the Right Segment

Once market segments are identified, it’s crucial to select the most promising ones to target, as attempting to serve too many segments simultaneously can be overwhelming.

Evaluation Criteria: Assess segments based on their attractiveness and the business’s strength or ability to serve them.
GE/McKinsey Matrix: This tool helps visualize and compare segments based on attractiveness (need strength, size, growth, competition, entry barriers) and business strength (skills, resources, cost of acquisition, channels).
Qualitative Assessment: For new or disruptive products, a qualitative assessment is often sufficient initially, as precise data may not be available.
Iterative Testing: If the initial segment chosen turns out to be less promising upon validation, select and test the next segment.
Avoiding Over-Segmentation: Do not pick too many segments to target, as this can dilute focus and complicate product development.

Using Personas to Describe the Customers and Users

Personas are fictional characters that represent the target customers and users, helping product teams understand their needs, behaviors, and goals to build a product that creates real value.

Fictional Representation: Personas typically include a name, picture, relevant characteristics, behaviors, attitudes, and a primary goal.
Goal-Oriented: Focusing on the persona’s goal (problem to solve, benefit to gain) helps ensure the product addresses real user needs.
Based on Research: Persona descriptions should be grounded in knowledge gained from direct interaction with the target audience (observation, interviews), not speculation.
Distinguishing Types: Differentiate between customer/buyer personas (focused on purchase decisions) and user personas (focused on product interaction and use).
Primary Persona: Select one primary persona as the main focus for development to create a cohesive user experience.
Visualization: Making personas visible to the development team helps maintain a user-centric mindset and avoids focusing solely on solutions.
Simple Template: A concise persona template capturing picture, name, details, and goal is recommended for clarity and ease of use.

Finding an Itch That’s Worth Scratching

A successful product must solve a problem people deeply care about or provide a benefit they truly value and wouldn’t want to live without. The “itch” must be significant enough to motivate adoption.

Problem vs. Benefit: Products can be “painkillers” (solving urgent problems) or “vitamins” (providing desirable benefits), but both must offer tangible value.
Tangible Benefit: The value created by the product must be greater than the cost and effort required to obtain and use it.
Identifying Strong Needs: The core problem or benefit must be meaningful to the target audience, addressing a real pain point or providing a significant gain.
Beyond Existing Awareness: Users may not be fully aware of the “itch” until they experience a better way to address it (like the convenience of Sonos).
Reducing Barriers: High purchase or usage barriers can hinder adoption even if the underlying need is strong.
Focus on Value Creation: The primary focus should be on creating value for customers and users, as this is the foundation for business success.

Clearly Stating the Value Your Product Creates

Precisely articulating the value proposition—what success looks like for the customers and users when they use the product—is essential for guiding development, design, marketing, and sales.

Beyond Vague Statements: Avoid generic claims like “entertaining users” and instead describe the specific experience or outcome desired by the target audience.
Customer/User Success: Define what “doing a great job” means from the perspective of the people who will buy and use the product.
Guiding Design and Features: A clear value proposition helps determine the right user experience, functionality, and design elements needed to deliver that value.
Informing Marketing and Sales: A well-defined value proposition provides the core message for communicating the product’s benefits to the market.
Identifying the Primary Benefit: If the product offers multiple benefits, pinpoint the most important one to maintain focus and facilitate decision-making.
Prioritizing User Needs: When faced with conflicting customer and user needs, prioritizing user needs often leads to a more successful product in the long run.

Making Your Product Stand Out

In a competitive landscape, products need clear differentiators to convince people to choose them over alternatives. Understanding the competition and identifying unique value is key.

Understanding the Competitive Landscape: Identify direct and indirect competitors and the factors they compete on.
Strategy Canvas: This tool helps visualize the competitive landscape by plotting competitors and your product against key industry factors (e.g., price, features, design).
Industry Value Curve: Represents how competitors currently perform across the key factors.
Your Product’s Value Curve: Shows how your product scores against the same factors.
Differentiation is Key: A product stands out when its value curve significantly diverges from the industry standard.
Achieving Differentiation: This involves strategically eliminating, reducing, raising, and creating key factors to move into a “blue market” or non-competitive space.
Kano Model: This model categorizes features as basics (must-haves), performers (linear satisfaction increase), and delighters (excite customers), emphasizing the need for delighters to differentiate.
Evolution of Features: Features that are delighters today tend to become performers and eventually basics over time, requiring continuous innovation to maintain differentiation.

Eliminating Features

Counterintuitively, removing or reducing features can be a powerful strategy to simplify a product, clarify its value proposition, improve the user experience, and reduce development costs, rather than just adding more functionality.

Avoiding Feature Creep: Products can become overly complex and expensive to maintain by constantly adding features without considering their overall impact.
Eliminate-Reduce-Raise-Create Grid: This tool, related to the Strategy Canvas, explicitly encourages identifying features to eliminate or reduce.
Focus on Value: Eliminate features that do not provide significant value to the target audience or do not align with the core value proposition.
Simplifying the Product: Removing features can lead to a cleaner, easier-to-use product with a clearer value proposition.
Reducing Development Costs: Fewer features mean less to build and maintain, freeing up resources for more impactful work.
Making New Features Stand Out: Removing non-essential features can highlight and emphasize the truly valuable and differentiating features.
Courage is Required: Eliminating features can be difficult, especially when facing stakeholder pressure, but it is often necessary for a focused and successful product.

Offering a Great Customer Experience

Beyond the core product features, the entire customer journey—from discovering and purchasing to using and getting support—significantly impacts satisfaction and adoption. A seamless and positive experience can be a key differentiator.

Beyond Product Features: Focus should extend to all touch points customers have with the product and the company.
Removing Barriers: Identify and eliminate any friction points that make it difficult to evaluate, purchase, install, use, update, or get help with the product.
Differentiating Factor: A superior customer experience can distinguish a product even if its core features are similar to competitors.
Consumption Map: This tool helps visualize the customer journey, identifying touch points and opportunities for improvement at each stage.
Analyzing Each Touch Point: Evaluate how customers interact with the product at each step, identifying pain points, delays, and areas of dissatisfaction.
Creating an Enhanced Journey: Design improvements to add value and enhance the experience at every touch point, making it easy and enjoyable for customers.
Relevant Across Stages: Focusing on customer experience is crucial throughout the product life cycle, particularly to reach the mainstream market.

Building Variants and Unbundling Your Product

Creating product variants or unbundling features into separate products are strategies to address the needs of diverse or growing audiences, increase business benefits, and enhance competitiveness.

Product Variant: A specialization of an existing product, often targeted at a specific segment or offered at different price points (e.g., free vs. premium versions).
Unbundling: Taking a feature or set of features from a larger product and releasing it as a standalone product.
Benefits: These techniques can enable sustained growth, allow for better serving of specific segments, open new revenue streams, and improve competitiveness.
Addressing Diverse Needs: Variants and unbundling allow for tailoring products to the specific requirements of different user groups.
Opening New Markets: A variant or unbundled product might appeal to a market segment not served by the original product.
Revenue Generation: Different variants or standalone products can offer new monetization opportunities.
Drawbacks: Risks include overwhelming customers with too many choices, cannibalizing existing products, and requiring portfolio management and potentially developing shared assets or platforms.

(Re-) Positioning Your Product

Product positioning involves defining how a product is perceived in the market relative to its competitors, often linked to its brand. Repositioning may be necessary to target new markets, extend the product life cycle, or respond to competitive changes.

Importance of Brand: A strong brand clarifies what the product stands for and builds customer loyalty and preference.
Alignment with Strategy: Product strategy and brand should be closely aligned to communicate a consistent message.
Subbranding: Companies may use subbrands for individual products to differentiate them while leveraging the main company brand (e.g., Google Search).
Creating New Brands: If a product doesn’t fit the company’s existing brand associations, creating a new brand may be necessary (e.g., Lexus for Toyota).
Repositioning/Rebranding: Changing the perception or brand of a product to make it attractive to new segments or revitalize it.
Responding to Market Changes: Repositioning can be a strategic response to shifting market trends or competitive actions.
Beyond Features: Positioning focuses on the perceived value and identity of the product in the minds of the target audience.

Strategy Validation: Testing and Refining Your Strategy

This chapter provides essential techniques for validating the assumptions and risks inherent in a product strategy, ensuring it is grounded in reality and increasing the likelihood of success.

Iteratively Testing and Correcting Your Strategy

Validating a product strategy is an iterative process of identifying risks, testing assumptions, collecting feedback, and using insights to refine the strategy or pivot.

Risk-Driven Approach: Start by identifying the biggest risk or “leap-of-faith” assumption in the strategy that could lead to failure if incorrect.
Test and Learn: Determine the best way to address the risk (e.g., observation, interviews, MVPs), collect relevant data, and analyze the results.
Pivot, Persevere, or Stop: Based on the learning, decide whether to significantly change the strategy (pivot), stick with it while making adjustments (persevere), or abandon the vision entirely (stop).
Iterative Cycle: Repeat the process of identifying the next biggest risk, testing, and deciding until the strategy is validated or resources are exhausted.
Reducing Uncertainty: Each iteration should reduce uncertainty and refine the strategy based on empirical evidence.
Avoiding Late Failure: Addressing major risks early minimizes the chance of building a product that nobody wants after significant investment.

Determining the Necessary Validation Effort

The amount of validation required depends directly on the level of uncertainty and risk associated with the product’s innovation type.

Core Innovations: Low risk, requiring little to no validation effort (hours or days).
Adjacent Innovations: Medium risk, requiring a medium validation effort (weeks).
Disruptive Innovations: High risk, requiring a high validation effort (months), as the market and value proposition are largely unproven.
Innovation Ambition Matrix: The Innovation Ambition Matrix helps estimate the necessary validation effort based on whether the innovation is core, adjacent, or disruptive.
Flexibility is Key: These are guidelines, and the actual effort may vary; be prepared to adjust the validation process based on emerging risks and learnings.
Investing Wisely: Allocate validation resources proportional to the inherent risk of the innovation.

Involving the Right People

Successful strategy validation is a collaborative effort that benefits from the diverse perspectives and expertise of key stakeholders, forming a “product discovery team.”

Collaborative Effort: The product manager should not attempt to validate the strategy alone.
Key Stakeholders (Players): Include members from the development team (UX, programming, testing), marketing, sales, support, legal, finance, HR, and a ScrumMaster/coach.
Product Discovery Team: For adjacent and disruptive innovations, a dedicated, collocated team with members from development and business functions is highly recommended.
Diverse Skills: Ensure the team has the necessary skills to assess technical feasibility, identify business risks, and conduct research.
Shared Ownership and Buy-in: Collaborative validation fosters a sense of shared responsibility and increases stakeholder support for the resulting strategy.
Mitigating Bias: Working with a diverse group helps balance individual opinions and cognitive biases, leading to more objective analysis of feedback and data.
Leadership Role: The product manager leads the validation effort, facilitating collaboration while making decisive calls when needed.

Using Data to Make Decisions

Grounded decisions about the product strategy should be based on feedback, data, and empirical evidence rather than solely on intuition, opinions, or beliefs.

Empirical Evidence: Collect data from testing assumptions and engaging with target customers and users.
Balancing Intuition and Data: While intuition sparks ideas, data provides a basis for validating them and making informed choices.
Avoiding the HiPPO Effect: Data empowers product managers to argue against the opinions of powerful stakeholders by providing objective evidence.
Mitigating Cognitive Biases: Be aware of biases like confirmation bias and self-serving bias that can distort data collection and interpretation; collaborating with others helps counterbalance these.
Data Analysis: Analyze collected data to understand what it reveals about the validity of strategic assumptions.
Evidence-Based Strategy: The goal is to build a strategy that is supported by evidence from market interaction and testing.

Turning Failure into Opportunity

Embracing failure as a necessary part of the innovation process is crucial for learning and discovering successful product strategies, especially for adjacent and disruptive innovations.

Uncertainty Requires Learning: High-risk innovations inherently involve unknowns, requiring experimentation and accepting that not all ideas will succeed.
Failure as Learning: Mistakes and failures are valuable if they lead to new insights, invalidate incorrect assumptions, or reveal better approaches.
Fail Early: Aim to test risky assumptions quickly and cheaply to fail early, when the impact and cost are lower, and there are more options for correction.
Fail-Safe Environment: Create an organizational culture where experimentation and learning from failure are encouraged and not penalized, particularly for innovation teams.
Incubators: A temporary, autonomous business unit can provide a fail-safe environment and the freedom to innovate, especially for disruptive products.
Alternatives to Incubators: Approaches like Google’s 20% time or hackathons can also support experimentation and learning.
Challenge Your Ideas: Actively seek out negative feedback and try to invalidate assumptions to ensure honest learning.

Getting Out of the Building

Directly interacting with target customers and users in their natural environment is a fundamental practice for gaining authentic insights into their needs and behaviors.

Direct Observation: Visit target customers and users to observe how they currently perform relevant tasks and understand their context.
Authentic Insights: Learning directly from users provides a deeper understanding than relying solely on second-hand information or internal assumptions.
Beyond Analytics: While analytics provide quantitative data, direct interaction reveals the why behind user behavior and challenges.
Observing in the Wild: See how products might be used in real-world settings like public transport, homes, or workplaces.
Regular Practice: Aim for regular interactions with customers and users, such as at least once per quarter, even for existing products.
Open Mindset: Approach interactions with an open mind, prepared to observe, listen, and learn without preconceived notions.
Ease of Recruitment: Recruiting test groups can be relatively easy through targeted outreach.

Identifying the Biggest Risk

Before testing, pinpoint the most critical uncertainty in the product strategy—the “leap of faith” assumption that, if incorrect, would most severely jeopardize the product’s success.

Focus on High-Impact Uncertainty: Identify statements in the strategy that are both uncertain and could cause significant negative consequences if wrong.
Areas of Risk: Risks can relate to the market and needs (Is there a real need? Is the segment right?), features and technologies (Is the product feasible? Will it stand out?), or business goals (Is it economically viable? Will the business model work?).
Prioritize Market and Needs Risks: Address risks related to market and needs first, as having no market or a weak value proposition makes other factors irrelevant.
One Risk at a Time: Focus on addressing the most crucial risk to maintain focus and facilitate effective data collection and analysis.
The Red Dot Game: A simple technique to collaboratively identify the biggest risk by having stakeholders place dots next to the assumptions they are most concerned about.
Define Success Criteria: Before testing, determine how you will know if you have successfully addressed the risk and gained sufficient confidence.

Choosing the Right Validation Techniques

Select the most appropriate methods for testing specific risks and gathering the necessary feedback or data. Different techniques are suited for different types of assumptions.

Matching Technique to Risk: Choose validation techniques based on the specific risk you are trying to address (e.g., problem interviews for needs, MVPs for demand).
Qualitative and Quantitative: Combine qualitative methods (observation, interviews) for understanding why with quantitative methods (MVPs, analytics) for scale and statistical significance.
Efficiency: If multiple techniques could address a risk, choose the quickest and cheapest option.
Separating Collection and Analysis: Avoid drawing conclusions while still collecting data to prevent bias.
Examples of Techniques: Includes direct observation, problem interviews, Minimum Viable Products (MVPs), and spikes (for technical feasibility).

Directly Observing Customers and Users

Observing how target customers and users perform relevant tasks provides valuable insights into their behaviors, pain points, and needs, helping validate assumptions about the target group and the problem the product solves.

Watching Users in Action: Observe users in their natural environment as they engage in activities related to the product’s intended use.
Identifying Pain Points: Observing reveals frustrations and challenges that users might not articulate in interviews.
Understanding Context: See the environment and circumstances in which the product will be used.
Validating Target Group: Confirms whether the chosen segment actually experiences the assumed needs or problems.
Beyond Usage Data: Provides the “why” behind quantitative usage metrics.
Patient and Non-Intrusive: Observe discreetly to avoid influencing user behavior.
Open-Minded: Approach observation without preconceived notions to see clearly.

Carrying Out Problem Interviews

Structured conversations with target users and customers help delve deeper into their experiences, challenges, and current ways of addressing their needs, validating assumptions about the problem and its significance.

Understanding Current Behavior: Ask about how they currently perform relevant activities, what works well, and what doesn’t.
Discovering Pain Points: Elicit specific frustrations or difficulties they encounter.
Validating Problem Significance: Determine how important the problem is to them and if they are actively looking for a solution.
Avoiding Solution Bias: Do not mention your product during problem interviews; focus solely on understanding their current situation and needs.
Carefully Crafted Questions: Prepare open-ended, non-leading questions to encourage honest responses.
Active Listening: Listen attentively and ask clarifying questions to fully understand their perspective.
Concise Interviews: Keep interviews relatively short (e.g., 15 minutes) to increase participation rates.

Creating Minimum Viable Products

A Minimum Viable Product (MVP) is the smallest possible product version used to learn how target users interact with the product and validate key assumptions about its value proposition and functionality.

Learning Focus: The primary purpose of an MVP is to gather validated learning about user behavior and market demand.
Minimal Functionality: It includes just enough features to test a key assumption or demonstrate the core value proposition.
Different Forms: MVPs can take various forms, including videos, landing pages, fake doors, concierge services, or early software builds.
Testing Assumptions: MVPs help validate assumptions about demand, user engagement, feature desirability, pricing, and marketing channels.
Early Feedback: Releasing an MVP provides early feedback from real users, enabling quick iteration and adjustments.
Building the Right Thing: Learning from MVPs helps ensure that subsequent development efforts are focused on features and experiences that users actually value.

Building Spikes to Assess Technical Feasibility

A spike is a short, timeboxed technical investigation or throwaway prototype used to address specific technical risks or uncertainties related to developing the product.

Addressing Technical Risk: Spikes help determine if a proposed technology is feasible, how difficult it will be to implement, and what resources are needed.
Evaluating Technologies: Can be used to assess new programming languages, frameworks, databases, or third-party services.
Understanding Effort: Provides a rough indication of the development effort required for certain technical components or approaches.
Informing Feasibility: Helps determine if the product can be built within a realistic timeframe and budget.
Avoiding Big Up-Front Design: Focuses on specific risks rather than attempting a complete technical design early on.
Preparing for Development: Spikes can help the development team prepare for implementing certain parts of the product.

Pivot, Persevere, or Stop

Based on the learning and data gathered from strategy validation efforts, the product manager and team must decide whether to significantly change the strategy (pivot), continue with the current strategy while making adjustments (persevere), or discontinue the product or vision altogether (stop).

Analyzing Learning: Review and analyze the feedback and data to determine if the current strategy is valid and working.
Identifying Invalidity: If the data indicates that the core assumptions are wrong and the strategy is unlikely to succeed, a change is needed.
Pivoting: A significant change in strategy while staying true to the original vision; examples include changing the target segment, value proposition, or business model.
Persevering: Continue with the current strategy, making incremental adjustments and improvements based on the learning.
Stopping: Abandoning the product or vision if no valid strategy can be found or if it is no longer beneficial to pursue.
Fail Fast: Aim to identify the need for a pivot or stop early, when the cost of changing direction or discontinuing is lower.
Avoiding Repeated Pivots: If constant pivots are required, it may indicate that the vision is unattainable or unclear.

Using Agile Techniques to Manage the Validation Work

Agile practices like timeboxing, using a Kanban board, and holding regular review meetings can effectively manage the iterative process of validating the product strategy.

Timeboxing: Set fixed periods (e.g., 4 weeks) for validation efforts to create focus and make progress transparent. At the end of a timebox, decide whether to continue, pivot, or stop.
Kanban Board: Visualize and track the validation tasks (identifying risks, planning tests, executing research, analyzing data) on a simple board with columns like “Input,” “To-Do,” “In Progress,” and “Done.”
Visualizing Progress: The Kanban board makes the validation work and its progress transparent to the team and stakeholders.
Facilitating Collaboration: Supports collaboration and self-organization among the validation team.
Regular Review Meetings: Hold frequent meetings (e.g., weekly) with the validation team and management sponsor to review progress, discuss risks, and identify necessary adjustments.
Data-Driven Discussions: Use the review meetings to discuss the learning and data collected during the validation period.
Connecting Strategy and Tactics: Integrate strategy review into existing agile ceremonies like the sprint review meeting if using Scrum.

Part 2: Product Roadmap

This section focuses on the product roadmap, a crucial tool for translating the product strategy into an actionable plan and communicating the product’s likely evolution to stakeholders.

Roadmap Foundations: Understanding and Using Product Roadmaps

This chapter lays the groundwork for effective product roadmapping, explaining its purpose, different formats, how to choose the right approach, who benefits, and how to avoid common pitfalls.

Why You Need a Product Roadmap

A product roadmap details the planned journey of a product, showing how the strategy will be executed through a series of major releases over time. It bridges the gap between the high-level strategy and the detailed product backlog.

Translating Strategy into Action: The roadmap outlines the concrete steps to implement the product strategy.
Communicating Future Evolution: It shows how the product is likely to grow and develop over time.
Aligning Stakeholders: The roadmap provides a shared understanding of the product’s direction for everyone involved.
Continuity of Purpose: It connects individual releases to a larger vision and strategy.
Guiding Prioritization: Helps in prioritizing work by showing how it fits into the overall plan.
Beyond the Product Backlog: The product backlog is too detailed for a long-term view; the roadmap provides the necessary high-level perspective.

Being Clear on the Different Types and Formats of Product Roadmaps

Product roadmaps can vary in what they emphasize and how they are presented, with key distinctions between feature-based and goal-oriented roadmaps, and internal versus external audiences.

Feature-Based Roadmaps: Focus on listing specific product features and mapping them to a timeline, often driven by feature delivery.
Goal-Oriented Roadmaps: Emphasize the goals or benefits each release aims to achieve, viewing features as supporting elements to reach those goals.
Internal Roadmaps: Used within the company to align stakeholders and guide internal planning for marketing, sales, support, and development.
External Roadmaps: Shared with customers and users, often used for marketing, sales, and demonstrating product commitment, and may omit specific dates to manage expectations.
Formats: Roadmaps can be tables, visual representations like storyboards, or simple spreadsheets.
Choosing a Tool: Start with simple tools like spreadsheets or paper before investing in commercial roadmapping software.
Avoiding Tool-Driven Roadmapping: The tool should support the roadmapping approach, not dictate it.

Choosing the Right Roadmapping Approach

The best approach to roadmapping depends on the level of uncertainty and change present, which is influenced by the product’s maturity and the market’s stability.

Matching to Uncertainty: Similar to planning a trip, more uncertainty requires a higher-level plan, while greater certainty allows for more detail.
Product Maturity and Market Stability: These two factors determine the appropriate roadmap format, planning horizon, and review frequency.
Young Product, Dynamic Market: Recommend a high-level, goal-oriented roadmap with a short horizon (e.g., 6 months) and frequent reviews (e.g., monthly).
Mature Product, Stable Market: A more detailed, feature-based roadmap with a longer horizon and less frequent reviews (e.g., quarterly or semi-annually) may be suitable.
Mature Product, Dynamic Market or Young Product, Stable Market: A goal-oriented roadmap with more features, a longer horizon, and quarterly reviews is often appropriate.
Roadmap Evolution: The roadmapping approach should evolve as the product and market change, potentially shifting between goal-oriented and feature-based.
Trust and Transparency: A roadmap that changes too frequently due to over-specification or unrealistic planning loses stakeholder trust.

Understanding Who Benefits from Your Roadmap

The product roadmap serves as a central communication tool that benefits various internal stakeholders by providing them with the necessary information to plan and coordinate their work effectively.

Aligning Stakeholders: The primary benefit is creating a shared understanding of the product’s future among different departments.
Guiding Departmental Planning: Marketing needs to plan campaigns, sales needs to prepare channels, support needs to anticipate new features, and development needs to allocate resources, all based on the roadmap.
Different Stakeholder Needs: Different groups have varying expectations from the roadmap, requiring a format and level of detail that addresses their specific needs.
Management Sponsorship: The roadmap helps secure management buy-in and resources by demonstrating the product’s planned contribution to business goals.
Development Team Direction: Provides the development team with a view of what’s coming, influencing their technical and design decisions.
Customer and User Influence: External roadmaps can allow customers to anticipate upcoming features and influence the product’s direction.

Involving the Stakeholders

Collaborative roadmapping with key stakeholders is essential for generating strong buy-in, leveraging diverse knowledge, and ensuring the roadmap is realistic and actionable.

Shared Ownership: Involving stakeholders in creating and reviewing the roadmap fosters a sense of shared responsibility and commitment.
Leveraging Expertise: Tap into the knowledge of different departments (e.g., sales insights, technical feasibility from development).
Building Consensus: Collaborative workshops help stakeholders hear each other’s perspectives and work towards a shared understanding and agreement.
Ensuring Feasibility: Input from development, marketing, and other teams helps identify potential constraints and ensure the plan is realistic.
Leading the Process: The product manager leads the collaborative effort, guiding discussions and making decisions when necessary to ensure the roadmap aligns with the strategy.
Regular Engagement: Ongoing involvement in roadmap reviews and updates maintains alignment and buy-in over time.

Getting the Relationship between the Roadmap and the Product Backlog Right

The product roadmap and the product backlog are distinct but complementary tools. The roadmap provides the strategic, high-level view, while the backlog contains the tactical details for implementation. Maintaining a clear separation is crucial.

Roadmap is Strategic, Backlog is Tactical: The roadmap outlines the overall journey and major releases; the backlog lists specific items (epics, user stories, requirements) needed for development.
Avoiding Overlap: Do not include detailed epics or user stories in the product roadmap; this clutters the roadmap and blurs the distinction between the two tools.
Roadmap Informs Backlog: The roadmap provides the direction and context for prioritizing and detailing items in the product backlog.
Backlog Informs Roadmap: Feedback and progress from developing items in the backlog can lead to adjustments in the roadmap.
Focusing the Backlog: It is often beneficial to focus the product backlog primarily on the items for the next one or two releases outlined in the roadmap.
Keeping Them in Sync: Regularly update both the roadmap and the backlog to reflect changes and maintain alignment.

Avoiding These Common Roadmapping Mistakes

Common errors in roadmapping can undermine its effectiveness. Being aware of these pitfalls helps product managers create more useful and reliable roadmaps.

Treating the Roadmap as a Guarantee: A roadmap is a plan based on current knowledge and is subject to change; it should not be presented as a fixed, immutable commitment.
Speculating Without Strategy: Do not create a roadmap if a valid product strategy is not yet in place; the roadmap implements the strategy, it doesn’t replace it.
Including Too Much Detail: Avoid cluttering the roadmap with low-level items like epics and user stories; keep it high-level and focused on releases, goals, and key features.
Ignoring Stakeholder Buy-in: A roadmap is useless if the key stakeholders don’t understand, agree with, or support it.
Not Reviewing and Updating: A static roadmap quickly becomes outdated and loses its value as a planning tool.
Lack of Focus: A roadmap should tell a coherent story about the product’s evolution, not be a random collection of features or requests.
Mismanaging Expectations: Be careful about promising specific features or dates, especially on external roadmaps, if there is significant uncertainty.

Roadmap Development: Crafting an Actionable Plan

This chapter provides practical techniques for building a realistic and actionable product roadmap, covering aspects like defining measurable goals, identifying release contents, estimating effort, and managing dependencies.

Making Your Product Roadmap SMART

A product roadmap is most effective when its releases are Specific, Measurable, Agreed, Realistic, and Time-bound. Applying the SMART criteria ensures the roadmap is clear, trackable, and supported by stakeholders.

Specific: Releases should be clearly defined, with a shared understanding of what they entail and why they are being developed.
Measurable: It should be possible to determine if a release has achieved its intended goals or benefits using defined metrics.
Agreed: The roadmap should have the buy-in and support of the key stakeholders involved in making the product successful.
Realistic: The plan should be feasible, considering the available resources, skills, and any dependencies.
Time-Bound: Each release should have a defined date or time frame for when it is expected to be available.

Taking Advantage of Release Goals

In a goal-oriented roadmap, each release is defined by a specific goal or benefit it aims to achieve, providing the rationale for the release and helping prioritize the work within it.

Focus on Benefits: Goals shift the focus from simply delivering features to achieving desired outcomes for users and the business.
Rationale for Releases: Goals explain why a particular release is important and worthwhile.
Prioritization Aid: Goals help in deciding which features or activities are most important to include in a release.
More Stable than Features: Goals tend to be more stable than specific features, making the roadmap more resilient to change.
Facilitates Collaboration: Shared goals align teams and stakeholders around a common objective.
Measurable Objectives: Goals should be measurable, with clear metrics to track their attainment.

Capturing Your Roadmap with the GO Template

The GO Product Roadmap template is a goal-oriented format designed to clearly communicate the product’s planned evolution by focusing on dates, release names, goals, key features, and metrics.

Structured Format: Organizes roadmap information into clear columns and rows.
Key Elements: Includes Date/Time Frame, Release Name, Goal (most important), Key Features (supporting the goal), and Metrics (to measure goal attainment).
Goal-First Approach: Emphasizes defining the goals before listing the supporting features.
High-Level Features: Encourages capturing features as capabilities rather than detailed user stories to maintain a strategic view.
Measurability: Explicitly includes a section for metrics to ensure goals are quantifiable.
Flexibility: Can be adapted by adding or removing columns to suit specific needs.
Visual and Collaborative: The template can be used on paper or in simple electronic formats to facilitate collaborative planning and visibility.

Determining the Right Release Contents

Defining the content of each release involves grouping features and activities in a way that tells a coherent story about the product’s growth and effectively implements the product strategy.

Coherent Releases: Each release should represent a meaningful step forward, building upon previous releases and moving the product closer to the vision.
Implementing Strategy: Release contents should directly support the goals outlined in the product strategy.
Leveraging Validation Insights: Learning from strategy validation helps inform the specific features and activities needed in early releases, particularly for new products.
Using KPIs for Existing Products: For mature products, analyze KPIs to identify areas for improvement and define releases that address those areas (e.g., a release focused on improving engagement).
Architecture Refactoring: Plan releases dedicated to improving the product’s technical health and maintainability if needed.
Combining Features: Group related features into releases to create well-rounded increments that deliver tangible value.

Getting the Features on Your Roadmap Right

While the focus is on goals, features are still important as the deliverables that enable goal attainment. Defining them at the appropriate level of detail is crucial for a useful roadmap.

High-Level Capabilities: Features on the roadmap should represent product capabilities or themes rather than detailed user stories.
Supporting the Goal: Features should be derived from and directly support the achievement of the release goals.
Limited Number: Aim for a small number of key features per release (e.g., no more than five) to maintain focus and clarity.
Cost-Benefit Analysis: Evaluate the potential impact and required effort of features to decide whether to include them, particularly for feature-based roadmaps.
Avoiding “Feature Soup”: Do not simply add requested features without considering how they contribute to the overall product direction and goals.
Informing Stakeholders: If a requested feature is not on the roadmap, explain the strategic reasons why and how it might be considered in the future.

Identifying the Success Factors

Understanding which aspects of a release are most critical—delivering specific content, hitting a deadline, or staying within budget—helps prioritize and make trade-offs when challenges arise. This is known as identifying the primary success factor.

Primary Success Factor: The single most important criterion for a release’s success (content, date, or budget). If this factor is not met, the impact on product success is the worst.
Impact Analysis: Determine which failure scenario (releasing late, missing content, exceeding budget) would have the most negative impact on the product’s performance.
Protecting the Primary Factor: Prioritize and allocate resources to ensure the primary success factor is met, even if it requires flexing other factors.
The Iron Triangle: Illustrates that content (or goal), time, and budget are interconnected; changing one usually affects the others. Quality should be fixed and not sacrificed.
Flexing Other Factors: To protect the primary factor, you must be willing to relax at least one of the other factors.
Secondary Success Factor: The second most important criterion, used to make trade-offs when the primary factor is secure.
Consistency or Variation: Success factors can be consistent across releases or vary depending on the release’s purpose and context.

Determining the Window of Opportunity

Instead of solely estimating how long development will take, identify the time frame when a release must be available to achieve its desired benefits and capitalize on market conditions. This time frame is the window of opportunity.

Market-Driven Dates: Focus on when the market needs the product or release to be available, not just when it can technically be finished.
Leveraging Market Dynamics: Consider the pace of market change, competitor actions, and customer needs to identify timely release windows.
New vs. Existing Products: The window of opportunity is particularly important for new products or significant updates in dynamic markets.
Speed to Market: Releasing a good-enough product within the window can be more beneficial than delaying for a perfect product.
Informing Estimates: The window of opportunity provides a target date that helps determine the scope and resources needed for the release.
Validation Insights: Learning from strategy validation informs the assessment of market dynamics and the viability of potential release windows.

Taking Dependencies into Account

Product roadmaps are often constrained by dependencies on other releases, people, or other products. Identifying and managing these dependencies is essential for creating a realistic and executable plan.

Between Releases: Ensure that releases are sequenced logically, considering technical dependencies (e.g., refactoring needed before new features) or user journey dependencies.
On People: Account for the availability of key individuals with specific skills needed for a release (e.g., a UX expert, a specific developer).
On Other Products: Recognize dependencies on other products within the company, such as shared components, platforms, or products that integrate with yours.
Managing Dependencies: Address dependencies by adjusting the roadmap, acquiring necessary resources, changing team structures, or reworking product architecture (e.g., unbundling, creating platforms).
Conway’s Law: Be aware that organizational structure can influence product architecture and dependencies; optimizing teams (e.g., cross-functional feature teams) can reduce dependencies.
Aim for Loose Coupling: Strive to minimize dependencies between products and teams to enable faster development and greater flexibility.

Making Your Roadmap Measurable

Ensuring that release goals are measurable allows you to track progress, determine if the desired benefits have been achieved, and understand if the product strategy is being effectively implemented.

Quantifiable Goals: Goals should be specific enough to be measured, stating target outcomes (e.g., “acquire X% more users,” “reduce technical debt by Y%”).
Defining Metrics: Select specific metrics that will be used to determine whether a goal has been met (e.g., number of new registrations, code complexity score).
Linking Metrics to Goals: Ensure the chosen metrics directly measure the attainment of the release goal, not just related activities.
Setting Realistic Targets: Define targets that are challenging but achievable based on available data and insights.
Time Frame for Measurement: Specify when the metrics will be evaluated to determine goal attainment (e.g., within two weeks after release).
Transparency: Include the metrics in the roadmap itself to make goal measurement clear to all stakeholders.

Roadmap Changes: Adapting to Evolution

This chapter addresses the dynamic nature of product roadmaps, emphasizing the importance of regularly tracking progress, reviewing performance, and adjusting the roadmap based on new information and changing circumstances.

Tracking the Progress

Regularly monitoring the progress of development and execution against the product roadmap is essential for identifying potential delays or issues and determining if adjustments are needed.

Monitoring Execution: Track whether releases are on track to be delivered on time, within budget, and with the intended content or goal.
Release Burndown Chart: A tool (often used in Scrum) to visualize the remaining effort needed for a release over time, helping to forecast completion and identify deviations from the plan.
Cumulative Flow Diagram: A tool (often used in Kanban) to visualize the flow of work, helping to identify bottlenecks and predict delivery.
Early Warning Signals: Tracking progress helps identify potential problems early, allowing for timely corrective actions.
Root-Cause Analysis: If progress is not as expected, investigate the underlying reasons (e.g., unrealistic goals, insufficient resources, unexpected technical challenges).
Informing Adjustments: The data from progress tracking directly informs decisions about whether and how to adjust the product roadmap.

Reviewing and Changing the Roadmap

Regularly reviewing and updating the product roadmap is crucial to ensure its continued relevance and effectiveness in guiding the product’s evolution in response to new information and changing circumstances.

Maintaining Relevance: Periodic reviews prevent the roadmap from becoming outdated and losing its value as a planning tool.
Frequency Based on Context: The review frequency should align with product maturity and market stability, ranging from monthly to less frequent.
Stakeholder Involvement: Include key stakeholders in roadmap review meetings to ensure alignment, gather feedback, and secure buy-in for any changes.
Review Factors: Consider changes in the product strategy, the actual development progress (vs. planned), and the data collected from customers and users.
Data-Driven Adjustments: Use empirical evidence and feedback from users and the market to inform decisions about adjusting goals, features, or timelines.
Connecting Strategy and Execution: Roadmap reviews provide an opportunity to assess whether the current execution is effectively implementing the product strategy.
Incremental vs. Radical Change: Reviews can lead to minor refinements or necessitate more significant changes, including revisiting the product strategy or pivoting.

Portfolio Roadmaps: Managing Multiple Products

This chapter provides a brief introduction to portfolio roadmaps, which are used to manage a group of related products, coordinating their development and identifying dependencies.

Why You Should Use a Portfolio Roadmap

When multiple products are related and potentially share resources, dependencies, or target markets, a portfolio roadmap provides a consolidated view to facilitate coordination and strategic alignment across the product family.

Managing Related Products: A portfolio roadmap is useful for products that are part of a suite, a family, or that share underlying platforms or technologies.
Coordination and Alignment: It helps coordinate development, release schedules, and marketing efforts across multiple products.
Identifying Dependencies: Provides a clear overview of dependencies between products, such as shared components, integrations, or launch dependencies.
Resource Allocation: Can help in allocating resources effectively across the product portfolio.
Strategic View of the Portfolio: Shows how individual products contribute to the overall portfolio strategy and the company’s broader objectives.

Planning Your Portfolio with the GO Portfolio Roadmap

The GO Portfolio Roadmap template extends the goal-oriented approach to managing multiple related products, combining individual product roadmaps into a single view.

Consolidated View: Displays the roadmaps of several products within a portfolio in one place.
Goal-Oriented: Focuses on the goals and benefits of each release for each product within the portfolio.
Includes Key Information: For each product and release, it shows the date/time frame, name, goal, key features, and metrics.
Identifying Cross-Product Relationships: The consolidated view makes it easier to spot dependencies, overlaps, and opportunities for collaboration between products.
Scalability: Can include multiple products and portfolios as needed.
Basis for Coordination: Provides a framework for product managers to coordinate their plans and address inter-product dependencies.

Addressing These Portfolio Challenges

Managing a portfolio of products introduces complexities beyond managing individual products, requiring additional coordination and potentially a dedicated portfolio manager.

Increased Complexity: Coordinating multiple product roadmaps is more complex than managing a single one.
Need for Coordination: Product managers of related products must collaborate to create and update the portfolio roadmap.
Portfolio Manager Role: For larger portfolios, a dedicated portfolio manager can lead the portfolio roadmapping effort, resolve inter-product dependencies, and prioritize across products.
Dependency Resolution: Portfolio roadmapping highlights dependencies, requiring strategies to manage or break them (e.g., creating shared platforms).
Prioritization Across Products: Decisions may be needed to prioritize resources or releases across different products in the portfolio.
Prerequisite: It is recommended to establish solid individual product roadmapping practices before attempting to implement portfolio roadmaps.

Epilogue

Developing successful products in the digital age requires more than just tactical execution; it necessitates making sound strategic decisions and effectively translating them into actionable plans.

Beyond Tactics: Product success hinges on proactive strategic thinking and decision-making.
Importance of Product Management Function: An effective product management function, with empowered and skilled product people, is crucial for driving product strategy and success.
Proactive Leadership: Product managers must be willing to lead, influence stakeholders, and make decisions, even without explicit authorization if necessary to ensure product success.
Putting Theory into Practice: The concepts and techniques discussed in the book require implementation and adaptation to real-world contexts.
Learning and Iteration: Mastering product strategy and roadmapping is a journey that involves learning, experimenting, and refining approaches over time.

About the Author

Roman Pichler is a product management consultant, teacher, and author known for his expertise in agile product management.