Review

The book serves as a solid introduction to product roadmaps for novice product managers (who I find are often overly focused on templates and structure). It provides a foundational understanding of roadmaps and their purpose. More seasoned product managers may find it falls short in addressing the nuanced challenges they face, such as aligning and coordinating roadmaps across multiple teams with varying styles and approaches.

You Might Also Like:

Book Summary: Continuous Discovery Habits by Teresa Torres

Get a comprehensive summary of the best-selling book "Continuous Discovery Habits" by Teresa Torres, the founder of ProductTalk. Learn about Teresa's practical framework for continuously improving your product strategy and staying ahead of the competition.

andrewclark.co.uk

Lean UX

Even though it seems positioned more toward designers, this is an incredibly important book for product managers. It does a great job of integrating the concepts from Lean Startup with existing methodologies (Design Thinking, Agile, UX design). It’s packed full of principles and practical implementation advice for teams. There’s little in this book I disagree with.

andrewclark.co.uk

Book Review and Summary: Strategize by Roman Pichler

Get a comprehensive review and summary of the best-selling book "Strategize" by Roman Pichler, the product management and strategy expert. Learn about the key principles and practices for developing and executing effective product strategies.

andrewclark.co.uk

Key Takeaways

The 20% that gave me 80% of the value.

Relaunching Roadmaps

• A product roadmap shows everyone how you intend to achieve your product vision .
• A roadmap is a communication tool, a statement of intent and direction. A good roadmap inspires buy-in, by focusing on the value you propose to deliver to your customer and your organisation.
• The actual artefact isn’t what’s important, it’s value comes from creating the shared understanding of where you’re going and why.
• Don’t think of roadmaps as fixed project plans (even through traditional roadmaps were).

• Put the organisations plans in strategic context → tie the roadmap to a compelling vision of the future. Start with the mission, vision and strategic intent / context, and then clearly link everything to it.
• Focus on delivery value to customers and the organisation → Describe chunks of value you intend to deliver. Use high level customer needs or themes. Leave room for autonomy but have clear guardrails and success criteria.
• Embrace learning as part of product development → Commit to outcomes not outputs.
• Rally the organisation around a single set of priorities → Involve people in the decisions that will affect them. Share your thinking early, before everything is concrete.
• Get customers excited about the product’s direction.
• Let the teams determine the solutions, and allow them to solve the problem.
• Commit to outcomes rather than outputs → make sure the roadmap isn’t conflated with a release plan or project plan.

A roadmap needs to tell the story of what it will be like when you achieve your vision, what it will take to get there, and how you will know if you are making progress.

Primary Components:

• Product Vision → How a customer benefits from your product when it is realised and ubiquitous.
• Business Objectives → Goals or outcomes your product will accomplish. What will be measurably different.
• Timeframes → Use broad timeframes like quarters or provide guidance but leave some wiggle room.
• Themes →What would need to be true for our product to realise its vision and attain its business objectives. Express themes as customer needs or problems to guide development.
• Disclaimer → make it subject to change without notice.

Secondary Components:

• Features and solutions → show how you intend to deliver on your themes.
• Confidence → the level of confidence you have in your ability to address each theme.
• Stage of development → e.g. discovery, pre-production, beta etc.
• Target customers → specific segment if appropriate.
• Product areas → if product is large or segmented.

Gathering Inputs

Before you make your roadmap, you’ll need to spend some time gathering inputs to make sure you have all the information and context you need to make good product decisions.

• Product Lifecycle Stages: New, Growth, Expansion, Harvesting, End of Life
• Market Inputs: problem & solution, value proposition, unfair advantage, key metrics customer segments, distribution channels, costs, revenue models, key partners, key resources.
• Don’t just focus on the problem, but on the outcome you’re trying to achieve by solving it. The problem → the solution → the expected outcome.
• 4 Steps to the Epiphany: customer discovery → customer validation → customer creation → company building.
• Gather input from customers: Customer roles. User types (end user, admin, manager). Differentiate between users and buyers.
• Roles help us categorise the different customers. While personas help us empathise.
• Gather stakeholder input. Identify all your stakeholders how they benefit and how they contribute.

Establishing the Why with Product Vision and Strategy

• A mission defines your intent and clarifies your intentions. Four elements:
• Value: What value does your mission bring to the world
• Inspiration: How does your mission inspire your team to make the vision a reality
• Plausibility: Is your mission realistic and achievable?
• Specificity: is your mission specific to your business, industry or sector?
• A vision is the outcome that you seek. It’s why your organisation exists, and it can be decomposed into the benefits you hope to create through your efforts for others and your organisation. It should include:
• your target customer
• the benefits (or needs) you’ll address
• what makes it unique

• Pair down that information into the format: A world where the [target customer] no longer suffers from [the identified problem] because of [product] they [benefit].
• The Product Strategy is how you achieve your mission. Its the bridge that connects your high-level vision to the specifics of your roadmap. Use the product strategy as the starting place for your roadmap.
• Objectives and Key Results: identifying business objectives that tie to your vision is critical. You need specific objectives to hit on the way to your vision. You have to narrow down how you’re going to get there. OKRs are a great way to pair your business objectives with success criteria.
• Objectives are for qualitative goals
• Key Results for each objective are quantitative
• Guidelines: Everything on the roadmap should be tied to at least one objective. Stick to a manageable number of objectives. Focus on outcomes, not output.
• Your roadmap should focus on outcomes over outputs.
• Loose timeframes like ‘Now, Next, Later’ can work. More uncertainty in further timezones is expected and encouraged.

Uncovering Customer Needs Through Themes

• Roadmap items should be derived from a job the customer needs to accomplish or a problem they must solve to avoid building things customers don’t need.
• Understand and organise user needs early in the process.
• Uncover a ‘job to be done’ that is frustrating enough for a customer to seek out and hire a solution.
• Separate your roadmap from your release plan:
• Roadmap: a high-level view of user needs (or problems) you should solve. It’s the why. It’s about what you should solve for.
• Release plan: details how you will solve them. It’s the how you’ll solve it. The solutions.
• Themes are buckets that define what’s important to your customers at the present time.
• Advantages of organising by themes:
• Easier to say no to solutions that don’t meet customer needs
• Can shift focus from what competitors are doing to what customers need
• Creates a cleaner narrative for marketing
• Clearly defined need makes solutions development easier
• Team have more freedom and flexibility to explore solutions that work
• Makes roadmaps easier to read, as there are less needs than solutions
• Problems and needs are consistent, the viability of features/solutions is more variable
• Themes are about outcomes not outputs. If you find yourself listing deliverables ask why. Why are they important? What will result from doing them?
• Every step should be incremental and build on the one before:
• Vision: the change you want to see in the world
• Objectives: the goals you want to accomplish in the next version of the product
• Themes: the customer needs or problems that you’re addressing
• Every theme should related directly to an objective.

Deepening your roadmap

• Secondary components help you provide more context and spend less time explaining your roadmap. Balance having too much information with too little.

Achieving Alignment and Buy-in:

• No plan survives contact with your stakeholders.
• Your plan will only work if you can get people to believe in it.
• Shuttle diplomacy can help coordinate stakeholders to reach an agreement. Meet with each party individually first for decisions require compromise and trade-offs. Politics are much more manageable in one-on-one settings
• For each stakeholder, understand:
• Goals: what are they trying to achieve in the next X months?
• Reality: what’s on their plate now? what’s recent?
• Options: what do they think will help them achieve those goals?
• Way forward: which of the options helps them achieve the goals they described earlier in the conversation?
• Only after you’ve done shuttle diplomacy should you bring everyone together.

Presenting and Sharing your roadmap

• Co-creation and sharing early and often can help with the IKEA effect and radically increase buy-in.
• Roadmaps need to be tailored to the audience, but from a common foundation.
• Development teams: Features and solutions, Stage of development, Product Areas, Scalability, Technology & Infrastructure, Dependencies and risks
• Sales and marketing might need: Features and solutions, Target customers, Confidence, External drivers (events, times of year etc)
• Executives: Market opportunity, profit and loss
• Customers: Features and timeframes

Keeping it Fresh

• When conditions in the environment change, your roadmap must change in order to survive.
• Revise roadmaps on a regular cycle to reflect market changes and shifts in strategy, but allow execution to proceed steadily between updates.
• How stable your environment is should determine how how far out your roadmap should go.
• How to deal with special requests:
• What problem is this request trying to solve?
• Does solving that need align with our objectives?
• Is it more important than what’s on the roadmap now?
• Forks in the road: if there’s a decision that could completely change the nature of the strategy or the roadmap then call it out and shot it as a fork in the road.

Deep Summary

Longer form notes, typically condensed, reworded and de-duplicated.

Relaunching Roadmaps

• A product roadmap shows everyone how you intend to achieve your product vision .
• A roadmap is a communication tool, a statement of intent and direction. A good roadmap inspires buy-in, by focusing on the value you propose to deliver to your customer and your organisation.
• The actual artefact isn’t what’s important, it’s creating the shared understanding of where you’re going and why.
• Don’t think of roadmaps as fixed project plans (even through traditional roadmaps were).
• Traditionally roadmaps were used to keep stakeholders informed of when major hardware upgrades were coming so they could plan months ahead. BUT that doesn’t work for today’s fast paced and outcome-driven product development processes.

• Put the organisations plans in strategic context → tie the roadmap to a compelling vision of the future. Start with the mission, vision and strategic intent / context, and then clearly link everything to it.
• Focus on delivery value to customers and the organisation → Describe chunks of value you intend to deliver. Use high level customer needs or themes. Leave room for autonomy but have clear guardrails and success criteria.
• Embrace learning as part of product development → Commit to outcomes not outputs. Ask why that feature is important? Ask why that date is important? Especially for those things that are further out.
• Rally the organisation around a single set of priorities → Involve people in the decisions that will affect them. Share your thinking early, before everything is concrete. Form a stakeholder advisory group with cross-functional representation.
• Get customers excited about the product’s direction → Start a dialog with customers, treat roadmap conversations with customers as an opportunity to validate your understanding of the market. If you miss the mark, that’s OK it’s the reason for the conversation.
• Prioritisation is critical to deliver on commitments → Don’t over promise. If you constantly miss you likely have an estimation and/or a prioritisation problem.
• Let the teams determine the solutions, and allow them to solve the problem. Roadmaps shouldn’t require wasteful up-front design and estimation.
• Commit to outcomes rather than outputs → make sure the roadmap isn’t conflated with a release plan or project plan.

Components of a Roadmap

A document that can effectively rally your troops around a plan needs to be more than just a list of features and dates.

It needs to tell the story of what it will be like when you achieve your vision, what it will take to get there, and how you will know if you are making progress.

Primary Components:

• Product Vision → How a customer benefits from your product when it is realised and ubiquitous.
• Business Objectives → Goals or outcomes your product will accomplish. What will be measurably different.
• Timeframes → Use broad timeframes like quarters or provide guidance but leave some wiggle room.
• Themes →What would need to be true for our product to realise its vision and attain its business objectives. Express themes as customer needs or problems to guide development.
• Disclaimer → make it subject to change without notice.

Secondary Components:

• Features and solutions → show how you intend to deliver on your themes.
• Confidence → the level of confidence you have in your ability to address each theme.
• Stage of development → e.g. discovery, pre-production, beta etc.
• Target customers → specific segment if appropriate.
• Product areas → if product is large or segmented.

Complementary Information: project information, platform considerations, financial information or external drivers.

Gathering Inputs

Before you make your roadmap, you’ll need to spend some time gathering inputs to make sure you have all the information and context you need to make good product decisions.

• Product Lifecycle Stages: New, Growth, Expansion, Harvesting, End of Life
• Market Inputs: problem & solution, value proposition, unfair advantage, key metrics customer segments, distribution channels, costs, revenue models, key partners, key resources.
• Don’t just focus on the problem, but on the outcome you’re trying to achieve by solving it. The problem → the solution → the expected outcome.
• 4 Steps to the Epiphany: customer discovery → customer validation → customer creation → company building.
• Gather input from customers: Customer roles. User types (end user, admin, manager). Differentiate between users and buyers.
• Roles help us categorise the different customers. While personas help us empathise.
• Gather stakeholder input. Identify all your stakeholders how they benefit and how they contribute.

Establishing the Why with Product Vision and Strategy

A vision should be about having an impact on the lives of the people your product serves.

• A mission defines your intent and clarifies your intentions. Four elements:
• Value: What value does your mission bring to the world
• Inspiration: How does your mission inspire your team to make the vision a reality
• Plausibility: Is your mission realistic and achievable?
• Specificity: is your mission specific to your business, industry or sector?
• A vision is the outcome that you seek. It’s why your organisation exists, and it can be decomposed into the benefits you hope to create through your efforts for both the world and your organisation. It should include:
• your target customer
• the benefits (or needs) you’ll address
• what makes it unique
• Values are beliefs and ideas. They are intended to guide behaviours, think of them as your compass.
• To create a vision, start with Geoffrey Moore’s value proposition template:
• For {Target customer}
• Who {target customer needs}
• The {product name}
• Is a {product category}
• That {product benefit / reason to buy}
• Unlike {competitors}
• Our product {differentiation}
• Pair down that information into the format: A world where the [target customer] no longer suffers from [the identified problem] because of [product] they [benefit].
• The Product Strategy is how you achieve your mission. Its the bridge that connects your high-level vision to the specifics of your roadmap. Use the product strategy as the starting place for your roadmap.
• Objectives and Key Results: identifying business objectives that tie to your vision is critical. You need specific objectives to hit on the way to your vision. You have to narrow down how you’re going to get there. OKRs are a great way to pair your business objectives with success criteria.
• Objectives are for qualitative goals
• Key Results for each objective are quantitative
• Guidelines: Everything on the roadmap should be tied to at least one objective. Stick to a manageable number of objectives. Focus on outcomes, not output.
• The 10 universal business objectives:
• Sustainable value:
• Support the product’s core value
• Create barriers to competition
• Growth:
• Grow market share
• Fulfill more demand
• Develpo new markets
• Improve recurring revenue
• Profit:
• Support higher prices
• Improve lifetime value
• Lower costs
• Leverage existing assets
• Outcome Based Roadmap

• Your roadmap should focus on outcomes over outputs. If not you risk becoming a feature factory, and losing sight of why you’re building features and if they’re actually achieving what you imagined.
• Loose timeframes like ‘Now, Next, Later’ can work. More uncertainty in further timezones is expected and encouraged.

Uncovering Customer Needs Through Themes

• Roadmap items should be derived from a job the customer needs to accomplish or a problem they must solve. Themes are customer needs not features.
• Every decision about your product should rooted in customer need, so you avoid building things customers don’t need.
• You need to uncover a customer ‘job to be done’ that is frustrating enough for a customer to seek out and hire a solution.
• You need to extract all of the precise problems or needs that must be addressed in order for your product to add value to the customer.
• A need is something the customer doesn’t have yet. A problem is something that’s not working right.
• Understand and organise user needs early in the process.
• Separate your roadmap from your release plan:
• Roadmap: a high-level view of user needs (or problems) you should solve. It’s the why. It’s about what you should solve for.
• Release plan: details how you will solve them. It’s the how you’ll solve it. The solutions.
• Themes: buckets that define what’s important to your customers at the present time.
• Sub-themes: more specific need.
• Advantages of organising by themes:
• Easier to say no to solutions that don’t meet customer needs
• Can shift focus from what competitors are doing to what customers need
• Creates a cleaner narrative for marketing
• Clearly defined need makes solutions development easier
• Team have more freedom and flexibility to explore solutions that work
• Makes roadmaps easier to read, as there are less needs than solutions
• Problems and needs are consistent, the viability of features/solutions is more variable
• Ways to uncover themes and sub-themes
• User Journey Maps: help you understand the steps to solving a user problem, and uncover opportunities for improvement
• Book Recommendation: Mapping Experiences by James Kalbach
• Experience Maps: can show you how everything fits together. Customer actions, customer types, emotions, technology needs and more.
• Focus on understanding the why a need or problem is worth solving (or not)
• If it’s helpful think of your system as a special sort of customer and identify system needs
• Opportunity Solution Trees: distinguish solutions from the problem (or opportunity) they’re intended to address. The key to good opportunity solution tree’s is a clear desired outcome.
• Hierarchy: Expected Outcome → Opportunity (Theme) → Solution (features) → Experiment
• User Stores: As a [user type] I want [desire] so I can [result]
• Job Story: When [situation/motivation] I need [desire] so I can [result]
• Themes are about outcomes not outputs. If you find yourself listing deliverables ask why. Why are they important? What will result from doing them?
• Every step should be incremental and build on the one before:
• Vision: the change you want to see in the world
• Objectives: the goals you want to accomplish in the next version of the product
• Themes and subthemes: the customer needs or problems that you’re addressing
• Every theme should related directly to an objective. You can link to more than one.
• Each time you do a major revisit of the roadmap, revisit your objectives.

Deepening your roadmap

• Secondary components help you provide more context and spend less time explaining your roadmap.
• Probable solutions (features) that you may implement. Infrastructure solutions that you may need. Carryover solutions, from previous roadmaps.
• Do you understand the need? Have you validated the solution? Have you validated infrastructure needs? What’s your confidence it’ll go ahead in the current form / timeline
• Stage of development: Discovery, Design, Test, Prototype, Develop, Alpha, Beta
• Confidence: represent the level of certainty that we will deliver on those items in those timeframes
• Product Areas: distinct areas, or separate businesses
• Experiment with components and remove what’s not valuable.
• Balance having too much information with too little.

Prioritising with Science:

• Prioritisation framework can help stakeholders focus on what’s important and align with each other.
• Prioritisation is important because of opportunity cost. Opportunity cost is you never get the chance to do something important because you chose to work on something else instead.
• Assume you might have to stop working at any time. All projects are at risk of cancelation or downsizing.
• As functionality grows the regression test matrix grows exponentially.
• If you focus on one set of problems for a certain set of customers you minimise the increasing draft of bad decisions.
• Bad ways to prioritise: your guy, analyst options, popularity, sales requests, support requests, me-too-features
• Prioritisation frameworks:
• Critical Path: Identifies key drivers for customer purchase, categorising needs as "critical" or "noncritical." Ideal for designing MVPs or major scope expansions, but does not consider effort, risk, or business goals.
• Kano Model: Understands customer value perception, useful for identifying add-ons or enhancements. Overlooks effort, risk, and business goals.
• Desirability, Feasibility, Viability: Identifies opportunities meeting success criteria, best for small sets of initiatives or solutions. Lacks clear definitions for customer needs, organizational goals, and effort or risk types.
• ROI Scorecard: Ranks ideas based on return-on-investment, evaluating multiple factors and long lists of initiatives. Complexity requires alignment on value and effort components.
• MoSCoW: Communicates launch criteria (Must-have, Should-have, Could-have, Won't-have), ideal when uncertain about product, service, or release inclusions. Helps communicate but does not set priorities.
• Value / Effort = Priority

Achieving Alignment and Buy-in:

• No plan survives contact with your stakeholders.
• Your plan will only work if you can get people to believe in it.
• Alignment: a concerted effort to help people understand the issues and what their respective roles are. You have to ask questions and listen to feedback. Not consensus.
• Shuttle diplomacy can help coordinate stakeholders to reach an agreement. Meet with each party individually first for decisions require compromise and trade-offs.
• Politics are much more manageable in one-on-one settings
• For each stakeholder, understand:
• Goals: what are they trying to achieve in the next X months?
• Reality: what’s on their plate now? what’s recent?
• Options: what do they think will help them achieve those goals? What options have you already discussed that need to be revisited?
• Way forward: which of the options helps them achieve the goals they described earlier in the conversation? Which options are the top of their list and why?
• Only after you’ve done shuttle diplomacy should you bring everyone together into a meeting or workshop. There has to be a culture of constructive disagreement and agreement on the companies strategy.

Presenting and Sharing your roadmap

• Every stakeholder benefits from a view into what’s coming and an opportunity to contribute.
• For the roadmap to get everyone excited about the future, it must tell the story.
• You should share your roadmap widely to both inspire and align everyone.
• Co-creation and sharing early and often can help with the IKEA effect and radically increase buy-in.
• Overpromising and underdelivering seems like a big risk, but people will be forgiving as long as you’re open and honest about your priorities.
• The Osborne Effect: announcing future plans too early can slow down current sales if people choose to wait for the next version.
• Roadmaps need to be tailored to the audience, but from a common foundation.
• Some things are best kept Internal
• Some stakeholders require more detail than others
• Development teams: Features and solutions, Stage of development, Product Areas, Scalability, Technology & Infrastructure, Dependencies and risks
• Sales and marketing might need: Features and solutions, Target customers, Confidence, External drivers (events, times of year etc)
• Executives: Market opportunity, profit and loss
• Customers: Features and timeframes
• For roadmap presentations:
1. Identify your audience
2. Clarify your goals for the presentation
3. Determine what your audience cares about
4. Assemble your components
• Sequence as follows:
• The why, make sure everyone is onboard with the product vision. Cover recent progress. Use customer anecdotes as well as data
• What’s in the near term, and clarify what critical needs justified the prioritisation and aligned with the business objectives. Add quant and qual information that helps justify it
• Propose what’s in store for the longer term and continue to reinforce how this will align with the company’s objectives

Keeping it Fresh

• When conditions in the environment change, your roadmap must change in order to survive
• Technology advances, competitors, trends and even the company strategy can change.
• Revise roadmaps on a regular cycle to reflect market changes and shifts in strategy or priority, which allowing execution to proceed steadily between updates.
• How stable your environment is should determine how how far out your roadmap should go.
• Discovery: Short (months)
• Growth: Longer (quarters)
• Maturity/decline: Longest (years)
• How to deal with special requests:
• What problem is this request trying to solve?
• Does solving that need align with our objectives?
• Is it more important than what’s on the roadmap now?
• When communicating change:
• Embrace change but share the reasons openly. Socialise them like you’d socialise a new roadmap.
• Forks in the road: if there’s a decision that could completely change the nature of the strategy or the roadmap then call it out and shot it as a fork in the road.

Relaunching roadmaps in your organisation

• How to get started
1. Assess your situation and choose an approach
‣
Roadmap Health Assessment:
1. Depending on the size of your challenge you can choose to A)course correct or B) do a full relaunch
2. Get buy-in for change from your key stakeholders
• Align everyone involved.
• Share the results from your health assessment
3. Train your stakeholders how to contribute
• Help them get the most out of the new process
• Explain what’s different and why
• Explain how they can contribute
4. Start small and work incrementally
• Start small and demonstrate early success
• Pick a portion of the process first, what can you fix in a few weeks?
5. Evaluate your results and align on next steps
• Seek feedback from stakeholders to check if things are working
6. Keep relaunching
• You’ll face resistance but keep at it.