Review

Prior to this book, there wasn’t a definitive Product Operations text. Product Operations was only loosely defined in a few blog posts and job descriptions. Finally, we have a stake in the ground. Something to reference or disagree with.

This wasn’t a riveting read, nor is it a Product Management classic, but it’s a book the community needed. I’m grateful Melissa and Denise have given us a thoughtful and thorough account of Product Operations.

You Might Also Like:

Book Review and Summary: Escaping the Build Trap by Melissa Perri

Get a comprehensive review and summary of the best-selling book "Escaping the Build Trap" by Melissa Perri, the product development expert. Learn about the key principles and practices for creating successful products and avoiding common pitfalls in the product development process.

andrewclark.co.uk

Radical Focus

The second edition of Radical Focus is one of the better books on implementing OKRs. OKRs are really powerful in the right context. It’s refreshing for a proponent of OKRs to come out and say they’re not useful everywhere. Christina doesn’t recommend their use in operations teams and proposes subtle adaptations of them for exploratory or long-lead-time work. There are many good OKR explainer books, but I feel this one does a great job of describing some of the rough edges and challenges.

andrewclark.co.uk

Book Summary: Accelerate by Nicole Forsgren, Jez Humble, and Gene Kim

Get a comprehensive review of the best-selling book "Accelerate" by Nicole Forsgren, Jez Humble, and Gene Kim. Discover the key insights and takeaways from this must-read for tech leaders and professionals

andrewclark.co.uk

Key Takeaways

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

• Product operations is the discipline of helping your product management function scale well. Surrounding the team with all of the essential inputs to set strategy, prioritise, and streamline ways of working.
• Product Operations has 3 core pillars:
• Business Data and Insights
• Collection and analysis of internal data for strategy creation and monitoring. Helps leadership track outcomes and determine return on investment of product teams. Contextualises business metrics with product metrics to help leaders make strategic decisions
• Customer and Market Insights
• Facilitating and aggregating external research. Streamlining insights received from users and making them accessible. Providing teams with the tools they need to conduct market research (e.g. competitor analysis, TAM-SAM-SOM)
• Process and Practices
• Defines the product operating model:
• how the company creates and deploys strategy
• how cross-functional teams collaborate around strategy and deployment
• how product management team functions
• Product governance and tool management also
• Evaluate the biggest needs and pain points. You don’t need to stand up all the pillars at once.

• Product managers often don’t have capacity to fix the process
• The absence of standard roadmapping processes, templates or a common framework for articulating roadmap outcomes hinders translation into an overall strategy
• Multi-product environments create mini fiefdoms, teams focus on their product. Sharing information and processes doesn’t happen naturally. We need Product Operations to break down silos of information and capability
• Product strategy is enabled by core inputs (quantitative and qualitative data) that inform your focus (or ‘bets’). Setting strategy without these core inputs, you’re making uninformed, and likely, quite costly bets.
• Product operations also helps bring the organisation together to reach goals. Product operations is an enablement function, here to make the decision-making process easier and more transparent (not to make decisions).

• Business and data insights:
• Steps to implementing data & insight capability:
• Understand what questions you need to answer to inform your product strategy
• Determine which pieces of data you need to track to answer those questions
• Identify which systems the data lives in and how to extract it manually
• Create a baseline dashboard (by pulling data manually)
• Automate the dashboard creation in a BI tool (Business Intelligence)
• Revenue and cost analysis is a core part of the product operations process. You should be able to provide a product-centric view of bottom-line costs through monitoring:
• Cost of efforts
• Investment spend breakdown
• View of activities aligned to goals/initiatives
• Efficiency of operations
• Support calls/defects
• An experienced product manager can tell a story about their product strategy with with data
• Different data is required for the different levels of strategy creation ( for forming strategic intents, identifying product initiatives, or generating options)
• Teams need to slice product metrics in different ways, to understand the trends across varying customer types, cohorts or geographies.
• Product operations can ensure that the team has the right instrumentation and data available at their fingertips to make these decisions.
• When teams have real-time data, they’ll be able to react quickly to customer feedback and market demands
• The type of engineering work needs to be tracked because it’s accounted for in different ways:
• Capitalise new features, and foundational technology
• Expense bug fixing, performance enhancements, experimental development and research

• Customer and Market Insights
• Research initiatives are worthless if the product team can’t use the outputs.
• Democratise your research → increase your learning velocity
• Friction to book interviews can stop product managers talking to customers.
• Setup systems that allow PdMs to get the insights they need to make critical strategy decisions
• Insights can come from many different places: Win/loss analysis data from sales, reviews from customers on websites, support calls and emails, generative and evaluative user research conducted by other teams, reviewing existing customer research
• Product operations for customer insights is about streamlining 3 things:
1. Get internal data you have already to product teams
2. Making it easier to do generative and evaluative research
3. Making the research accessible and reusable for all teams
• Enabling a customer research function:
1. Catalog: what sources exist today
2. Contextualise: What was the intent from each channel?
3. Create: 360 degree view of data to date
• Inspect the quality of the data/assets you have. Can they be made more useful for product managers? Work with departments to use better tagging (e.g win/loss reason codes by Sales)
• Focus on the activities, tools, and systems that will make user research accessible to the rest of the organisation:
• Democratisation of Research
• Access users quickly (setup a user access system to stop research from being a bottleneck)
• Train those interested in conducting research (e.g. unmoderated usability testing)
• Allow more people to self-serve
• Research Repositories
• Catalog, store and expose previously conducted research. Anyone requesting research must first check the repository
• UX research framework and playbooks. Helps teams understand questions each research team can answer and align to the product and marketing life cycle

• Processes and Practices (Product Operating Model)
• Product Ops isn’t about creating process, it’s about increasing the quality and speed of decision making
• A Product Operating Model: the way we translate the business and product strategies into the work getting done. Components of…

• Good governance includes product oversight, review mechanisms, risk management, compliance, single point of responsibility, and continuous improvement.
• You manage innovation by linking processes with strategy, business models, and capabilities. Product insights and data analytics are the backbone of monitoring and alignment.
• Better governance allows you to monitor your strategy and have quarterly planning. Planning isn’t about process, it’s about setting a cadence for vital conversations that enable us to be more responsive to market and business needs
• Funding product teams not initiatives makes this easier
• The goal is to develop a culture of “either/or’’ trade-offs rather than a “yes and…’’ atmosphere AND to help provide transparency to the rest of the organisation on what is happening in product development.
• Often roadmap formats are sporadic and they aren’t data-driven at all
• Don’t standardise every process and overwhelm your teams. But there are areas where it helps. Particularly things that affect cross-functional areas, encourage consistent practices across teams. Idea management, roadmapping, product tool kits and onboarding
• Roadmaps are a communication tool. To figure out which ones are right for your company, think about your audience and what they need to know.
• Standardising product development state language can help (Discovery, Alpha, Beta, GA)
• Product teams can place an unhealthy amount of reliance upon tools: “Once we have this Tools enhance processes and practices, they don’t replace them.

• There’s an always-tricky balance between governance and agility
• Product operations facilitate governance / annual planning by…
• Designing the cadence of inputs, decisions, and communications
• Generating momentum and urgency in aligning initiatives
• Bringing together the right set of product people and stakeholders for decision-making
• Set the table for key meetings: fast-paced agenda + clearly-defined meeting outcomes
• Providing easy-to-follow templates to promote a high level of engagement with a minimum level of effort

• Through surveys measure how people in your organisation perceive the value of product management → make them health metrics on a dashboard
• PMs don’t always buy in. There’s often a concern Product Ops will take over. BUT a product operations team doesn’t make the decisions, it enables the decisions to be made.
• Tips for starting:
• Start small, do it in one team first, check the pain points, iterate and improve.
• Find and work with promotors who are excited by the vision
• Say no, and be clear about what you can achieve with your current bandwidth
• Map out a vision for how Product Ops could grow
• In a small team, you set the standard and the tone. Solve hard problems, then speak about it.
• Think about the intersection of what product ops can do, and what’s most strategically important for the company
• Secure executive support
• Focus on all types of data
• Get to impact quickly
• Balance process with agility

Deep Summary

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

Why we wrote this book

• There’s a lot of confusion about what product operations is
• Product Operations streamlines systems at scale. It helps teams and leadership get clarity on the performance of their products, which enables better strategic decision making.
• Product Operations is the key to scaling product management’s value
• Streamlining insights into your business, customers, and processes is incredibly valuable.
• Product Operations empowers product managers build products customers love that achieve better business outcomes.
• Product operations is the discipline of helping your product management function scale well. It’s an enablement function that aims to give each team the essential inputs to set strategy, prioritise, and streamline ways of working. P
• Pillars of Product Ops
• Data and insights
• Customer and market insights
• Process and governance
• Product Ops teams make sure the product management function gets what it needs to stay healthy and valuable. Product Operations define the product management operating model

Part 1. Introduction to Product Operations

• Product management is a tough job, product managers have to be good at everything.
• You don’t have time to do product execution, product strategy and product operations at the same time
• If compiling data for product strategy conversations is difficult you won’t have time for execution or time to fix data enablement for everyone
• Even with training Product Managers can’t do their jobs well without data
• The absence of standard roadmapping processes, templates or a common framework for articulating roadmap outcomes hinders translation into an overall strategy
• Many sources of data are important to Product leadership
• What teams plan to do
• Capacity planning and investment allocation across teams
• Understanding ARR (annual recurring revenue) by persona and product
• Getting qualitative inputs to understand churn numbers better
• Tracking who works on what to attribute costs to products/projects
• How do you know if your data gathering process isn’t efficient? By the time you’ve finished gathering your data it’s time to do it again.

1. Why Product Operations

• Multi-product portfolios create mini fiefdoms. People focus on their product, and don’t naturally share information. Different ways of working (processes) pop up, both within teams and cross-functionally
• We need to break down silos of information and capability
• Product operations arose from the need to bring modern software teams and cross-functional stakeholders together to deliver valuable products.
• to surface the right information in order to make strategic decisions
• to help all the departments understand where they can have an impact on the product life cycle.
• Functional operations teams are not a new concept (common in marketing and sales)
• Responsibilities of product managers are many:

• Many product operations responsibilities are conducted by senior leaders in ‘spare time’
• Product operations helps enable product managers to focus on the most important things (setting and achieving their product strategy)
• You’ll get a happier more supported product team, who have the information they need to make good decisions
• Product operations can’t solve for unskilled product managers
• Great product people will fail without the infrastructure to support them
• Don’t do everything at the same time.
• Home in on the one pillar that’s the biggest pain point and opportunity for your organisation
• Explore where to focus first….

2 What is Product Operations?

• Former product managers have empathy for the job, and think about how to make it easier and build up scalable systems

Product operations is the discipline of helping your product management function scale well. Surrounding the team with all of the essential inputs to set strategy, prioritise, and streamline ways of working.

• Product Strategy is a system of achievable goals and visions that work together to align the team around desirable outcomes for both the business and its customers.
• Product strategy emerges from experimentation toward a goal
• Product strategy is enabled by core inputs (quantitative and qualitative data) that in form your focus (or ‘bets’)
• Setting strategy without these core inputs, you’re making uninformed, and likely, quite costly bets.
• Pull information from across the organisation into a cross-functional view that helps everyone make more strategic decisions
• Aligning the organisation around goals
• Product operations also helps bring the organisation together in determining how to reach those goals
• Product operations is about removing obstacles form product managers and product leaders to make evidence-based decision-making
• Product operations provides the infrastructure needed to enable the product team to make strategic decisions and align the company around them
• It helps remove frustrations…
• How do I contribute to the roadmap?
• Different GTM processes?
• Make annual planning data-informed
• How to communicate strategy effectively
• Help the exec connect the actions of the product teams back to the outcomes we want to achieve?
• Product operations is an enablement function
• Here to make the decision-making process easier and more transparent (not to make decisions)
• The three core pillars of product operations:
• Data and insights
• Customer and market insights
• Processes and practices

3 The three pillars of Product Operations

1. Business Data and Insights
• Collection and analysis of internal data for strategy creation and monitoring
• Helps execs track outcomes and determine return on investment of product teams
• Contextualises business metrics (like ARR and retention) with product metrics to help leaders make strategic decisions
2. Customer and Market Insights
• Facilitate and aggregate external research
• streamline insights we receive from users and make them accessible
• provide teams with the tools they need to conduct market research (e.g. competitor analysis, Total Addressable Market/ Serviceable Addressable Market)
3. Process and Practices
• Scales product management value with consistent cross-functional practices
• Defines the product operating model
• how the company creates and deploys strategy
• how cross-functional teams collaborate around strategy and deployment
• how product management team functions
• Product governance and tool management also

• When considering how to address these challenges: evaluate the biggest needs and pain points. You don’t need to stand up all the pillars at once.

PART 2: Pillar 1: Business and Data Insights

• Once you know the data you need for product strategy, instrument it for longer-term needs.
• It can be wasteful and counterintuitive to require PMs to learn scripting languages to self-serve data (e.g. SQL / MQL)
• If you can’t get data from systems to reconcile nobody will trust your reports. It’s important that PMs don’t spend all their time cleansing and reconciling data from every system
• To achieve a measure of value for money, you seem some form of rough time allocation from the teams (e.g. timesheet data). It’s important for accounting but also strategy.
• Before solving self-serve data, you might add an analyst to each team. Have them sit in the product close to the team.
• Steps to implementing data & insight capability:
• Understand what questions you need to answer to inform your product strategy
• Determine which pieces of data you need to track to answer those questions
• Identify which systems the data lives in and how to extract it manually
• Create a baseline dashboard (by pulling data manually)
• Automate the dashboard creation in a BI tool (Business Intelligence)

4. Contextualising Data from a product perspective

• Product leaders need to explain the why behind the work done to accelerate EBITDA by surfacing, acting on, and monitoring product levers.
• Revenue and cost analysis is a core part of the product operations process.
• You need evidence that your product strategy could work / is working:
• Month-over-month product profitability
• Usage by user/company
• Status of new and ongoing products
• Market data on adjacencies and competitors
• Customer Key Performance Indicators (KPIs) by segment
• TAM expansion opportunities
• Being able to optimise R&D spend and cost of goods & services (COGS) to deliver strategy efficiently is critical as well.
• You should be able to provide a product-centric view of bottom-line costs through monitoring:
• Cost of efforts
• Investment spend breakdown
• View of activities aligned to goals/initiatives
• Efficiency of operations
• Support calls/defects
• Product operations brings this data together for one holistic view, becoming the connective tissue to the 360 view of all activities that impact product strategy (and EBITDA)
• Aggregated into one visualisation tool, accessible in real time and for ongoing analysis
• Cross-functional stakeholders will reap the benefits too
• You need to understand what you want to measure before you can instrument it.
• Typical Data to Track

• An experienced product manager can tell a story about their product strategy with with data

5 Getting to the Right Strategic Questions

• Layers of strategy from Escaping the Build Trap

• Different data is required for the different levels of strategy creation. Product Operations can play a vital role in ensuring it is readily availible
• Questions to inform strategic intents:
• Understanding the current state of the business and trends is the first step toward identifying your potential levers of impact
• General metrics about revenue and cost in your business can provide insight, but aren’t enough to drive intent. ‘Growth slowed last year’ doesn’t tell you what to do
• Instead you’ll need to slice and dice data to by different criteria to reveal what’s important:
• Customer segment and/or persona type
• Cohort
• Geography
• You’ll likely spot a few things that warrant further investigation and research.
• Questions to Inform Product Initiatives
• Product leaders need to prioritise the key initiatives necessary to achieve business outcomes, which may be across products and functions.
• Product leaders should use the focus from strategic intents around markets and business strategies to follow up on questions such as:
• What is the revenue by-product and feature, and is it commensurate with spend?
• Do certain personas buy different packages?
• What is the retention of customers who buy different products? What percentage of our customers are buying each product or feature set?
• Does the revenue here align with the segments we’ve identified as our target customers? Does the spend align with our strategic focus?
• Do all of our products have ample usage, or should we consider sunsetting underperforming products to focus our resources?
• These questions will provide data points which will direct product managers toward a bigger question: Why? Answering the why will help to formulate the product initiative.
• The setting of strategic intents and product initiatives should include close collaboration with the C-suite, a back-and-forth exchange of data and insights.
• Strategy is not just a one-way deployment. It needs to be communicated up, down, and across.
• Questions to Inform Options
• Teams need to figure out how to solve the identified problems. Teams should be able to connect the dots back to the strategic intents, and tie solutions to revenue and cost opportunities.
• Teams need to understand their product, their customers and their business so they can translate higher-level product initiatives into smaller customer problems.
• A decrease in net promoter score can signal an increase in churn in the future.\
• An increase in feature usage can predict increased revenue in the future for subscription-based models.
• An increase in adoption across different products can signal an opportunity for cross-sell and upsell revenue.
• Teams need to segment product metrics to understand the trends across varying customer types and cohorts.
• PdMs need to prioritise various opportunities in their backlog against the value it will achieve for the customers and business. Product initiatives become a lens for prioritisation: ‘Will prioritising enhancement A or B produce more value toward the product initiative?’
• Product operations can ensure that the team has the right instrumentation and data available at their fingertips to make these decisions. Once decisions are made, the teams will need to monitor the results and adjust accordingly.

6 Visualising the Data

• Identify the questions you need to answer → visualise your end state → find out where the data lives → add missing instrumentation → make the dashboard manually → automate it
• Conduct a Product Metrics Instrumentation audit:
• Is engagement data enabled today?
• Which tool(s) are we using?
• When were the event tags implemented?
• What kind of metrics are we able to see?
• Can we measure engagement on all of our products and/or features?
• What would we want the optimal state to look like, in terms of data captured?
• If you don’t have a product experience measurement tool (e.g. Amplitude) make a business case and get one (provide examples of decisions made without data or quality data?)
• Core engagement metrics:
• Product stickiness (daily/weekly/monthly active users [DAU/WAU/MAU])
• Frequency (e.g. number of logins for a given customer)
• Feature adoption rates Feature retention rates
• Product usage data
• Depth (feature usage by time, funnel, and more)
• Breadth (could be the number of active users)
• The product ops job here is to ensure everyone is consistently informed about what you’re measuring, why, and what’s actionable
• Resource allocation data is useful when thinking about return on investment and where to allocate resources. Who’s working on what by project or theme?
• Timesheets are great for this or a weekly high-level report of aggregate hours by theme is OK too
• Use these buckets:
• Strategic Work: e.g. product initiatives
• Technology Debt and Platform Improvement
• Business As Usual (BAU)/ Keeping the Lights On (KLO)
• Bugs
‣
Bucket bar chart

The Manual Baseline

• After instrumenting the data you need to define and monitor your strategy, put it together in a holistic view
• One for informing strategy
• One for monitoring strategy
• The manual baseline helps you check if the data is useful IRL decision making process. It helps you agree the data that’s useful, and find the best way to visualise it.
‣
You might need data from many different sources

• Getting a manual baseline can take longer than you’d like. Be patient, go through a couple of cycles before you automate.
• Product operations consolidates product and business metrics into effective dashboards that help inform strategy and provide transparency into its progress
• You’ll need at at least two levels of dashboards:
• Product-Team dashboards:
• Used by PdMs to monitor results of experiments and work that’s contributing toward the overall outcome set in the product initiative
• The dashboard should help keep the team aligned on moving the right metrics, and show how it ladders up to key initiatives.
• What’s on the dashboard?
• As well as showing product metrics, show how they vary by persona.
• As well as showing experiment results, show hurdle rates / success criteria
• Show roadmap status and projected metrics for pre-launch initiatives
• Show who’s responsible for each roadmap item
• Don’t show DORA metrics
• Exec dashboards
• Portfolio level view of how the product and business are doing
• Want to see how strategy is progressing, what are the key success metrics
• Aim is to inspire confidence
• Make it high-level and easy to understand.
• Good Dashboard Hygiene
• Use people’s names for accountability and empowerment
• Represent all the work (if you can)
• Set time periods appropriately (for your check-ins)
• Automating data and insights
• Plum all of your data into a visualisation tool
• Ensure PMs can pull what they need out of the tools to conduct analysis
• Connect financial data and product data, there should be a through line from product results to business results.
• The value of automation:
• Access and leverage realtime information
• Track realisation of prioritised outcomes
• Compare snapshots in time
• Validate and demonstrate pogress
• Improve forecasting
• Manage product development ROI better
• Steps to automation
• Select a Business Intelligence tool to automatically aggregate data (e.g, Looker, Tableau)
• Implement rules to tag data for cost allocations and strategic task-tracking. Improve data quality at source
• Give yourself 4-6 months of discovery and iteration to hone the dashboard. Review each quarter to see if you’re still tracking the right things
• You can start with product-team dashboards as the first value slice, and tackle exec later.
• When teams have real-time data, they’ll be able to react quickly to customer feedback and market demands
• Advantages of having roadmap items in Jira:
• Better planning and documentation for key decisions
• Transparency into R&D execution against plans
• Improved cross-team dependency management
• Automated software capitalisation reporting
• Categories of Work:

• Product operations can provide value by ensuring that the investments align to the needs of the business

Getting started with data and insights

1. Hone in on the Metrics That Matter
• Based on the outcomes you want to achieve: select 3-5 financial and product metrics you should measure.
• Rethink what you’re measuring and what’s most actionable.
2. Partner with Finance
• Create tight links between product and finance data, to better inform product development and opportunities
3. Understand R&D Allocations
• Get visibility if R&D spend.
• Understand engineering allocations to ensure the right product bets are being resourced as agreed

Part 3: Pillar 2: Customer and Market Insights

• Research initiatives are worth absolutely nothing if the product team can’t use the outputs.
• Democratise your research → increase your learning velocity

Chapter 7: The Research Pillar

• Product Managers know they need to be talking to customers. Normally they’re not doing it due to logistics. Interviews are easy, setting them up can be a faff
• Some management worry about customers being nagged for feedback / testing all t
• Product Ops can help setup systems that allow product managers to get the insights they need to make critical strategy decisions
• Insights can come from many different places:
• Win/loss analysis data from sales
• Reviews from customers on websites
• Support calls and emails
• Generative and evaluative user research conducted by other teams
• Reviewing existing customer research, for the type of insights you’re looking for now
• We often have lots of customer insights in our systems
• There’s also market research: industry trends, competition etc
• Market sizing: allows us to assess whether an opportunity is worth going after
• Competition analysis: helps us understand how we stack up against the other players
• Start where there are the biggest gaps

Chapter 8: Customer Insights

• You need to take a cross-functional view to customer insights: UX, sales, support, GTM, PdM. Start with where feedback comes from today, then ask how can you circulate the information more efficiently.
• Product operations for customer insights is about streamlining 3 things:
1. Get internal data you have already to product teams
2. Making it easier to do generative and evaluative research
3. Making the research accessible and reusable for all teams
• Find what teams already do well, then fill in the gaps
• Teams need to strike the balance between doing too much and not enough research
• If your company is having hundreds of customer conversations (through sales and support) you need to find a way for your product team to harness that insight

Product Operations is building the the connective tissue between the teams building your your technology and the teams who interact with your users Blake Samic · Product Ops OpenAI, ex-Uber, ex-Stripe

• Bring all of the customer-facing teams together to understand what data they collect
• Enabling a customer research function:
1. Catalog: what sources exist today
2. Contextualise: What was the intent from each channel?
3. Create: 360 degree view of data to date

• Inspect the quality of the data/assets you have. Can they be made more useful for product managers (capturing key information for them)
• e.g. better tagging of win/loss reasons by Sales
• Setup both reporting and meeting cadences to review

Chapter 9: Streamlining the User Research

• Once we get the data out of our existing systems, we will start to identify gaps in the information we need
• User interviews can help fill the gap.
• Typical Problems:
• PdMs find setting up research burdensome so they fall into the trap of frequently contact the same users (which develops a blind spot)
• Lessons learned from research often get isolated to teams that performed the research
• Sales may block some customer interviews (due to the sales cycle)
• Product managers may avoid talking to customers
• Focus on the activities, tools, and systems that will make user research accessible to the rest of the organisation:
1. A database of users who’ve opted into user research (makes it easier to find users for research)
• Recruit opt in users: ask them what types of research they’ll participate in
• Log all research against them
2. A repository of user research: you might find your research question has been answered already
• holds notes and videos from previous research)
• Findings uploaded (qualitative and quantitative)
• Research roles and responsibilities:
• User researchers own the methodology to conduct research.
• Product managers consume the research. They might also design and conduct research on their own, and should be frequently attending user research sessions.
• Product Ops make it easier for user researchers and product managers to conduct the research and understand the insights they need.
• They oversee the tools and implement systems
• Playbooks for future reference
• Which systems should capture results
• Advise on the best user research tools
• Organise the user/client outreach database for user research and testing

10 Market Research

• What role does market research have if you’re talking to customers?
• Helps understand the value from a potential market
• Helps understand the competitors, the trends, and how much potential value is in each market
• Helps quantify potential opportunities in different markets
• Create models to predict how much of the market can be captured over time
• Helps quantify tradeoffs of product strategy
• Estimating Value of Expansion Opportunities
• Take into account the dynamics of both markets and the competitive landscape
• How big is the market size of each option?
• Can we actually penetrate that market, or is it saturated with another solution?
• What do the contract times look like for our competitors? Is everyone signed up for big commits already?
• Key Terms we want to understand:

Total Addressable Market	TAM	total potential value we could achieve if we were able to capture the entire market
Serviceable Addressable Market	SAM	the segment of the TAM we could capture with our current products or future products, given the demand for our type of product within our geographical reach
Service Obtainable Market	SOM	the portion of the SAM we could realistically capture, taking into account our development time, competition, and current sales staffing

1. Calculating these terms is time-consuming
2. You need knowledge of companies in the market and their attributes
3. Models typically provide a range (best—and worst-case scenarios)
4. You might need to hire an analyst with experience into product ops to help you in this area

Competitive Analysis and Market Trends

• Setup google alerts for competitors, markets, technologies and features.
• Don’t duplicate Product Marketing efforts.
• Start with basic market trend analysis (subscribe to to research platforms like Gartner)
• Product Ops can hold the keys to demo versions or logins of a competitor’s site
• Ask prospects or those considering a switch. Invite them to walk you through their reasons and screen share the competitor site with you. Record these sessions and keep them in the customer research database we talked about earlier in this chapter.
• Product/Research Ops can accelerate learning velocity by streamlining the way user research was conducted and enabling the product teams to self-serve.
• UX research framework and playbooks
• Research requests come are of a higher-quality. Helps teams understand questions each research team can answer and align to the product and marketing life cycles
‣
Example: Research questions over product lifecycle

‣
Example: Usefulness Assessment

• User access
• User access system for recruitment of users
• Reduce the lead-time to 48 hours
• Helping non-researchers: Democratisation of research → research repository
• Democratisation of Research
• Access users quickly (remove research from being a bottleneck)
• Train those interested in conducting research (e.g. unmoderated usability testing)
• Doing so can radically increase capacity
• Research Repositories
• Everyone can access research previously conducted
• For user research, market research, customer experience research, marketing and branding research, and licensed third-party research
• Once completed research is uploaded to the system
• Anyone requesting research must first check the repository
• Tips for getting started on Research Ops:
• Start with a listening tour. Learn about pain points, needs, the current perception of user insights, and their understanding of PdM
• Analyse the past 6-12 months of research.
• Categorise it it by “development phase” and “questions answered” to determine where researchers are spending their time.
• Many UXR orgs spend too much time on evaluative usability research
• Shifting left/upstream can help create useful products and product-market fit
• Democratising certain forms of user research proves beneficial
1. Contextual education: researchers teach, practitioners apply
2. Buddies: a UXR who checks their work and helps them succeed
• Work to build a learning agenda. Use a framework that emphasises uncovering user needs, iterative design and testing of solution concepts, and ensuring usable experiences.
• Success measures:
• Insights-to-action rate
• Accelerated research schedules
• Ability to meet insights demands

Getting Started with Customer and Market Insights

1. Create a Table of Research Insights
• Take stock of what exists today
• Capture assets by team, type of data collected, which system it lives in, and the frequency at which it is collected
• Look for are and prioritise accordingly.
2. Get up to speed on market trends
• Determine which professional research services your company subscribes to (e.g. Gartner, Forrester)
• Start with some basic market trend analysis
3. Assess the State of Research Tools
• Research tools and processes are core to product operations (prototyping, surveys, & user research)
• Understand what tools are licensed and how teams are using them
• Build a quick catalog of existing research
• Contextualise: What was the underlying intent or hypothesis behind the research from each channel?
• Create a360-degree view of the insights

Part 4: Pillar 3: Creating a Product Operating Model. Processes and Practices

• The Product Management Process will be standardised more in large companies
• Sales, engineering and customer success all have well understood methodologies that everybody follows
• Product Operations will create a more rigorous product management process
• Product often doesn’t do enough to engage cross-functional stakeholders in the planning process

Chapter 11: The Product Operating Model

• Reframe ‘process’ to ‘method’ or ‘service’: e.g. providing useful services to that do the heavy lifting for product managers
• Run product ops like an API product, a set of methods that go through versions. If they are not helpful and used, they should be deprecated.
• Marty Cagan labeled product ops and ‘the rise of process people’ dangerous
• Product Ops is though is about adding operational leverage to a product team NOT dictating how the team should do everything.
• The premise that it’s all about process is misguided.
• Product Ops is about increasing the quality and speed of decision making
• Product Ops set the ways of working so teams can get to the actual work (rather than spending cycles debating process)
• A Product Operating Model: the way we translate the business and product strategies into the work getting done
• the CPO sets the product principles, culture, and values for the product team
• the product operations team help define and put into practice the process and governance pieces
• The operating model provides guidelines on how the product team works with each other and with other departments and stakeholders.
• It defines a blueprint for roadmapping, reviewing strategy, idea management, and annual planning
• It helps align the entire company around product development.

Chapter 12: Creating the Process and Governance of the Product Operating Model

Components of the operating model:

• Example Activities from fictional case study in book:
• Standardise product roles and career ladders.
• Work with other disciplines leaders to define the boundaries between their functions and product management.
• Get PdMs the skills training they needed to understand their day-to-day work.
• Standardise templates and tools to make it easier to work cross-functionally (e.g. roadmaps)
• Setup and automate a product reporting cadence on metrics, outcomes, and roadmaps

Chapter 13 Governance and Product Planning

• How do we know work ladders up to the product strategy?
• Do you review OKRs or KPIs on a consistent basis?
• Do you change course you’re not progressing toward OKRs?
• Do you have the right people in the room to make decisions in real time? (governance)
• Good governance includes product oversight, review mechanisms, risk management, compliance, single point of responsibility, and continuous improvement.
• You manage innovation by linking processes with strategy, business models, and capabilities.
• Product insights and data analytics are the backbone of monitoring and alignment.
• A good governance model and the right software allow for continuous product planning
• Badly done, governance cycles are extremely costly and time-consuming, companies typically do them only once a year.
• Doing it just once a year means sacrificing the ability to adjust initiatives and strategies to align with current realities and competitive pressures.
• Better governance allows you to monitor your strategy and have quarterly planning. Planning isn’t about process, it’s about setting a cadence for vital conversations that enable us to be more responsive to market and business needs
• Two bits of governance for Product Organisations:
1. Cadence for strategic discussions
2. Cross-functional touch points
3. Both combine the right insights to the right people enabling better decision making
• Good governance provides focus. Focus is about saying no.
• Avoid doing it in front of executives with no context, or the whole company who can’t do anything with the information

Product Operations owns and define expectations around inputs and outputs for key meetings:

Example:

• Practice makes perfect for planning at the team, function, and organisation level. The key is cadence… to force tough conversations
• Do well and you won’t need yearly planning
• Review strategic intents and update them on a quarterly basis in the QBR.
• Funding product teams not initiatives makes this easier
• Tell your stakeholders what the planning process is AND tell them how and when they can contribute
• Introducing a prioritisation framework can force stakeholders to consider trade-offs instead of just adding more to your lists
• Product Operation on governance…
• sets the cadence for predictable planning cycles (annual, quarterly, monthly)
• set expectations cross-functionally as well
• lay out the vision of how each function contributes to the roadmap, cadence of reviews, and more.
• define and share templates of roadmaps, budgets, and resourcing will provide immediate value in the process.
• sets up and facilitates the company discussion around what the organisation needs and then provides governance for that.
• You might choose to prioritise both both outcomes and features
• Outcomes give you more flexibility and ability to explore
• Features give you more control and maybe more speed
• create templates for each meeting, e.g. formats of OKRs or business cases to introduce a new initiative, and distribute them well in advance
• create the agendas, track discussion and action items.
• they improve the meetings based on feedback (through retrospectives and continuous improvement)
• ensures that all of the choices made in each session are transparent to the org
• own and implement the software tools to help this happen
• The goal is to develop a culture of “either/or’’ trade-offs rather than a “yes and…’’ atmosphere AND to help provide transparency to the rest of the organisation on what is happening in product development.
• Prioritisation Frameworks:
• Product Ops can help the organisation choose the right prioritisation framework
• Use a combination of weighted scoring average and cost of delay at both portfolio and product level
• Using an agreed framework to guide trade-offs is essential, it helps reduce the loudest voice in the room

14 Defining Process for Product Managers

• Often roadmap formats are sporadic and they aren’t data-driven at all
• Audit our processes and templates to make sure we’re effective in our product capabilities
• Just Enough Process
• Governance is about ensuring you’re working on high ROI activities
• Process…
• equips the team with skills and tools needed to do their work
• helps onboard new PdMs and grow a strong team
• Don’t standardise every process and overwhelm your teams. But there are areas where it helps:
• things that affect cross-functional areas
• encouraging consistent practices across teams
• Some core areas should be standardised:
• idea management
• roadmapping
• product tool kits
• onboarding
• Idea Management:
• Systems to track of where the ideas came from in order to make sure people don’t lose the context of the why behind the what
• Product Ops can help establish a process that gets the right information to the right teams, and communicates back the status of the ideas to the relevant partners
• To do this we need to answer:
• Where can cross-functional partners and customers submit requests or ideas?
• How do we make sure the ideas are submitted in a format that is useful?
• How do we communicate the progress or status of ideas back?
• You can use a dedicated tool (like ProdPad) or start with a form.
• Shape requests so they focus on the problem not the solution
• Consider a Mad Libs-style form that guides stakeholder to the real problem and provides the necessary context for informed decision making
• Keep submitters informed of the status. If not actioning a request, explain why and provide the criteria that led to this decision.
• Roadmapping
• Everyone’s favourite debate. What format do we use? Who has access to the roadmap? How far out should the roadmap go? What level is helpful versus harmful?
• Product Operations don’t influence what goes in the roadmap, but they can help bring some simplicity and structure to how they’re shown and communicated
• There isn’t a perfect roadmap structure, companies need different levels and varieties of roadmaps to suit different stakeholders.
• Product Ops can align teams on which kinds of roadmaps are needed and how to produce them
• Roadmaps are a communication tool. To figure out which ones are right for your company, think about your audience and what they need to know…
• Product Teams: Highly detailed, commitments from engineering by quarter, discovery and delivery status, and are usually a quarter in length.
• Sales teams: less detail big-picture items that address problems and rough timeline on releases (either quarterly or half year). This is where the narrative/value proposition for each feature to customers is important to include as well.
• Leadership: Focus on the ‘initiative to strategic intent’. Used to talk about dependencies and capacity planning, and follow quarterly timelines.
• Product Ops can help create the format needed to communicate these effectively and find a place where they are easily accessible to those who need them.
• Roadmaps items should be tied back to the rationale for doing it
• Product Ops can ensure the relevant information is included to effectively communicate the roadmap, and to keep it up to date.
• Sales team’s often don’t intentionally trying to overpromise, they often can’t tell what stage of product development an idea is at.
• Standardising product development state language can help…
• Discovery: exploring but not validated the problem or solution. Slim chance they’ll be developed
• Alpha: problem validated, but software not been built. Develop a solution for a small group of users. Lots of iteration. Solution isn’t final
• Beta: solution is validated, but teams need to make sure it scales well. Launching to a limited group and monitoring. Likely to be launched within the quarter
• General Availability: launched in product and available to any customer
• Product Toolkits and Templates:
• Product Ops can guide teams toward more consistency and reducing the effort around how to do the work.
• Toolkits and templates provide guidance on methods, expectations (e.g., speak to three to five customers), and help the teams focus on the 10X work, not the minute details.
• Take stock of what toolkits could be useful to standardise (consider the product development lifecycle, and the update cadence) .
• Toolkit and Template questions:
• Acquire site licenses for Product Management tools:
• What type of information currently gets shared outside the product team and when?
• What information is not getting shared consistently and for this reason, causing problems?
• Who is the audience for each of these templates?
• How do we standardise how other teams work with us?
• Sample Discovery Toolkit
• Experiment Findings: A doc that describes the hypothesis to be tested, the experiment that was run, the results, and next steps. Discussed by product team and stakeholders and kept in a wiki, open to anyone in the company.
• Personas: Personas and a persona template.
• Discovery Software: Prototyping, user research and A/B testing \
• If teams are using many software solutions, find the best, consolidate and procure licences for everyone
• If there’s currently no software, analyse the market and procure one for everyone
• Strategy Toolkit
• Strategy Memos: 2-3 page docs for strategic intents and product initiatives. They are a way of introducing a new concept for feedback and solidified thereafter for reference.
• Product Visions and Briefs: Product briefs targeted how the solution should work and how customers would use it. A brief can be accompanied by a prototype or vision deck
• Strategy Reviews: Strategy review templates
• GTM Toolkits:
• GTM Materials: Release template. Checklist (training material, pre-launch activities)
• Release notes:
• Product demos for company
• Onboarding and training:
• Onboarding and tool setup
• Basic training
• Pairing up with a product manager
• Standardised templates and toolkits
• Access to and training on the tools they need to do their job
• Community of practice:
• Lunch and Learns
• Demos
• External events, conferences
• Selecting and enabling consistent professional development activities, such as targeted skills

Chapter 15 Tools of Enablement

• Product teams can place an unhealthy amount of reliance upon tools: “Once we have this software, roadmapping will be solved!
• Tools enhance processes and practices, they don’t replace them
• Form a cross-functional working group to review, vet, and recommend tools:
• Create a consistent appraisal process that takes into account:
• Product and cross-functional users
• Use cases for all the tools (they often go beyond product)
• Time & development resources needed to implement the tool
• Training and enablement
• How to measure utility and success of tool adoption
• Costs and budgeting
• Product tool stack:

• Tools are only as good as their inputs (e.g. Jira tagging and etiquette)
• There’s an always-tricky balance between governance and agility
• Product operations facilitate annual planning by…
• Designing the cadence of inputs, decisions, and communications
• Generating momentum and urgency in aligning initiatives
• Bringing together the right set of product people and stakeholders for decision-making
• Set the table for key meetings: fast-paced agenda + clearly-defined meeting outcomes
• Providing easy-to-follow templates to promote a high level of engagement with a minimum level of effort

Example Planning Process

• Write down ALL the things you’re doing - have a joint view of product, engineering and design
• Have a 4-hour ‘1 Pager Rager’
• Each VP had to do 4-5 initiative deep-dives
• Group then upvote initiatives
• Get on the same page about priority and scope
• Get general consensus about prioritiation for the year
• Then you need to facilitate two things at the product team level…
• OKR setting
• First pass at resourcing plan
• Expect first attempts to exceed your actual capacity
• You’re probably doing too much?
• Where can you extend timelines?
• Where can you reduce scope?
• Where can you make an impact without development?

• For leadership to digest the resourcing plan you might need to categorise a large number of initiatives into a smaller number of themes/investment categories.
• Before meeting you might want to poll the attendees on how they would allocate resources…

• Get all of the relevant product and engineering leads into a room to discuss allocations:
• Have people who can speak to what is being prioritised
• Work with initiative leads to prepare a brief overview of each initiative and the related OKRs
• Get executive alignment before fully socialising the plan
• Roadmap meetings:
• Why the initiative is exciting. Why it matters. Why people should care.
• How it was going to impact roadmaps.
• Create a hype slide
• Save the detail for later
• Review the first draft annual plan with cross-functional stakeholders
• Set meetings with other big functions inside the company
• Get them to come with their own list of priorities
• Regular checkins = more alignment and collaboration

Providing structure for alignment:

• Template for initiative one-pagers
• Framework to assign initiative owners and review one-pagers
• Technology OKR tracker
• Bottoms-up initiative resourcing estimates
• Pod roadmap templates

Creating digestible content for every stage of planning:

• Rough “everything” draft, socialized with technology leadership
• Technology investment allocation slide for the leadership committee
• Initiative deep-dive slides
• Pod roll-up reports and quarterly updates to tech leadership about progress against the plan\

Running tight, productive meetings (including prep work and facilitation):

• Planning kickoff with the product and engineering departments
• “One-Pager Rager” with technology VPs
• “Sharpen the pencils” meeting with CPO & CTO
• “First draft review” with leadership committee Roadmap overview meeting with the product and engineering departments
• “Cross-functional cross-check” meetings with key stakeholders
• “Final draft” review with leadership committee

Getting Started with Process and Practices

1. Assess Your Current-State Product Operating Model Components
• Roles and responsibilities
• Process for product teams
• Guidelines for working with other teams
• Governance and annual planning

What exists to day, what’s missing. Draft the outstanding operating model components and refine it with your CPO to provide alignment, clarity, and efficiency.

2. Create decision-making forums
• A meeting map will help you understand the decision-making and update opportunities and their cadences
• Start with what needs to happen on an annual basis, and then cascade from there.
• Who should attend?
• What is the focus of each meeting?
• What will and won’t be discussed?
• What are the desired outputs of each meeting?
• Get a clear view of what’s happening today, start developing the ideal state that’s more effective
3. Map out bi-directional feedback
• Map out how customer feedback gets back to the product team and implementation
• Map out the path from the product team to the customer (communicating updates)

Part 5: Introducing Product Ops at Your Organisation

• Initially, you need to drum up demand and help people understand what Product Ops is
• Through surveys measure how people in your organisation perceive the value of product management → make them health metrics on a dashboard

16. When and Where to start

• As you grow, strategies become more complex, you work on more things, and it’s hard to keep track of them all. That’s when product ops can make a massive difference.
• If you know you need product operations, you need to decide what pillar to start with.
• To do that, follow your biggest pain point:

17. Getting Buy-in

• Making the business case for Product Ops?
• State the pain points
• Make the impact of the pain points clear
• Lost revenue
• Delays in strategic alternatives (due to lack of data)
• Thin roadmaps with no quantitative or qualitative inputs leading to outputs that don’t achieve outcomes
• Explanation of Product Operations:
• Product operations is the discipline of helping your product management function scale well—surrounding the team with all of the essential inputs to set strategy, prioritise, and streamline ways of working. As companies scale, they face difficult product challenges. A product operations function can help us navigate these challenges by focusing us on outcomes, connecting those outcomes to actionable activities, and promoting best practices.
• There are three product operations pillars: Business and Data Insights, Customer and Market Insights, and Governance and Operating Model.
• We would benefit from strengthening and supporting [PILLAR NAME] first.
• A long list of companies have successfully strengthened product functions by implementing Product OPs (Uber, Stripe… etc)

18. Common Objections: How to Respond

19. Building Consensus

• PMs don’t always buy in. There’s often a concern Product Ops will take over. BUT a product operations team doesn’t make the decisions, it enables the decisions to be made.

• The product ops team acts like a product team and their customers are the Product Managers

20, 22. How to win them over

• The key to influence is getting the value proposition right for your audience
• Get design and research onside by helping product managers self-serve:
• Research repository, interview training, user access systems
• Get sales and marketing should share what customers want in exchange for transparency into roadmaps and product metrics.
• Get data science on side by making sure their insight makes it into decision making forums.
• Customer support can collect, structure and distribute customer feedback → so the product team can act on it and improve the product
• Get engineering onside by bringing them into roadmap planning earlier.
• Practical tips:
• Go on a listening tour → 35 interviews. Identify highest needs and pain points.
• Speak to 15-20 people from across the organisation. What’s painful for you as it relates to working with product management
• Cluster for impact. If you could fix just 1 or 2 things for each team, what would product operations work on?
• Identify impact and effort
• Quick Win Ideas
• Create a product newsletter to create visibility and build trust.
• Create a product launch template and process
• Close the loop on requests. If you action a stakeholder request, follow up afterward
• Tips for starting:
• Start small, do it in one team first, check the pain points, iterate and improve.
• Find promotors who are brought into the vision.
• Say no, and be clear about what you can achieve with your current bandwidth
• Map out a vision for how Product Ops could grow
• In a small team, you set the standard and the tone. Solve hard problems, then speak about it.
• Think about the intersection of what product ops can do, and what’s most strategically important for the company
• Secure executive support
• Focus on all types of data
• Get to impact quickly
• Balance process with agility
• Consider a roadshow. You need to be embraced by the organisation…
• What is product ops and why it helps
• How product ops will work with each cross-functional department
• Potential outcomes we can achieve
• Case studies and examples of other organisations
• Your roadmap
• You need to connect product data and customer insights with business-impacting financials
• How Product Ops Scales

• What to look look for in a Product Ops leader:
• Process-oriented
• Able to break down problems and drive large complex programs
• Has motivated and led teams
• High emotional intelligence to work cross-functionally with leaders
• Curiosity for problems and dogged approach to solve them
• Evidence-based storyteller
• A vision for quick wins and long-term view
• Embedded vs shared service model (dedicate to a squad or have a core team?)
• A central model will result in more process and standardisation but will scale better
• An embedded model allows for more tailored solutions, but can reinforce silos
• Central processes allow you to raise the tide for all product teams, gives you a lot of leverage with a few people
• If you have a central team, you’re still going to have to prioritise teams

33. Activating Product Operations

• Product Ops is the discipline of helping product management scale. Product Ops equips product managers with the tools they need to make good quality decisions
• Product Operations build a system that allows product managers to focus on their product
• Three pillars of product operations:
• Business and Data Insights
• Customer and Market Insights
• Process and Practices
• Define how you’ll measure success at different levels:
• Cycle times, throughput, ideas generated, ideas in product, how many iterations after launch to achieve positive results, # experiments that are conclusive
• Cost savings, time reductions, engagement surveys, team health, improved decision making
• Questions:
• Do product leaders feel more connected to product teams?
• Is important data available when needed?
• Are product managers spending more time with customers?
• Turnaround time of user research?
• Product manager satisfaction?
• Cross-functional relationships
• Tips for setting up product operations
• Have patience
• Start with product ops early, to establish a foundation
• Get buy-in from cross-functional data
• Understand the business and the pain points and opportunities