Strategize: Product Strategy and Product Roadmap Practices for the Digital Age
.jpg)
Authors: Roman Pichler Tags: product management, strategy, agile, innovation, technology Publication Year: 2016
Overview
In my work with product managers, product owners, and entrepreneurs, I’ve seen a common struggle: getting so caught up in the day-to-day tactics of building a product—writing user stories, dealing with sales requests, managing the backlog—that the bigger picture gets lost. We end up perfectly executing the wrong plan. I wrote ‘Strategize’ to help you avoid this trap. My book provides a proactive, systematic approach to making the right strategic decisions and then translating them into an actionable plan. It is intended for anyone in charge of a product’s success, regardless of your specific job title. The core argument is the crucial distinction between [[product strategy]] and the [[product roadmap]]. They are not the same thing. Your strategy is your high-level plan for achieving your vision—it defines who your customers are, what problem you’re solving for them, what makes your product unique, and what your business goals are. Your roadmap, in turn, shows how you will execute that strategy over time. The book is structured in two parts to reflect this. Part 1, ‘Product Strategy,’ gives you the foundational concepts and tools to create and validate a winning strategy. We explore how to align with business goals, understand your innovation type, use the product life cycle, and capture your thinking with my Product Vision Board. Part 2, ‘Product Roadmap,’ focuses on execution. I provide practical guidance on creating an actionable, goal-oriented roadmap that aligns stakeholders and guides the development team. I introduce my GO Product Roadmap template as a concrete tool to focus on goals over features, ensuring your plan remains strategic and adaptable. This book is a practical guide, filled with tools and techniques to help you navigate the complexities of product management in the digital age and build products that succeed.
Book Distillation
1. Part 1: Product Strategy - Strategy Foundations
Product success begins with a clear hierarchy: Vision, Strategy, and Tactics. The Vision is your ultimate purpose, the positive change your product should bring. The Strategy is the path to realizing that vision, a high-level plan defining your target market and their needs, the product’s key features and differentiators, and your business goals. Tactics are the product backlog details—the epics and user stories—that execute the strategy. Your product strategy must be guided by the overall business strategy and informed by your specific [[innovation strategy]]—whether it’s a Core, Adjacent, or Disruptive innovation, as each type carries different levels of risk and requires different approaches. The [[product life cycle model]] (Development, Introduction, Growth, Maturity, Decline) is a vital sense-making tool to understand your product’s current stage and make the right strategic moves to maximize its success. All of these strategic elements can be captured, communicated, and tested using the Product Vision Board.
Key Quote/Concept:
[[The Product Vision Board]]. This is a simple yet powerful tool I designed to capture your product strategy in one place. It consists of five sections: Vision (the overarching goal), Target Group (the market and users), Needs (the problem you solve), Product (what it is and what makes it special), and Business Goals (how it benefits the company). It facilitates a shared understanding and serves as a foundation for strategic conversations and validation.
2. Part 1: Product Strategy - Strategy Development
Developing a winning strategy involves making specific, deliberate choices. For new and innovative products, market segmentation should be benefit-first, not based on traditional demographics, to uncover new opportunities. Use personas to create a deep, shared understanding of your customers and users, focusing on their goals. You must find a real ‘itch that’s worth scratching’—a significant problem or a compelling benefit—and clearly articulate your product’s value proposition. To stand out, you must differentiate. The Strategy Canvas helps you map your value curve against the competition and find a ‘blue ocean’ by eliminating, reducing, raising, and creating competing factors. This often means having the courage to eliminate features, not just add them. A great [[customer experience]] across all touchpoints is a powerful differentiator. As products grow, you may need to unbundle features into new products or create product variants to serve diverse segments and sustain growth.
Key Quote/Concept:
[[The Eliminate-Reduce-Raise-Create Grid]]. This is a framework used with the Strategy Canvas to challenge industry norms and create a unique value proposition. Instead of just trying to match competitors, you strategically ask: Which factors can we ELIMINATE that the industry takes for granted? Which can be REDUCED well below the industry standard? Which should be RAISED well above? And which new factors can be CREATED that the industry has never offered? This drives true differentiation.
3. Part 1: Product Strategy - Strategy Validation
Your initial strategy is a set of hypotheses that must be tested. Validation is an iterative loop: identify your biggest risk, choose the right technique to test it (e.g., customer interviews, observation, MVPs, spikes), collect data, and analyze the results. Based on what you learn, you must decide whether to pivot (change strategy), persevere (continue with adjustments), or stop. This is not a solo activity; it requires a collaborative [[product discovery team]] composed of product, design, engineering, and key business stakeholders. Decisions must be based on data and evidence, not on the highest-paid person’s opinion (HiPPO). To do this effectively, especially for adjacent and disruptive innovations, you need a fail-safe environment like an incubator where experimentation and learning from failure are encouraged. The goal is to fail fast and early to avoid costly late-stage failures.
Key Quote/Concept:
[[Pivot, Persevere, or Stop]]. This is the critical decision point in the strategy validation loop. After running an experiment to test a key assumption, you analyze the feedback. If the data validates your direction, you PERSEVERE, continuing on the path while making small adjustments. If the data invalidates a core hypothesis, you PIVOT, making a significant change to your strategy while keeping the vision intact. If you cannot find a valid strategy for your vision, you must have the discipline to STOP.
4. Part 2: Product Roadmap - Roadmap Foundations
A product roadmap translates your strategy into an actionable plan, communicating how the product will likely evolve over several major releases. It is a strategic, high-level tool, distinct from the tactical, detailed product backlog. Roadmaps can be feature-based, but [[goal-oriented roadmaps]] are more effective, especially for products in dynamic environments. The right roadmapping approach—its level of detail, time horizon, and review frequency—depends on your product’s maturity and market stability. The roadmap is a critical alignment tool for all stakeholders (management, development, marketing, sales), so creating it collaboratively in a workshop is essential to gain buy-in and ensure feasibility. Avoid common mistakes like treating the roadmap as a fixed guarantee, creating it without a validated strategy, or cluttering it with low-level details like user stories.
Key Quote/Concept:
[[Goal-Oriented vs. Feature-Based Roadmaps]]. A feature-based roadmap is a list of features plotted on a timeline. It’s prone to change and often leads to debates about individual features. A goal-oriented roadmap, which I advocate, focuses on objectives for each release, such as ‘Acquire 1,000 new users’ or ‘Improve user retention by 15%.’ Features are then derived from these goals. This approach creates a more stable, strategic, and collaborative planning tool.
5. Part 2: Product Roadmap - Roadmap Development
An effective roadmap is SMART: Specific, Measurable, Agreed, Realistic, and Time-bound. My GO Product Roadmap template is designed to achieve this by structuring each release around a goal. The releases on your roadmap should tell a coherent story, with each one acting as a stepping-stone that implements the product strategy and moves you closer to your vision. To determine the right contents, use your KPIs to identify areas for improvement. For each release, you must also identify the primary success factor—the most critical dimension among the goal/features, date, and budget. The [[Iron Triangle]] illustrates that you cannot fix all three; one must be flexible. Protecting your primary success factor (e.g., hitting a launch date) means being willing to flex the others (e.g., reducing scope or increasing budget).
Key Quote/Concept:
[[The GO Product Roadmap Template]]. This is my practical tool for building a goal-oriented roadmap. It consists of five key elements for each release: 1. Date/Timeframe, 2. Name, 3. Goal (the ‘why’), 4. Features (the high-level ‘what’), and 5. Metrics (how you’ll measure success). This structure forces clarity on the purpose and desired outcome of each release, shifting the focus from outputs (features) to outcomes (goals).
6. Part 2: Product Roadmap - Roadmap Changes
A product roadmap is a living document, not a static plan. It must be reviewed and updated regularly to remain relevant and useful. The appropriate review frequency depends on your product’s maturity and market dynamism—ranging from monthly for young products to every 3-6 months for mature ones. The review process should be collaborative, involving the key stakeholders who helped create the roadmap. There are three key inputs to consider during a review: changes to the product strategy, the actual progress of development and other teams (tracked with tools like release burndown charts), and new data from customers and users. This ensures your roadmap remains a realistic and actionable plan that reflects new information and learning.
Key Quote/Concept:
[[Roadmap Review Factors]]. A systematic roadmap review should be based on three key factors. 1) Product Strategy Changes: Has our underlying strategy shifted? 2) Work Progress: Are we on track to deliver what we planned? 3) Customer and User Data: What have we learned from recent releases and user feedback? Analyzing these factors ensures that roadmap adjustments are thoughtful and comprehensive, not reactive.
7. Part 2: Product Roadmap - Portfolio Roadmaps
Products often exist as part of a larger portfolio or product family. In such cases, a [[portfolio roadmap]] is necessary to show how the different products will evolve together. This plan helps coordinate development and launch activities, and it makes dependencies between products visible and manageable. You can use an extended version of the GO Roadmap template to capture the goals, features, and metrics for each product in the portfolio on a single, unified timeline. Managing a portfolio introduces new challenges and often requires a dedicated portfolio manager role to facilitate cross-product planning, resolve conflicts, and ensure the entire product line moves forward cohesively.
Key Quote/Concept:
[[The GO Portfolio Roadmap]]. This tool extends the goal-oriented approach to manage a group of related products. It combines the individual roadmaps of products like ‘Product A’ and ‘Product B’ into a single view, aligning their release timelines, goals, and features. This makes it easier to spot and manage dependencies, coordinate marketing and sales efforts, and ensure the product family strategy is coherent.
Generated using Google GenAI
Essential Questions
1. What is the fundamental distinction I make between product strategy and a product roadmap, and why is this separation crucial for success?
In my experience, many teams conflate strategy and planning, leading them to execute the wrong plan perfectly. The core argument of ‘Strategize’ is the critical separation between [[product strategy]] and the [[product roadmap]]. Your product strategy is your high-level plan for realizing your vision. It answers the ‘why’ and the ‘who’: who are the customers, what problem are we solving for them, what makes our product unique, and what are our business goals? I designed my Product Vision Board to capture these elements. The product roadmap, conversely, is the ‘how’ and ‘when’. It’s an execution plan that translates the strategy into actionable steps, showing how the product will evolve over time through major releases. This distinction is vital because it forces you to validate your core assumptions (the strategy) before committing to a detailed execution plan (the roadmap). Without a validated strategy, your roadmap becomes a speculative wish list, prone to constant change and stakeholder friction. By separating them, you can have strategic conversations focused on value and validation, and then create a more stable, goal-oriented roadmap that guides development effectively.
2. How do I advocate for validating a product strategy, and what is the role of the ‘Pivot, Persevere, or Stop’ decision point?
A product strategy should never be treated as a static document; it is a set of testable hypotheses. The biggest risk in product development is building something nobody wants. Therefore, I dedicate a significant portion of the book to [[strategy validation]]. The process is an iterative loop: identify your biggest risk (using techniques like the Red Dot Game), design an experiment to test it (from customer interviews to MVPs), collect data, and analyze the results. This is not a one-person job but a collaborative effort for a [[product discovery team]]. Based on the evidence you gather, you face a critical decision: PERSEVERE if the data supports your direction, making minor adjustments; PIVOT if a core hypothesis is invalidated, requiring a significant change in strategy while keeping the vision intact; or STOP if you cannot find a viable path to your vision. This disciplined, evidence-based approach helps you fail fast and cheap, turning potential failures into learning opportunities. It systematically de-risks your strategy, ensuring that by the time you invest heavily in development, you are building on a validated foundation.
3. Why do I champion goal-oriented roadmaps over feature-based ones, and how does my GO Product Roadmap template facilitate this approach?
A common pitfall I see is the feature-based roadmap, which is essentially a list of features on a timeline. This approach invites debates over individual features, is brittle and prone to change, and often loses sight of the actual value being delivered. To counter this, I advocate for [[goal-oriented roadmaps]]. Instead of focusing on outputs (features), they focus on outcomes (goals). A release goal might be ‘Acquire 1,000 new users’ or ‘Reduce churn by 15%’. This shifts the conversation from ‘What are we building?’ to ‘What are we trying to achieve?’. To make this practical, I created the [[GO Product Roadmap Template]]. It structures each release around five key elements: Date/Timeframe, Name, Goal, Features, and Metrics. The ‘Goal’ is the centerpiece, defining the ‘why’ of the release. The ‘Features’ are then derived from that goal, and the ‘Metrics’ make the goal measurable. This structure forces strategic clarity, provides stability (goals change less often than feature ideas), and empowers the development team to find the best solutions to achieve the stated objective, fostering true collaboration and alignment.
Key Takeaways
1. Strategy is a Hierarchy: Vision > Strategy > Tactics
One of the most fundamental concepts I stress is the clear hierarchy of planning. At the top is the Vision, the ultimate purpose and the positive change your product should bring. The Product Strategy is the path to that vision—a high-level plan defining the market, needs, key differentiators, and business goals. Finally, Tactics are the details in the product backlog, like epics and user stories, that execute the strategy. Getting this hierarchy right is essential. Teams that jump straight to tactics without a clear strategy often build features that don’t serve a larger purpose, leading to a disjointed product and wasted effort. My book emphasizes that the strategy must be validated and shared before the roadmap is detailed, and the roadmap must guide the creation of the backlog. This top-down guidance, coupled with bottom-up feedback from tactical execution, creates a cohesive and adaptive product development process.
Practical Application: For an AI product engineer, this means before you start designing a new algorithm or feature, you should be able to connect it upwards. Ask: ‘Which goal on the [[goal-oriented roadmaps|goal-oriented roadmap]] does this support?’ and ‘How does that goal, in turn, serve our overall [[product strategy]]?’ For instance, if you’re asked to build a new recommendation model, you should understand if the strategic goal is to increase user engagement, drive sales of a specific product category, or something else. This context allows you to make better technical trade-offs and even propose alternative solutions that might achieve the strategic goal more effectively.
2. Your Innovation Type Dictates Your Approach
Not all product work is the same, and your approach must adapt accordingly. I use the Innovation Ambition Matrix to distinguish between three types of innovation. [[Core innovations]] optimize existing products for existing markets; they are low-risk and require a focus on operational excellence. [[Adjacent innovations]] leverage existing strengths into new areas (a new product for an existing market, or vice-versa); they carry moderate risk and require more discovery and validation. [[Disruptive innovations]] create new products for new markets; they are high-risk and require an entrepreneurial mindset, a fail-safe environment like an incubator, and significant validation effort. Understanding which type of innovation you’re working on is crucial for setting expectations, allocating resources, and choosing the right validation techniques. You cannot apply a core innovation process to a disruptive idea and expect success; it will be crushed by demands for reliable forecasts and risk avoidance.
Practical Application: An AI product engineer working on a [[core innovation]] (e.g., improving the accuracy of an existing fraud detection model by 2%) will focus on optimization and reliability. In contrast, an engineer on a [[disruptive innovation]] (e.g., using a novel generative AI to create a new category of design tools) must embrace uncertainty. Your work will involve more spikes, building MVPs to test fundamental value propositions, and accepting that the initial strategy will likely [[Pivot, Persevere, or Stop|pivot]]. You must be comfortable with ambiguity and focus on learning velocity over feature velocity.
3. Stakeholder Management is Collaborative Leadership, Not Order-Taking
A product manager’s role is not to be a go-between or to simply placate stakeholders. True success comes from collaborative leadership. I provide tools like the Power-Interest Grid to help you analyze your stakeholders and determine how to engage them effectively. The ‘players’ (high power, high interest) should be your close collaborators in strategy and roadmap workshops. This collaborative creation process is key to generating buy-in and ensuring your plans are feasible. However, collaboration requires leadership. You must guide the process, facilitate difficult conversations, and have the courage to say ‘no’ to requests that don’t align with the validated strategy. A roadmap should not be a weak compromise or a ‘camel designed by committee.’ It must be a coherent, strategic plan. This means using data and the product strategy as your shield and guide, ensuring decisions are made for the good of the product, not just to satisfy the most powerful person in the room.
Practical Application: When an AI product engineer is in a roadmap planning session, and a sales leader (‘player’) demands a specific feature for a single large client, your response shouldn’t be a simple ‘yes’ or ‘no’. Instead, you lead the conversation back to strategy: ‘How does this feature align with our Q3 goal of increasing user retention across the entire user base? Let’s look at the data. Perhaps there’s a more generalized solution that meets this client’s need while also serving our strategic goal.’ This reframes the discussion from a feature request to a collaborative problem-solving exercise grounded in the agreed-upon strategy.
Suggested Deep Dive
Chapter: Part 1, Chapter: Strategy Validation
Reason: For an AI product engineer, the concepts in this chapter are paramount. AI products, especially those using novel techniques, are rife with uncertainty regarding value, usability, and feasibility. This chapter provides a systematic framework for de-risking these assumptions before significant engineering resources are spent. Understanding how to identify the biggest risk, choose the right validation technique (from problem interviews to MVPs and spikes), and make the ‘Pivot, Persevere, or Stop’ decision is a critical skill. It moves the engineer from being a pure builder to a strategic partner who can help steer the product toward genuine product-market fit, preventing the creation of technologically impressive but commercially unviable products.
Key Vignette
Deconstructing the First iPhone’s ‘Blue Ocean’ Strategy
To illustrate how to create a product that stands out, I analyze the launch of the first iPhone using the Strategy Canvas and the Eliminate-Reduce-Raise-Create Grid. Apple didn’t just try to out-compete Nokia and BlackBerry on existing factors. Instead, it fundamentally redefined the smartphone market by making strategic trade-offs. It ELIMINATED the physical keyboard and stylus, REDUCED the emphasis on voice quality and complex e-mail integration, RAISED the mobile internet experience and media player capabilities, and CREATED two entirely new factors: a revolutionary multi-touch screen and a stylish, minimalist design. This created a ‘blue ocean’ where the iPhone initially had no direct competitors, making the existing industry value curve irrelevant.
Memorable Quotes
Doing the right thing is more important than doing the thing right.
— Page 12, Part 1: Product Strategy
A camel is a horse designed by committee.
— Page 48, Strategy Foundations
Innovation is not about saying yes to everything. It’s about saying no to all but the most crucial features.
— Page 68, Strategy Development
Markets that don’t exist can’t be analyzed.
— Page 57, Strategy Development
However beautiful the strategy, you should occasionally look at the results.
— Page 49, Strategy Foundations
Comparative Analysis
My book, ‘Strategize’, sits within a canon of modern product management literature, but it aims to fill a specific, practical gap. It shares a philosophical foundation with Eric Ries’s ‘The Lean Startup’, particularly in its emphasis on iterative validation and the ‘pivot or persevere’ mindset. I explicitly build on Ries’s ideas by providing a structured process for applying them to strategy. While Marty Cagan’s ‘Inspired’ offers a powerful vision for how great product teams should operate and what their culture should be, ‘Strategize’ provides the specific, tangible tools—like my [[Product Vision Board]] and [[GO Product Roadmap Template]]—to implement that vision. Cagan tells you what a great team does; I provide the canvases and templates for how they can do it. Furthermore, my work directly engages with concepts from Geoffrey Moore’s ‘Crossing the Chasm’, integrating the product life cycle and the challenge of moving from early adopters to the mainstream market directly into the strategic planning and roadmapping process. The unique contribution of ‘Strategize’ is its clear, two-part structure that first builds a validated strategy and then translates it into an actionable, goal-oriented roadmap. It is less about abstract principles and more of a hands-on manual for the person in charge of the product.
Reflection
As the author, my goal with ‘Strategize’ was to provide a clear, actionable toolkit to demystify product strategy. The book’s strength lies in its structured approach and practical templates, which give product people a concrete way to move from reactive backlog grooming to proactive strategic leadership. The clear distinction between strategy and roadmap, and the emphasis on goal-oriented planning, are designed to elevate the product role. However, I am aware of the potential gap between my frameworks and the messy reality of many organizations. A skeptical reader might argue that these tools are only effective in an environment where product managers are already empowered, trusted, and given autonomy—a cultural state many companies have not achieved. The book advocates for this empowerment, but it cannot create it. My opinion is that by using these tools to facilitate collaborative workshops and ground decisions in data, a product manager can start to build that trust and earn that autonomy. The frameworks are not just for planning; they are tools for organizational change. The book’s weakness, if any, is that it may understate the political skill and sheer persistence required to implement this methodical approach in a culture that defaults to top-down directives or sales-led feature lists. The ultimate significance of ‘Strategize’ is to serve as both a guide and a manifesto: a guide for how to do the work, and a manifesto for the strategic, leadership-oriented role product managers should play.
Flashcards
Card 1
Front: What are the three core elements of a [[product strategy]] as defined in ‘Strategize’?
Back:
- Market and Needs: The target customers/users and the problem you solve for them. 2. Key Features and Differentiators: The crucial aspects that create value and make the product stand out. 3. Business Goals: How the product benefits the company (e.g., generates revenue, reduces cost).
Card 2
Front: What is the purpose of the [[Product Vision Board]]?
Back: It is a tool to describe, communicate, test, and refine the product strategy. It captures the Vision, Target Group, Needs, Product, and Business Goals on a single canvas to create a shared understanding.
Card 3
Front: What is the difference between a Core, Adjacent, and Disruptive innovation?
Back: Core: Optimizing an existing product for an existing market (low risk). Adjacent: Entering a new market with an existing product, or a new product for an existing market (medium risk). Disruptive: Creating a new product for a new market (high risk).
Card 4
Front: What is the key difference between a feature-based roadmap and a [[goal-oriented roadmaps|goal-oriented roadmap]]?
Back: A feature-based roadmap lists features on a timeline (focus on output). A goal-oriented roadmap focuses on objectives for each release, like ‘Acquire new users’ (focus on outcome), with features derived from those goals.
Card 5
Front: What are the three possible outcomes of a [[strategy validation]] cycle?
Back:
- Persevere: The data validates the strategy, so you continue with minor adjustments. 2. Pivot: The data invalidates a core hypothesis, so you make a major change to the strategy. 3. Stop: A valid strategy cannot be found for the vision, so you cease work.
Card 6
Front: What are the five elements of the [[GO Product Roadmap Template]]?
Back:
- Date/Timeframe. 2. Name (of the release). 3. Goal (the ‘why’). 4. Features (high-level capabilities). 5. Metrics (to measure goal attainment).
Card 7
Front: What are the four stakeholder groups in the Power-Interest Grid?
Back:
- Players (High Power, High Interest): Collaborate with them. 2. Context Setters (High Power, Low Interest): Consult them. 3. Subjects (Low Power, High Interest): Involve them. 4. Crowd (Low Power, Low Interest): Inform them.
Generated using Google GenAI