Transformed by Marty Cagan: Complete Summary of the Product Operating Model for Business Innovation

Introduction: What This Book Is About

In Transformed: Moving to the Product Operating Model, renowned product leader Marty Cagan and the Silicon Valley Product Group (SVPG) team provide a definitive guide for companies seeking to innovate like the world’s top tech organizations. This book addresses the most common question Cagan has received over 20 years: “How can a traditional company successfully change to work like the best?” It moves beyond the “what” and “why” of great products, covered in INSPIRED and EMPOWERED, to deliver the “how” of organizational transformation.

The book is an essential resource for CEOs, executives, product leaders, and team members who recognize the urgent need to evolve beyond outdated feature-factory and IT-centric models. Cagan demystifies the Product Operating Model, a conceptual framework based on the first principles that drive companies like Amazon, Apple, and Netflix. Through compelling case studies from companies like Adobe, Carmax, and Trainline, the book proves that this difficult transformation is not only possible but essential for survival and growth in a world of rapid technological change.

This summary provides a comprehensive, chapter-by-chapter breakdown of every core competency, concept, and technique presented in Transformed. You will learn the three critical dimensions of transformation: changing how you build, how you solve problems, and how you decide which problems to solve. We will cover the specific skills required for product managers, designers, and engineers; the principles behind product strategy and discovery; and actionable tactics for overcoming the inevitable objections from every corner of the organization. This complete guide captures the book’s entire blueprint for turning your company into a product-led powerhouse.

---

Related top book summaries:

• Zero to One – Complete Book Summary & All Key Ideas
• Your Next Five Moves – Complete Book Summary & All Key Ideas
• Working Backwards – Complete Book Summary & All Key Ideas
• Why Simple Wins – Complete Book Summary & All Key Ideas
• Why Machines Learn – Complete Book Summary & All Key Ideas

View all 200+ book summaries

---

PART I: Introduction

Chapter 1: Who Is This Book For? – Understanding the Audience for Transformation

This book is written for anyone involved in helping their company transition to the Product Operating Model. This includes product team members, product leaders, senior executives like the CEO and CFO, and other stakeholders who are impacted by this significant shift.

A common misconception is that the product model only applies to “tech companies.” However, Cagan clarifies that a tech company is not defined by what it sells but by how it powers its business. Companies like Tesla (cars), Netflix (entertainment), and Amazon (retail) use technology as the core engine for design, operations, and growth. Transformed is for any company, regardless of industry, that believes technology should be at the heart of its business strategy.

The book directly answers the question of how a traditional company can bridge the gap between its current operations and the methods described in Cagan’s previous books, INSPIRED (for product teams) and EMPOWERED (for product leaders). It provides a roadmap for navigating the substantial and often difficult changes required to compete in an era of rapid technological advancement.

Chapter 2: What Is a Product Operating Model? – Defining the New Way of Working

The tech industry often struggles with standardized terminology. To provide clarity, Cagan defines the core concept of the book.

What the Product Operating Model Is and Isn’t

The Product Operating Model is not a rigid process or a single methodology. Instead, it is a conceptual model based on a set of first principles that the best product companies believe to be true. These principles guide how they operate, such as prioritizing innovation over predictability and embracing experimentation. The ultimate goal is to consistently create technology-powered solutions that customers love, yet work for your business. From a financial perspective, it’s about maximizing the return on your technology investment.

This model is sometimes referred to as being “product-led” or “product-centric,” but those terms can misleadingly imply that the product organization is taking over. Cagan emphasizes that the product model is about a new way of collaborating across the entire company. The book refers to the company’s current way of working as the prior model and the goal state as the product operating model or simply the product model.

Defining a “Product” in This Context

The term “product” in this model is broad and not limited to customer-facing applications. It includes:

• Internal tools used by employees to serve paying customers.
• Platform services that other products are built upon.
• Back-office systems that provide critical data.
• Physical devices that are powered by software.

The product model applies to any team that is building technology-powered products and services, regardless of whether they are a small component of a larger system or a complete, standalone offering.

Chapter 3: Why Transform? – The Driving Forces Behind Change

Companies embark on the difficult journey of transformation for three primary reasons, often in combination.

A Competitive Threat

Nearly every industry has been disrupted by new competitors that leverage technology to provide better solutions for customers. The rise of Generative AI is just the latest example of a disruptive technology reshaping competitive landscapes. Companies in industries from finance and healthcare to automotive and retail realize their old strategies and tools are no longer sufficient to compete against modern adversaries. This existential threat is a powerful motivator for change.

A Compelling Prize

Leaders and investors see the immense financial rewards and market valuations of companies that have mastered consistent innovation. The success of companies born in the product model and those that have successfully transformed creates a compelling prize that motivates executives and employees to pursue this path. The promise of significant growth and profitability is a strong incentive to undertake the transformation effort.

Frustrated Leaders

Many leaders are frustrated with pouring massive amounts of money into technology efforts with little to show for it. They are tired of constant cost overruns, disappointing results, slow delivery times, and a culture of blame. They see other companies achieving more with less and want to learn if those methods can be applied to their own organization. This frustration with wasted investment and poor outcomes often pushes a company to seek a better way of working.

Chapter 4: A Typical Transformation – A Cautionary Tale of Failure

Most companies try to transform at least once and fail before they realize the depth of the challenge. Cagan presents a common story of a financial operations company that tried to change but ultimately failed, highlighting the typical pitfalls.

The Initial Push and Flawed Execution

The company, facing new competition and slowing growth, hired a new CEO with a mandate to reinvigorate the brand. The CEO diagnosed the problems: a sprawling organization, heavy technical debt from acquisitions, and frustrated customers. She initiated several changes, including centralizing the organization, insourcing engineering, and creating a new product unit.

However, the execution was flawed from the start. To save money, the company retitled business analysts as product managers without providing the necessary training or assessing for the required competencies. This is a critical and common mistake. Hiring 600 engineers proved expensive and slow, and the new engineers were shocked by the level of technical debt. Leadership, unwilling to fund a major replatforming effort, pushed for faster roadmap delivery on a broken foundation.

The Downward Spiral into Bureaucracy

After two years, with things moving slower than ever, the CEO concluded the problem was engineering’s inability to deliver predictable results. The company then made another fatal error: it shifted focus to predictability over innovation.

A formal, structured engineering process was implemented, leading to longer release cycles. To manage these high-stakes releases, a layer of program managers was added, increasing bureaucracy and control. Costs continued to rise while releases became infrequent. Competitors thrived, key engineering talent resigned, and customer retention dropped. The transformation had failed, costing millions of dollars and ultimately the CEO her job. This story serves as a stark warning about the consequences of a superficial or misguided transformation effort.

Chapter 5: The Role of the CEO – The Most Critical Factor for Success

The single most important lesson from 20 years of helping companies transform is the absolutely critical role of the CEO. While the CEO doesn’t need prior experience with the product model or need to spend a lot of time on the transformation itself, her active and visible support is non-negotiable.

Why the CEO Must Be the Chief Evangelist

Transformation is not just an IT or product department initiative; it impacts the entire company, including sales, marketing, finance, HR, and legal. Not every leader in these departments will be enthusiastic about the changes. Some will resist, either passively or actively, to protect their current responsibilities or out of a preference for the familiar.

These stakeholders all ultimately report to the CEO. As legendary coach Bill Campbell said, “The company cares about what the leader cares about.” If the CEO delegates the transformation to a CIO or Chief Transformation Officer, stakeholders who don’t report to that person will look to the CEO to see if the change is truly a priority. Without the CEO’s unwavering support, resistance from other parts of the business will stall and ultimately kill the effort.

The CEO must be the chief evangelist for the product model. If she is unwilling to take on this role, the company should reassess its readiness to transform. The good news is that a successful transformation benefits everyone: marketing has more to promote, sales can sell more, employee morale improves, and financial results are clear.

Chapter 6: A Guide to TRANSFORMED – How the Book Is Structured

This book is designed to prepare you for the difficult but achievable journey of transformation. It is not a one-size-fits-all recipe but a guide filled with case studies, principles, and practical techniques. The book is organized into several parts, each building on the last.

The Core Components of the Book

• Transformation Stories: Detailed case studies from companies like Trainline, Datasite, and Adobe show that successful transformation is possible.
• Innovation Stories: Examples from companies like Carmax and Kaiser Permanente inspire by showing what is possible once a company has transformed.
• Part II: Transformation Defined: A comprehensive definition of the product operating model across three dimensions of change.
• Part III: Product Model Competencies: A deep dive into the new skills required for product managers, designers, and engineers.
• Part IV: Product Model Concepts: An explanation of the foundational concepts of the product model, including product teams, strategy, discovery, and delivery.
• Part VI: The Product Model in Action: A look at how the product organization partners with customers, sales, marketing, finance, and executives.
• Part VIII: Transformation Techniques: Practical methods for guiding the organization through change, including assessments and adoption tactics.
• Part X: Overcoming Objections: A guide to addressing the legitimate concerns that arise from every part of the company.
• Part XI: Conclusion: A summary of the keys to a successful transformation.

A Note of Tough Love for Product Leaders

Cagan emphasizes that product leaders have as much work to do as senior executives. Many product leaders mistakenly believe that if executives just change their ways, everything will be fine. They complain about weak product managers, not being empowered, and untrusting stakeholders, without realizing these problems are often a consequence of their own inaction. A product leader must take responsibility for raising the skill level of their people, earning credibility, and changing hearts and minds. The transformation starts with the product organization raising its own game.

PART II: Transformation Defined

Chapter 7: Changing How You Build – From Projects to Products

The first dimension of transformation is a fundamental shift in how technology work is executed. Traditional companies operate on a project model, where efforts are funded, staffed, and delivered as discrete projects. This model is inefficient and stifles innovation.

The Problem with the Project Model

In the project model, when a project ends, the team disbands, and much of the accumulated learning is lost. This leads to relearning things and repeating mistakes. Furthermore, teams that don’t have to live with the code they write have little incentive to avoid technical debt. This is similar to remodeling a house to sell versus to live in—shortcuts are common when you won’t be around to deal with the consequences. This way of working is expensive, slow, and rarely delivers the innovation needed.

The Shift to Continuous Delivery

The product model moves from projects to products. Products are managed as ongoing efforts, with teams continuously improving them for years. This requires a different way of building and deploying. Strong product companies release changes frequently in small batches, a practice known as continuous integration and continuous deployment (CI/CD).

The data clearly shows that releasing more frequently leads to higher quality and reliability. It is far easier to ensure a small number of changes are working correctly than to test a large “big-bang” release. A key benchmark for transformation is that every product team must be able to release at least once every two weeks.

Beyond “Fake Agile”

Many companies adopt Agile rituals and hire Agile coaches but still release only quarterly or monthly. This is “fake Agile” and delivers none of the real benefits. The goal is not to follow a process but to achieve the outcome: frequent, small, reliable releases. This requires investment in testing and deployment automation. Whether you call it Agile or not, the ability to deploy quickly is a non-negotiable foundation for the product model.

Chapter 8: Changing How You Solve Problems – From Feature Teams to Empowered Teams

The second dimension of transformation focuses on moving from being a “feature factory” to an organization that solves real problems. Many companies ship more features than ever but see no corresponding business impact because they are building the wrong things.

The Failure of Feature Teams

In the traditional model, feature teams are set up to serve the business’s stakeholders. Stakeholders create a roadmap of features they believe will solve problems, and the feature team’s job is simply to build them. The team is measured on output (shipping features), not outcomes (business results).

When a feature fails to deliver value, the team can claim they just built what they were told, and the stakeholder can blame the implementation. This creates a culture of low accountability and distrust. It also leads to an accumulation of “orphaned” features and technical debt, which slows the entire organization down.

Empowering Teams with Problems to Solve

In contrast, an empowered product team is given a set of problems to solve and desired outcomes to achieve. The team is responsible for discovering a solution that is:

• Valuable: Customers will buy or use it.
• Usable: Users can figure out how to use it.
• Feasible: Engineers can build it with the available time, skills, and technology.
• Viable: It works for the business (marketing, sales, legal, finance, etc.).

This model pushes decision-making down to the people closest to the technology and the users. It unleashes the power of empowered engineers, who are not just there to code but to help identify the best solution. When engineers, designers, and product managers collaborate directly with customers, true innovation happens.

The Role of Product Discovery and Outcome-Based Roadmaps

Empowered teams are measured on time to money (the time to achieve the necessary outcome), not just time to market. To achieve this, they use product discovery—a set of techniques for rapidly testing ideas with low-cost prototypes to find a solution worth building. This allows teams to iterate through ideas in days or weeks instead of months or years.

A practical tactic for transitioning is the outcome-based roadmap. This involves taking the existing feature roadmap and, for each item, defining the underlying problem it’s meant to solve and the desired outcome. This shifts the focus from features to results and helps wean stakeholders off demanding specific features and dates.

Chapter 9: Changing How You Decide Which Problems to Solve – The Role of Product Leadership

The third and most profound dimension of transformation is changing how the company decides which problems are the most important to solve. This moves the organization from being reactive and stakeholder-driven to being strategic and insight-driven.

Disrupting Traditional Product Planning

In most companies, product planning is an annual process where stakeholders lobby for their pet projects, often based on flawed business cases. The product model replaces this with a system driven by product leadership. This is the key to a company being able to disrupt itself before it is disrupted by others. It requires a fundamental shift in how strategic decisions are made.

The Power of a Customer-Centric Product Vision

Strong product companies are not driven by reacting to competitors or sales requests. They are driven by a compelling product vision that describes a future where they have meaningfully improved the lives of their customers. A product vision is a long-term goal (typically 3-10 years) that inspires and aligns the entire organization. It is the North Star that guides all product teams and serves as a powerful recruiting tool for attracting top talent.

Creating an Insight-Driven Product Strategy

While the vision describes the future, the product strategy identifies the most important problems to solve now. A strong product strategy is a force multiplier that maximizes the return on technology investment. It involves:

• Focus: Identifying the few key areas that will have the biggest impact on the business, rather than trying to do too much at once.
• Insights: Leveraging insights from four key sources:
  1. Quantitative data from product usage and business analytics.
  2. Qualitative insights from talking directly to customers.
  3. New enabling technologies that create new possibilities.
  4. Industry and technology trends.

The Essential Role of Product Leadership

This strategic work is the responsibility of product leadership (the leaders of product management, product design, and engineering). Many companies transforming to the product model have a major gap in this area. A “head of product” in a feature-team company has a completely different job than one in the product model. Product leaders are responsible for coaching their people, creating the product vision and strategy, and ensuring the teams have the context they need to make good decisions.

PART III: Product Model Competencies

Chapter 10: Product Managers – The Hardest Competency to Establish

The product manager role is consistently the most difficult new competency for a transforming company to establish. While many companies have people with this title, they are often retitled project managers or business analysts who lack the necessary skills for the product model. This is a primary reason why transformations fail.

The Core Responsibilities: Value and Viability

In the product model, the product manager is explicitly responsible for ensuring any solution addresses two critical risks:

• Value Risk: Will customers buy or choose to use it? This requires a deep understanding of users, customers, the market, and the competitive landscape.
• Viability Risk: Will this solution work for our business? This requires a deep understanding of how the business operates, including finance, marketing, sales, legal, and compliance.

A competent product manager must become an expert in the customers, the data, the business, and the industry. This level of expertise is far beyond the narrow scope of a traditional product owner or business analyst.

The Critical Need for Direct Access

To succeed, a product manager must have direct, unencumbered access to three key constituencies:

1. Users and Customers: To understand their problems and test potential solutions. No one—not sales, not marketing, not a user researcher—should be a gatekeeper.
2. Product Data: To make informed decisions based on how customers are actually using the product.
3. Business Stakeholders: To build trust and ensure solutions work within the constraints of the business.

The Dangers of Over-indexing on Domain Expertise

Companies often make the mistake of hiring product managers with deep domain expertise (e.g., hiring an insurance expert for an insurance product). While knowledge is important, pre-existing domain experience often comes with domain dogma—a set of ingrained beliefs about what will and won’t work. This dogma can be a major impediment to innovation. It’s better to hire strong product managers who can quickly learn the domain than to hire domain experts who can’t unlearn their biases.

Chapter 11: Product Designers – From Aesthetics to Experience

In traditional models, designers are often brought in at the end of the process to “make things pretty.” In the product model, their role is elevated and expanded significantly. They are no longer just visual designers; they are product designers responsible for the entire customer experience.

Design Is How It Works

As Steve Jobs famously said, “Design is not just what it looks like and feels like. Design is how it works.” A product designer in the product model is responsible for the holistic customer experience, which includes:

• Service Design: The end-to-end journey of the customer.
• Interaction Design: How users communicate with the technology.
• Visual Design: The look and feel that communicates the brand and aids usability.
• Industrial Design: For physical devices.

The most critical skill for most digital products is interaction design. The designer must understand how to create intuitive and engaging experiences that guide users to value.

The Designer’s Role in Product Discovery

Product designers are essential partners in product discovery. They work alongside the product manager and tech lead to discover an effective solution. Their primary role in this process is to express ideas in the form of prototypes. A skilled designer can create numerous prototypes in a week, allowing the team to rapidly test different approaches with users. This ability to visualize and test solutions quickly is what helps a team converge on a solution that customers love.

Chapter 12: Tech Leads – The Engine of Innovation

The role of engineers, particularly senior engineers, is fundamentally different in the product model. They are not just implementers; they are co-creators of the solution.

Empowered Engineers Drive Innovation

Of all the principles in the product model, the most important is that innovation absolutely depends on empowered engineers. Because they work with the enabling technology every day, they are in the best position to see what is “just now possible.” The old adage that “the PM is responsible for the what and the engineer is responsible for the how” is a recipe for a feature factory.

This is why outsourcing engineering is so detrimental in the product model. Mercenary engineers, brought in late with little context, have no chance of innovating.

The Role of the Tech Lead in Product Discovery

While all engineers should be engaged in what is being built, it is essential that the tech lead on each team partners with the product manager and designer in product discovery. The tech lead is typically the most senior individual contributor engineer on the team and is responsible for assessing feasibility risk.

This doesn’t mean the tech lead spends all day in discovery. It usually requires less than an hour a day, but that time is critical. A few minutes of input early on can save weeks or months of wasted effort later. The tech lead’s job description must explicitly include the responsibility to help discover the right solution, not just build what is handed to them.

Chapter 13: Product Leaders – Providing Coaching and Context

Empowered product teams do not mean less leadership; they require better leadership. Product leaders—the managers of product management, design, and engineering—are responsible for creating an environment where teams can thrive. Their job has two main components: management (coaching and staffing) and leadership (providing strategic context).

Management: Coaching and Staffing

• Coaching: The single most important responsibility of any manager is to develop the skills of their people. This is not micromanagement; it is assessing strengths and weaknesses, creating a coaching plan, and spending quality time helping each person improve. First-level managers often spend up to 80% of their time on this.
• Staffing: Leaders are responsible for recruiting, onboarding, evaluating, and, when necessary, replacing team members. As Jeff Bezos says, setting a high bar for hiring is the single most important element of success.

Leadership: Providing Strategic Context

Instead of command and control, product leaders lead with context. They provide the teams with the information necessary to make good decisions. This strategic context has four key components:

1. Product Vision: The inspiring, long-term (3-10 year) goal of how the company will improve the lives of its customers.
2. Team Topology: The structure of the product teams, designed to maximize empowerment and minimize dependencies.
3. Product Strategy: The plan for achieving the vision, which identifies the most critical problems to solve now based on focus and insights.
4. Team Objectives: The specific problems assigned to each team (often quarterly, using a framework like OKRs) that derive from the product strategy.

The final critical role of product leaders is ongoing evangelism of the product model and the strategic context across the entire organization.

Chapter 14: Innovation Story: Almosafer – Thriving Through a Pandemic in the Middle East

Almosafer, a travel company based in Saudi Arabia, transformed to the product model in 2018 to better serve the unique needs of its regional customers. By building a strong digital team, they developed the muscles for continuous customer interviews, data analysis, and rapid prototyping. This allowed them to grow their airline business to over a billion dollars.

When the COVID-19 pandemic shut down international travel, Almosafer used its new capabilities to pivot. The team identified a critical unmet need: a way for families to safely gather outdoors. They focused on “istirahas,” traditional private outdoor resting places. There was no existing system for finding or booking these venues.

The product team quickly developed a new marketplace offering for istirahas. They worked with partners to build supply while simultaneously discovering the right customer experience through remote research and prototyping. The new offering was a success, establishing a new and rapidly growing category for the business. This innovation not only provided a real service during a time of need but also helped Almosafer achieve a remarkable 70%+ market share in its region, proving that a local player with strong product skills can outcompete global giants.

PART IV: Product Model Concepts

Chapter 15: Product Teams – The Foundation of the Product Model

The empowered, cross-functional product team is the fundamental unit of the product model. Its work is guided by four core principles.

Principle: Empowered with Problems to Solve

An empowered product team exists to solve problems in ways that customers love, yet work for the business. They are assigned problems, not a list of features to build. The team is cross-functional, typically consisting of a product manager (accountable for value and viability), a product designer (accountable for usability and experience), and a tech lead with several engineers (accountable for feasibility and delivery). This “product triad” has the necessary skills to discover and deliver effective solutions.

Principle: Outcomes over Output

Product teams are held accountable for business results (outcomes), not just shipping features (output). The focus is on time to money over time to market. This means the team’s job is not done when a feature is shipped; it’s done when the desired business outcome is achieved. This principle incentivizes teams to iterate until they succeed and may even lead them to remove functionality if data shows it improves results.

Principle: Sense of Ownership

To feel truly empowered, teams need a strong sense of ownership. This is achieved by giving them responsibility for a meaningful part of the product, whether it’s a whole product or a significant component of a larger one. This ownership covers the entire lifecycle, from product discovery to product delivery, including bug fixes and optimization. Separating discovery and delivery into different teams is a critical anti-pattern that destroys ownership and motivation.

Principle: Collaboration

True collaboration is not consensus, democracy, or compromise. It’s about a product manager, product designer, and engineers working together intensely to find a solution that is valuable, usable, feasible, and viable. Decisions are deferred to the person with the relevant expertise: the tech lead for technology, the designer for user experience, and the product manager for business constraints. This collaborative process, often centered around a prototype, is where the magic of innovation happens as the team leverages its collective skills to solve for all constraints simultaneously.

Chapter 16: Product Strategy – How to Decide What’s Important

Product strategy is how you decide which problems are the most important to solve to make the product vision a reality. It’s about making smart choices to maximize the impact of your product teams.

Principle: Focus

As Steve Jobs said, focus means saying no to the hundred other good ideas. Most companies try to do too much at once, diluting their efforts. In the product model, product leaders work with executives to identify the two or three most important goals for the business. This disciplined focus is essential for making meaningful progress. The product vision serves as a key tool for maintaining focus; if an idea doesn’t move the company closer to the vision, it should be questioned.

Principle: Powered by Insights

A strong product strategy is powered by insights from four key sources:

1. Data Analysis: Understanding how customers use and buy your products.
2. Customer Conversations: Understanding their context, problems, and what it would take for them to switch solutions.
3. Enabling Technologies: Identifying what is now possible that wasn’t before.
4. Industry Trends: Learning from the competitive landscape and changing customer expectations.

Product leaders are immersed in these insights and are responsible for aggregating and analyzing them to find points of leverage.

Principle: Transparency

Because product leaders are making critical decisions about what the company will and won’t work on, they must be transparent about the data and reasoning behind their strategy. This builds trust with stakeholders and ensures the entire organization is aligned. Executing a product strategy requires cooperation from across the company, and that cooperation depends on buy-in.

Principle: Placing Bets

Product strategy is not a science. Not every effort will succeed as planned. Experienced product leaders understand this and manage their work as a portfolio of bets. If a problem is critically important, they might assign it to multiple teams. They manage risk by placing a series of bets each quarter, with the goal of maximizing the likelihood of achieving the company’s annual business objectives.

Chapter 17: Product Discovery – How to Find Solutions Worth Building

Product discovery is the process of figuring out the best solution to a problem before committing the time and expense of building it. It is the key to accelerating time to money and is guided by four principles.

Principle: Minimize Waste

The primary goal of product discovery is to avoid the waste associated with building things nobody wants. Data shows that 70% to 90% of features built in the traditional IT model fail to deliver the desired business results. Product discovery aims to ensure that when engineers are asked to build something, there is sufficient evidence to believe it will succeed. This is achieved by rapidly testing ideas to find a solution worth building.

Principle: Assess Product Risks

Before building anything, the team must assess and address four key risks:

• Value Risk: Will customers buy or use it?
• Usability Risk: Can users figure out how to use it?
• Feasibility Risk: Can we build it?
• Viability Risk: Will it work for our business (including legal, compliance, and ethical risks)?

Product teams are often the first to see potential ethical consequences of their work. They have a responsibility to identify these risks and seek alternative solutions.

Principle: Embrace Rapid Experimentation

The core of product discovery is a culture of rapid experimentation. Instead of assuming an idea will work, the team creates a quick, low-cost experiment (usually with a prototype) to test it. This allows for data-informed decisions rather than relying on opinions. Teams must be skilled in both quantitative techniques (like A/B testing) to see what is happening and qualitative techniques (like user interviews) to understand why.

Principle: Test Ideas Responsibly

While startups can often move fast and break things, established companies have revenue, brand reputation, and existing customers to protect. Product discovery in this context must be done responsibly. This means running experiments and collecting data while ensuring you protect:

• The company’s revenue.
• The company’s reputation.
• Existing customers from confusion or frustration.
• Colleagues in sales and customer success from being blindsided.

Techniques exist to test ideas conservatively while still learning quickly.

Chapter 18: Product Delivery – Building and Releasing with Confidence

Product delivery is about building, testing, and deploying solutions to customers reliably and efficiently. It is built on modern engineering practices that ensure the product is a dependable service.

Principle: Small, Frequent, Uncoupled Releases

To ensure reliability, teams deploy small, frequent, uncoupled releases. At a minimum, each team should release every two weeks; strong teams release multiple times per day (CI/CD). This seems counterintuitive, but smaller releases are easier to test for quality and to ensure they don’t introduce regressions (unintentionally breaking something else). If a problem does occur, it’s much easier to identify the cause in a small release. This approach is better for both the company and the customer, as it avoids disruptive “big-bang” releases.

High-Integrity Commitments for Predictability

While the product model prioritizes innovation, sometimes a specific deliverable is needed on a specific date. These are called high-integrity commitments. A team can safely make such a commitment only after they have done sufficient product discovery to understand what’s required and address the major risks. The commitment must come from the people who will do the work—the engineers—and should be approved by the head of engineering. This technique should be used judiciously for truly critical deadlines.

Principle: Instrumentation and Monitoring

• Instrumentation: To be accountable for outcomes, you must understand how your products are used. Every feature must be instrumented with telemetry to collect usage data. Without this data, you are flying blind.
• Monitoring (Observability): Instrumentation enables monitoring. Teams must continuously monitor the health and performance of their services to detect issues, often before customers do.

Principle: Deployment Infrastructure

Modern deployment infrastructure is essential for testing value. The most common way to do this is with A/B testing, which allows you to isolate the impact of a single new capability. This requires significant traffic to get statistically significant results quickly. Another key capability is feature flagging, which allows you to release a new feature “dark” (invisible to users) and then turn it on for specific segments of users when ready. This gives the team control over who sees what and when.

Chapter 19: Product Culture – The Beliefs That Drive Innovation

A strong product culture is the result of consistently applying the principles of the product model. It’s a culture defined by a set of shared beliefs about how to create great products.

Principle: Principles over Process

As companies grow, they often add processes to prevent mistakes. But as Jeff Bezos warns, if you’re not careful, the process can become the thing. Strong product companies value people over process. Instead of adding a process after a mistake, they provide coaching to help the person learn. This requires a culture where managers are coaches who provide their teams with the skills and strategic context to make good decisions.

Principle: Trust over Control

The product model is a fundamental shift from a top-down, command-and-control culture to one based on trust. It means empowering teams with problems to solve instead of micromanaging them with roadmaps of features. It means leading with context, not control. This requires leaders who are self-confident enough to let their teams take responsibility and credit for their work.

Principle: Innovation over Predictability

Many companies design their organizations for predictability, focusing on shipping a set of features on a timeline. But as Henrik Kniberg says, “100% predictability = 0% innovation.” A culture focused on predictability will never innovate because real innovation is inherently unpredictable. The product model prioritizes innovation, recognizing that this is what drives long-term success. Predictability can be handled when needed with high-integrity commitments, but it should not be the primary goal.

Principle: Learning over Failure

A fear of failure stifles innovation. In product discovery, there is no success or failure, only learning. The goal is to learn what works and what doesn’t in a fast, low-cost way so that you don’t fail in production. A strong product culture understands that some efforts will still fail, and it embraces the learning and the people who were willing to take the risk.

Chapter 20: Innovation Story: Carmax – Accelerating Omnichannel Retail in a Crisis

CarMax, the largest used car retailer in the US, had already begun its transformation to the product model before 2020. When the pandemic hit, stay-at-home orders meant their physical stores, which held billions of dollars in inventory, faced severe restrictions. Sales dropped by over 75%.

The company needed to rapidly accelerate its move to an omnichannel retail experience, allowing customers to do everything online. This was no longer a growth opportunity; it was a business-critical necessity.

Product teams, already working on omnichannel capabilities, went into high gear. They had to discover and build solutions for every stage of the transaction, including online financing, instant trade-in offers, electronic document signing, and arranging for curbside or home delivery. A key challenge was ensuring pricing accuracy and clearly communicating the condition of the car to maintain trust.

The teams used rapid prototyping and rolled out solutions regionally before going national. Within just six months of the pandemic’s onset, CarMax had a fully operational online car-buying and selling process. The company quickly recovered its lost revenue and emerged as an auto industry innovation leader, proving its ability to respond effectively to a major crisis.

PART V: Transformation Story: Trainline

By Jon Moore

When private equity firm KKR purchased Trainline in 2015, the UK rail ticket reseller was a legacy business with an outdated IT model. Engineering was outsourced, product management was non-existent, and the company operated on slow, eight-week release cycles. KKR brought in a new CEO, Clare Gilmartin, who hired Jon Moore as Chief Product Officer and Mark Holt as CTO to lead a dramatic transformation.

Changing How They Built

The first priority was to fix engineering. The team insourced talent, rewrote every job spec, and created a new tech lead role. The company’s on-premises data center was unfit for purpose and slated for demolition. In a remarkable 18-month effort, the entire platform was migrated to AWS, and the company moved to continuous delivery, releasing over 100 components a week. Engineers were now expected to understand customers and use the product extensively.

Changing How They Solved Problems

Moore inherited a team of “product owners” used to taking requirements from stakeholders. He focused intensely on coaching them in modern product management and discovery. A weekly meeting called “Weekly Wins” was established to create a safe space for teams to share insights, prototypes, and test data, which significantly improved communication and built momentum. The initial product strategy focused on two critical problems: mobile app usage and site conversion. A new mobile apps team, staffed with top talent, served as an internal bar-raiser, quickly achieving a dominant position in the App Store and showing the rest of the company what was possible with a focus on outcomes.

Investing in Design and Data

The design team was built with a bias toward high-velocity qualitative testing and prototyping. When finance initially rejected a request for more designers, Moore presented evidence of the improved business outcomes from teams that had strong design talent, and the hiring was quickly approved.

The company also made a significant investment in data science, building a team from scratch. This investment paid off during a hack day when a single engineer proposed a simple solution to help customers find less crowded trains: just ask them. The idea was validated with a live-data prototype, and the data science team built a feature that generated massive free publicity and attracted top engineering talent.

Changing How They Decided What to Solve

The team created a compelling product vision centered on solving the “Super Seven”—the top seven customer pain points uncovered through deep research. A key insight was that providing mobile tickets dramatically increased the frequency of rail travel and customer lifetime value. This insight formed the core of a product strategy that drove the company forward.

The transformation was a massive success. Just over four years after KKR purchased the company for under £500 million, Trainline went public with a valuation of just over £2 billion. The company had successfully repositioned itself as a technology leader in the travel industry.

PART VI: The Product Model in Action

Chapter 21: Partnering with Customers – A New Kind of Relationship

The product model introduces a new, direct, and collaborative relationship with customers. This relationship is built on a clear set of promises and interactions.

Promises to Customers

• No Premature Commitments: Product teams will not promise a date or deliverable until they have done sufficient product discovery to understand what’s required.
• Commitments from the Team: The only people who can make a promise are the members of the product team who will actually do the work.
• High-Integrity Commitments: When a date is required, the team will use a rigorous process to provide a commitment they can stand behind.
• General Solutions: The team’s job is to find a solution that works for the broader market, not just a single customer.

The Role of Discovery and Delivery

• Product Discovery: The team will engage directly with users and customers to deeply understand their problems and test potential solutions with prototypes.
• Product Delivery: The team promises to test solutions thoroughly, both to ensure new capabilities work and to prevent regressions. They will use modern design and deployment techniques to release changes in a way that is not disruptive to the customer’s workflow.

The ultimate goal is to create happy, referenceable customers who love the product so much they are willing to share their experience with others.

Chapter 22: Partnering with Sales – Aligning for Customer Success

The relationship between product and sales is one of the most interdependent in any company. In the product model, they move from being adversaries to being true collaborative partners.

Building Trust Through Collaboration

The key to a healthy relationship is building trust. This is best done by the head of product and head of sales spending quality time together in front of customers, and encouraging their teams to do the same. When a salesperson witnesses a product team discover a winning solution that the customer never imagined, and a product team sees how a salesperson navigates a complex sale, they develop a mutual respect and understanding.

Creating Referenceable Customers Together

The core of the product model is creating happy, referenceable customers. Product needs to work with sales to identify and develop these customers. When a company lacks referenceable customers, the sales team is forced to make promises for custom “specials” to close deals. By collaborating to create a base of satisfied customers, product and sales can break this cycle. The product model gives the sales organization—which is already customer-centric and outcome-based—a true partner with the same goals.

Chapter 23: Partnering with Product Marketing – The Go-to-Market Experts

The product marketing manager (PMM) is one of the product team’s closest and most critical partners. Their collaboration spans the entire product lifecycle.

Key Areas of Collaboration

• Market Understanding: PMMs provide access to industry analysts, competitive research, and market insights.
• Product Go-to-Market: The PMM is the expert on how to get a product into the hands of customers. Product and product marketing must work together to solve for both the product and its path to market.
• Customer Discovery Program: For new products or new markets, the product manager and PMM collaborate on a program to work closely with a set of prospective customers to discover a solution and create the initial referenceable customers.
• Messaging and Positioning: The PMM ensures that any changes to the product are communicated effectively.
• Pricing and Packaging: In most product model companies, product marketing owns pricing and packaging decisions, with input from the product teams.
• Sales Enablement: The PMM is responsible for creating the collateral and sales tools needed to equip the sales force.

Chapter 24: Partnering with Finance – From Cost Center to Profit Center

The relationship with finance is critical for funding the product organization and demonstrating its value. The key is to shift the conversation from cost-based projects to outcome-based investments.

Testing the Product Model

The conversation with finance should start by acknowledging that the old model of funding projects based on business cases has a poor track record of predicting returns. The proposal is to test the product model to see if it can deliver better results. This can be done conservatively with a few pilot teams.

A New Collaborative Model

In this new partnership, product and finance agree on a new way of working:

• Product’s Commitment:
  • Stop making up business cases and hiding behind feature roadmaps.
  • Be measured on business results, not shipping features.
  • Be transparent about what is known and unknown, and run low-cost tests to gather data before requesting larger investments.
  • Use a high-integrity commitment process when a reliable date is needed.
• Finance’s Commitment:
  • Move from funding projects to funding durable product teams that are held accountable for quarterly business results.
  • Support the need to staff new competencies, recognizing that insourcing critical roles often saves money in the long run.
  • Judge teams on business impact, not on shipping features.
  • Minimize the need for high-integrity commitments, using them only when truly necessary.

Chapter 25: Partnering with Stakeholders – From Subservience to Collaboration

Moving to the product model represents a significant change for stakeholders, who may be used to having direct control over technology resources. The new relationship is one of collaboration, not subservience.

Building Trust with Stakeholders

An empowered product team is responsible for creating solutions that customers love, yet work for your business. This means they depend on stakeholders from marketing, sales, finance, legal, and other areas to understand the business constraints.

The onus is on product leadership to ensure every team has a competent product manager who has done the work to understand these constraints. The product manager’s commitment to stakeholders is to:

• Learn their constraints: Engage directly with each stakeholder to understand their needs.
• Preview solutions: Before building anything, show a prototype of any potentially impactful solution to the relevant stakeholder to get their feedback.
• Focus on outcomes: Commit to pursuing the necessary business results, not just shipping features.

This collaborative process, built on trust and transparency, allows the team to find solutions that solve for both the customer and the business.

Chapter 26: Partnering with Executives – A New Kind of Engagement

The product model requires a different, higher-quality engagement with executives. It’s not about less interaction, but about changing the nature of those interactions to be empowering and effective.

A Framework for Executive Collaboration

• Decisions: Executives provide the strategic context (business strategy, financial parameters, etc.) that teams need to make good decisions. Teams, in turn, share the data and reasoning behind their decisions.
• Outcomes: Executives give teams problems to solve with as much freedom as possible. Teams take responsibility for delivering the necessary business outcomes.
• Disagreements: Executives encourage teams to explore counterintuitive ideas. Teams, in turn, promise to run responsible discovery tests to gather evidence for their proposals.
• Promises: Executives use high-integrity commitments judiciously, only when a date is truly critical. Teams, in turn, take these commitments seriously and do everything in their power to deliver.
• Surprises: Teams commit to previewing any potentially risky solution with executives before building it to avoid wasteful rework.
• Trust: The entire relationship is built on a foundation of mutual trust and a commitment to helping each other succeed.

Chapter 27: Innovation Story: Gympass – Pivoting to Wellness During a Crisis

Brazilian company Gympass provided corporate employees with access to a network of over 50,000 gyms. After transforming to the product model in 2018, they were on a strong growth trajectory. When the pandemic hit, the fitness industry was devastated, and gyms were forced to close.

Gympass was facing an existential crisis. Their product organization, however, had already discovered through user research that there was significant interest in wellness activities beyond the gym, such as meditation, nutrition, and at-home exercise. The team was tasked with quickly pivoting to provide a range of home-based wellness solutions.

They used a build-and-partner strategy, creating a platform but integrating with nearly 100 vertical fitness partners. The team used rapid prototyping to address the key risks: ensuring the solution was valuable to end-users and viable for both Gympass and its partners.

In a remarkable feat, Gympass rolled out the new offering to ten countries within four weeks. They went from zero to hundreds of thousands of users in a few months, more than doubling their corporate clients and revenue during the pandemic. Their valuation rose to $2.2 billion, a testament to their ability to innovate under pressure.

PART VII: Transformation Story: Datasite

By Christian Idiodi

When Christian Idiodi joined Merrill Corporation in 2018, the 50-year-old financial printing company was a traditional, sales-driven organization facing an identity crisis. It was saddled with legacy businesses, outdated technology, high debt, and a damaged reputation. The company had already failed at an outsourced transformation attempt.

The Root Causes: Sales-Driven Culture and Disempowerment

The core problem was that Merrill was a sales-driven company, where the sales organization owned the clients and therefore drove all decisions. Technology was subservient, leading to disastrous projects like a new platform that took six years and

        6million∗∗tobuildbutgeneratedlessthan∗∗6 million** to build but generated less than **6million∗∗tobuildbutgeneratedlessthan∗∗
      

30,000 in revenue. This culture created a disempowered, mercenary workforce. Engineering was outsourced, decisions were top-down, and the physical office space was designed for isolation, not collaboration. The company also suffered from a lack of focus, with a sprawling portfolio of acquired businesses that had no unifying synergy.

The Transformation: Building, Solving, and Focusing Anew

The transformation, led by a new product and technology leadership team, addressed the three dimensions of change:

• Changing How We Build: The fragile, on-premises legacy platform was replaced with a modern, microservices-based architecture on the cloud. This enabled faster, more reliable releases. An early win came when the team fixed a critical security bug for a major client in less than an hour, demonstrating the power of the new platform and turning a potential catastrophe into an inflection point.
• Changing How We Solve Problems: The company moved from funding projects to funding empowered, collaborative product teams. This required staffing new roles like product managers and designers and insourcing engineering. These teams were given problems to solve and were responsible for discovering solutions that worked for both the customer and the business.
• Changing How We Decide Which Problems to Solve: The company established a clear product vision and an insight-driven product strategy. This required making hard choices, including divesting several businesses to focus on the best opportunities.

In 2020, Merrill rebranded as Datasite, reflecting its successful transformation into a global, SaaS-based technology platform for the M&A community. The company’s revenue grew by over 30% in 2019, and today it is the industry leader, admired for its culture of innovation.

PART VIII: Transformation Techniques

Chapter 28: Transformation Outcome – What “Done” Looks Like

Transformation is never truly complete, as strong companies are always improving. However, there is a meaningful milestone that defines success: the ability to consistently deliver real results. The ultimate goal of moving to the product model is to build the organizational muscles necessary to identify and take advantage of the most promising opportunities, and to respond effectively to the most serious threats.

Companies that had transformed were able to adapt to the challenges of the pandemic and the rise of generative AI, emerging stronger than ever. The outcome of your transformation is not a new process; it’s a new capability to innovate and thrive in an unpredictable world.

Chapter 29: Transformation Assessment – Where Are You Today?

An honest and accurate assessment of your organization’s current state is the essential starting point for any transformation plan. This involves speaking with people at all levels, looking for evidence beyond words, and understanding the underlying principles, not just the surface-level processes.

High-Level Assessment Questions

• How You Build: How often do teams release? Are they independent? How are critical problems fixed? What is the level of team autonomy and technical debt?
• How You Solve Problems: How is work given to teams (features or problems)? Who is involved in defining the solution? How are solutions tested with customers? How is success defined (output or outcomes)?
• How You Decide Which Problems to Solve: Who decides what gets worked on? Is there a product vision and strategy? Are roadmaps driven by stakeholders or insights?

Detailed Assessment of Competencies and Concepts

The assessment then dives deeper into the specific product model competencies (product management, design, engineering, leadership) and concepts (product teams, strategy, discovery, delivery, culture). This detailed review helps identify the specific gaps that need to be addressed. A common pitfall to watch for is innovation theatre, such as corporate innovation labs that are disconnected from the delivery teams, which rarely produce meaningful results.

Chapter 30: Transformation Tactics—Competencies

Establishing the new product model competencies is one of the hardest but most foundational parts of the transformation.

Key Tactics for Building Competence

• New Job Definitions: Start by clearly defining the new roles and responsibilities. A “product manager” in the product model is a completely different job than a product owner or business analyst.
• Job Reset: For roles like product manager, it may be necessary to do a formal reset, where existing staff must re-qualify for the new, more demanding role.
• Role Balancing: Ensure you have the right ratio of product managers, designers, and engineers. This often means needing fewer but stronger PMs and more skilled designers.
• Dealing with Outsourced Engineers: Insourcing engineering is non-negotiable for the product model. Start by insourcing the tech lead for each team and then create a plan to bring the rest of the roles in-house over time.
• New Recruiting Practices: The hiring manager must own recruiting. Set up interview teams that know what to look for and can sell the new way of working to candidates.
• Assessments and Coaching Plans: Assess each person against the new job requirements and create a personalized coaching plan to help them develop the necessary skills.

Chapter 31: Transformation Tactics—Concepts

Once the competencies are being established, you can focus on implementing the product model concepts.

Key Tactics for Implementing Concepts

• Team Topology Review: The way product teams are structured is critical for empowerment. The start of a transformation is a good time to review and redesign the team topology, often moving from many small, dependent teams to a smaller number of larger teams with more end-to-end ownership.
• Driving Up Customer Interaction: Mandate that every user-facing product team conduct customer discovery sessions (interviews or prototype tests) three times per week, every week. This is the heart of the PM and designer’s job.
• Discovery Sprints: Use intensive, one-week discovery sprints (or design sprints) to teach teams the mindset and techniques of product discovery while tackling a meaningful problem.
• Create a Product Vision and Strategy: This is a leadership responsibility. If the leaders lack experience, a product leadership coach can facilitate a product vision sprint or product strategy sprint to create these critical artifacts.
• Portfolio Management: For companies with many legacy systems, conduct a portfolio review to categorize each system as sunset, sustain, or invest. This frees up resources to focus on the areas of new investment.
• Implement Team Objectives (OKRs): Use a framework like OKRs to assign problems from the product strategy to the product teams, making empowerment real.

Chapter 32: Transformation Tactics—Adoption

How you introduce change is as important as the change itself. These tactics help the organization absorb the new way of working.

Key Adoption Strategies

• Pilot Teams: Start the transformation with one or more volunteer pilot teams. This allows you to work out the kinks on a small scale before rolling out changes to the broader organization. The rest of the company can watch from the sidelines and get comfortable with the ideas.
• Product Model Dimensions: For large organizations with different priorities, you can have different groups focus on different dimensions of the model: one group on changing how you build, another on changing how you solve problems, and a third on changing how you decide which problems to solve.
• Top Down and Bottom Up: Have one coach or leader focus on developing the skills of the product teams (bottom up) while another focuses on the product leaders and strategic context (top down).
• Coaching Stakeholders: Pair a product coach with a willing and influential stakeholder to model the new collaborative relationship for the rest of the organization.
• Managing Existing Commitments: Create a plan for fulfilling prior commitments. This may involve having a subset of teams continue in the old model temporarily, or having each team manage a mix of old and new work.

Chapter 33: Transformation Evangelism – Beating the Drum for Change

Transformation is a long game, and it’s easy for an organization to lose focus. Continuous evangelism is required to maintain momentum.

The Transformation Plan and Continuous Communication

Create a written transformation plan with clear owners and accountability for each item. Then, execute on that plan with a constant drumbeat of communication.

• Continuous Evangelism: Product leaders must constantly communicate the product vision, strategy, and progress to teams, stakeholders, and executives.
• Celebrate Quick Wins: Publicly celebrate small but meaningful milestones, such as a team moving to two-week releases, killing a bad idea early, or achieving an important business result. This shows the organization what is possible.
• Monthly Progress Reports: Report on progress against the transformation plan at least once a month to show that the effort is real and is moving forward.

Guarding Against Transformation Setbacks

Even successful transformations can regress. Be vigilant against common threats, such as a new CEO who doesn’t understand the product model, the return of a command-and-control PMO, or a desire to revert to old behaviors when a business crisis passes.

Chapter 34: Transformation Help – Finding the Right Coaches

A company cannot learn a new way of working on its own. It needs people who can coach the teams and leaders. While the best long-term solution is for managers to be coaches, external help is often necessary to get started.

The Four Types of Product Coaches

1. Delivery Coaches: Experienced engineering professionals who help teams implement the practices needed for continuous delivery (CI/CD).
2. Discovery Coaches: Former product managers or designers who teach product teams the techniques of product discovery.
3. Product Leadership Coaches: Former heads of product, design, or engineering who coach leaders on creating product vision, strategy, and team topology.
4. Transformation Coaches: Senior leaders with experience guiding an entire company through the cultural and organizational changes of a transformation. They work directly with the CEO and executive team.

How to Find a Good Coach

Hiring the wrong coach is a common cause of failed transformations. You must hire coaches who have real-world experience doing the work they are being hired to teach. A delivery coach must have a track record of implementing CI/CD. A discovery coach must have been a PM or designer at a strong product company. A leadership coach must have been a product leader. The book profiles several trusted coaches—Gabrielle Bufrem, Hope Gurion, Margaret Hollendoner, Stacey Langer, Dr. Marily Nika, Phyl Terry, and Petra Wille—as examples of the type of experienced professionals to look for.

Chapter 35: Innovation Story: Datasite – Creating a Patented Redaction Tool

After its successful transformation, Datasite was positioned to innovate in ways it couldn’t before. A major news story about a poorly redacted legal document highlighted a critical need in the M&A community: a truly secure way to redact confidential information.

The product team recognized that existing tools were inadequate because they only masked data, leaving the underlying metadata vulnerable. The team needed to build a new tool that could completely remove both the data and its metadata.

An engineer, inspired by an approach used in Google Maps, came up with a novel technical solution. The team built a feasibility prototype to prove it could work. They then partnered with 12 customer discovery partners in Europe and North America to test and refine the user experience.

The result was a patented technology that could automatically and securely redact documents, with the ability to unredact them when necessary. This tool became a significant market differentiator for Datasite, providing real value and peace of mind to its clients and cementing its position as an industry innovator.

PART IX: Transformation Story: Adobe

By Lea Hickman

The transformation of Adobe from selling perpetual software licenses for its Creative Suite to a subscription-based Creative Cloud is one of the most financially successful transformations in industry history. The motivation was a perfect storm of existential threats.

The Motivation for a “Bet-the-Company” Change

Adobe was facing several challenges:

• Slowing Upgrades: The Creative Suite was mature, and customers were less compelled to upgrade with each new release.
• New Competition: Simpler, cloud-based tools like Sketch were gaining traction with a new generation of users.
• Technology Shifts: The rise of mobile devices and cloud services was changing how designers worked.
• The iPhone Effect: Steve Jobs’s 2010 open letter stating that Flash would not be allowed on iOS was a substantial blow.

The leadership team realized they needed to make a massive change. The key to getting the CEO, CFO, and the rest of the company on board was a compelling product vision. Lea Hickman, as the new head of product for Creative Cloud, led the creation of a “day in the life” narrative and a visiontype (a high-fidelity prototype of the vision) that showed how a new, integrated, cloud-based offering could dramatically improve the lives of their designer customers.

The Three Dimensions of Adobe’s Transformation

• Changing How We Build: The company had to move from 18-24 month waterfall release cycles to a continuous development and delivery model. This required significant architectural changes and a cultural shift for the engineering teams to embrace the responsibility of keeping a 24/7 cloud service running.
• Changing How We Solve Problems: The company moved from an engineering-driven culture to one of empowered, cross-functional product teams. This required elevating the product management role to be focused on product discovery and ensuring teams engaged directly with customers.
• Changing How We Decide Which Problems to Solve: The product vision guided an insight-driven product strategy that focused on two critical problems: creating a common identity system and enabling cloud-based file syncing.

The transformation impacted every part of the company, from how sales sold to how marketing communicated. The results were staggering. The Creative Suite had 6 million customers and

        2billioninannualrevenue.By2021,theCreativeCloudhad∗∗26millionsubscribers∗∗and∗∗2 billion in annual revenue. By 2021, the Creative Cloud had **26 million subscribers** and **2billioninannualrevenue.By2021,theCreativeCloudhad∗∗26millionsubscribers∗∗and∗∗
      

11.5 billion** in revenue. Adobe’s market cap grew from $13 billion to $269 billion.

PART X: Overcoming Objections

Chapter 36: Objections from Customers – Addressing User and Buyer Concerns

• “You must commit to building this specific feature.” Explain that you are committed to solving their problem, and product discovery will be used to find the best solution for the broader market. Use a high-integrity commitment process if a date is truly needed.
• “We need to see your product roadmap.” Share the product vision instead. It’s a better tool for communicating future direction and aligning on long-term goals.
• “We can only handle infrequent releases.” Explain that their pain is caused by infrequent “big-bang” releases. Small, frequent releases are less disruptive and higher quality. Use techniques like feature flagging to control when new capabilities become visible.
• “We are uncomfortable with you collecting usage data.” Reassure them that all data is anonymized and aggregated. Explain that this instrumentation is essential for ensuring the product is working correctly and providing value, much like the instruments in a cockpit.

Chapter 37: Objections from Sales – Bridging the Gap with the Front Lines

• “We talk to customers every day, so we should tell you what to build.” Acknowledge their valuable input, but explain that customers and salespeople don’t know what is technically possible. Innovation comes from combining customer needs with what technology now enables.
• “I need to make my numbers now. How does this help me this quarter?” Provide the sales team with referenceable customers who are using and loving the latest offering. This is the most powerful tool you can give them.
• “We need this ‘special’ feature to close a deal.” The head of sales should be the first filter for these requests. If a request proceeds, the product manager must understand the underlying problem and see if a general solution can be found that benefits the broader market.
• “I don’t want product teams contacting my customers and risking the relationship.” Direct access is non-negotiable, but product leaders must ensure their teams are coached on appropriate customer interaction. A user research coordinator can also help manage contact to avoid overwhelming key customers.

Chapter 38: Objections from the CEO and Board – Aligning with Senior Leadership

• “As CEO, I should be the one to decide what gets built.” Acknowledge their unique perspective, but explain that at scale, innovation depends on empowered teams who are closest to the technology and the users. The CEO’s role is to provide strategic context, not dictate solutions.
• “I need to know what will be released and when.” The product strategy should connect product work to business outcomes. Use high-integrity commitments for the few deliverables that have true deadlines.
• “The board wants to see a product roadmap.” The board wants to understand how the investment in product will drive business results. The product leader must connect the dots between the product strategy and the company’s financial goals.
• “How do I defend increasing investment in product over sales?” If the company has not yet achieved product-market fit, investing in sales is inefficient. Resources should be focused on getting the product right first.

Chapter 39: Objections from Line of Business – Partnering with Business Unit Leaders

• “I have P&L responsibility, so I should control the engineering resources.” The line-of-business (LOB) manager is a critical partner, much like a startup CEO. They should collaborate with product leaders on vision and strategy, but not directly control the resources, as this can lead to siloed, suboptimal decisions for the company as a whole.
• “The product team is repeating all the problem discovery I’ve already done.” In the future, include the product manager and designer in your initial customer interactions so the team can learn the problem space with you.
• “I should create the product strategy for my business.” The LOB leader’s input is essential, but the overall product strategy should be created by product leaders looking holistically across all business units to maximize the value for the entire company.

Chapter 40: Objections from Customer Success – Supporting Those on the Front Lines

• “Product teams don’t seem to care about the problems we see every day.” The customer success team should maintain a single, live top-10 list of the most serious customer pain points. This gives the product teams a clear, prioritized signal of what needs to be fixed.
• “How are we supposed to know when things are changing with the product?” Product teams must communicate upcoming changes to product marketing, which is then responsible for informing customer success, sales, and customers.
• “Our product organization is too slow, so we’ve built our own solutions for customers.” While well-intentioned, this creates an unsupported and fragile environment for customers. The right solution is to fix the product organization, which is the purpose of the transformation.

Chapter 41: Objections from Marketing – Aligning on Market and Product

• “Who better than marketing to define the products we need?” Marketing provides critical insights, but they don’t know what is technically possible. Innovation requires a partnership between marketing’s market knowledge and product’s technology and user knowledge.
• “How can we best help the product teams?” The most important thing marketing can do is get any valuable information about the market, competitors, and customers into the hands of the relevant product managers.
• “We want to promote a future state of the product before it’s done.” This can be a valid strategy, but it must be done carefully to avoid cannibalizing current sales or making promises the team can’t keep. It requires close coordination between the heads of product, product marketing, and the CMO.

Chapter 42: Objections from Finance – Shifting the Financial Model

• “Outsourcing is cheaper and gives us more flexibility.” On a per-engineer basis, outsourcing may seem cheaper. But on a per-outcome basis, it is dramatically more expensive. A smaller team of empowered employees will consistently outperform a larger team of outsourced staff.
• “We need to know the cost and ROI of each project before we fund it.” The old model of business cases has a terrible track record. The product model adopts the venture capital approach: fund durable product teams instead of projects, and hold them accountable for business outcomes.
• “How do we hold teams accountable?” Accountability is based on the business results the teams are asked to achieve. Product leaders manage the portfolio of bets and are held accountable for the overall results of the product strategy.

Chapter 43: Objections from HR/People Ops – Redefining Roles and Performance

• “Can’t we just retitle our business analysts as product managers?” No. This is one of the most common reasons transformations fail. The product manager role in the product model is a completely different job that requires a new competency. You must raise the bar.
• “Isn’t ongoing coaching redundant with annual performance reviews?” Ongoing coaching is the primary responsibility of a manager in the product model. It’s how you develop the skills your people need to succeed. It’s not redundant; it’s essential.
• “We want every employee to have individual OKRs.” Members of a product team should have shared team OKRs, not individual ones. This incentivizes them to work together collaboratively to solve the same problem.

Chapter 44: Objections from the CIO – Evolving the Role of Technology Leadership

• “My job is to serve the business. Where does this leave me?” The product model shifts technology from a cost center to a profit center. This is an opportunity for the CIO to expand their role to a CTO, leading innovation rather than just managing vendors and internal systems.
• “How do I learn to be a CTO?” There are excellent product and engineering leadership coaches and CTO bootcamps that can help a CIO make this transition.

Chapter 45: Objections from the PMO – From Control to Enablement

• “What is the role of a Program Management Office (PMO) in the product model?” The problem with a traditional PMO is that it often exists to enforce a command-and-control culture. The function can be transformed into a delivery management organization, focused on servant-based project management and impediment removal for the teams.
• “We need to focus on predictability.” The product model prioritizes innovation over predictability. A focus on predictability stifles innovation. The goal is to deliver value, not just deliver on a pre-defined schedule.

Chapter 46: Objections from Inside Product – Addressing Team-Level Concerns

• “How can we be responsible for outcomes if we don’t control sales and marketing?” Your job is to understand the entire system and identify where the problem is. If the issue is with marketing or sales, your job is to work with them to fix it.
• “We don’t have time to test product ideas.” You don’t have time not to. Testing ideas in discovery with low-cost prototypes is dramatically faster and cheaper than building the wrong thing and having to fix it later. It’s the fastest path to time to money.
• “We have too many dependencies on other teams.” This is a common symptom of a poorly designed team topology and high technical debt. The long-term solution is to fix those issues. In the short term, delivery managers and platform teams can help manage the dependencies.
• “The engineers on my team just want to be told what to build.” That’s fine for some engineers, as long as the tech lead on the team is willing and able to participate in product discovery. However, the company should focus on hiring engineers who do want to be involved in what they build.

Chapter 4ter 47: Innovation Story: Kaiser Permanente – Innovating in a Regulated Industry

Kaiser Permanente, one of the largest non-profit healthcare organizations in the US, had begun its transformation to the product model in 2019. When the pandemic hit, in-person care was severely limited, creating the potential for significant gaps in patient care.

The company urgently needed a way for patients to get care 24/7, from anywhere. The result was “Get Care Now,” a nationwide, on-demand virtual care solution.

This was a massive undertaking with significant risks. The product teams had to solve for the needs of patients (who might be stressed and have varying comfort with technology) and clinicians (who had specific medical, regulatory, and operational needs). The solution required integrating complex scheduling and health record systems and ensuring it could scale to over 12 million patients.

Through intense collaboration with clinicians and operations teams, and by using rapid prototyping and testing, the product teams discovered and validated an end-to-end solution. In a remarkable achievement for a regulated industry, Get Care Now was built and launched in just four months. The service received a 9.6 out of 10 member satisfaction rating, proving that even in the most complex and regulated environments, the product model can enable rapid, high-impact innovation.

PART XI: Conclusion

Chapter 48: Keys to Successful Transformation – The 10 Critical Success Factors

Based on 20 years of experience, SVPG has identified ten factors that are essential for a successful transformation.

1. The Role of the CEO: The CEO must be the chief evangelist. Without her active and visible support, the transformation will likely fail.
2. The Role of Technology: The company must shift its mindset from viewing technology as a cost center to seeing it as the core enabler of the business.
3. Strong Product Leaders: The leaders of product management, design, and engineering are responsible for everything that follows. They must be experienced or have access to strong coaching.
4. True Product Managers: This is a new competency that must be established. The company must be willing to raise the bar and ensure every PM is a potential future leader.
5. Professional Product Designers: Design must be elevated from a supporting role to a core partner alongside product and engineering.
6. Empowered Engineers: Empowered engineers are the engine of innovation. This means insourcing engineering and putting them at the center of problem-solving.
7. Insights-Based Product Strategy: The company must move from stakeholder-driven roadmaps to an insight-driven strategy created by product leaders.
8. Stakeholder Collaboration: The relationship with stakeholders must shift from subservient to collaborative, built on a foundation of trust.
9. Continuous Evangelization of Outcomes: Product leaders must constantly communicate the vision, strategy, and progress, with a focus on business results.
10. Corporate Courage: Transformation is difficult and requires a real leap of faith. It takes true courage from senior leaders to make the leap and see it through.

Chapter 49: Innovation Story: Trainline – Solving the Pricing Puzzle

After its transformation, Trainline had a strong product organization capable of tackling its customers’ biggest frustration: the perception that rail tickets were “so expensive!”

The data science team investigated and uncovered a key insight: ticket prices were not linked to demand (yield) but were tied directly to the number of days to departure. Prices rose steeply within two weeks of travel. The team realized they could predict the exact savings for buying early on any route.

The challenge was how to present this information to customers without alienating their critical rail partners. The risks were immense; showing erroneous prices could get their license to trade revoked. The team worked through the value, usability, feasibility, and viability risks. They built a live-data prototype that proved customers loved the savings. They worked with their operations team to get a progressive partner to agree to a live test.

The results were overwhelmingly positive. Customers who could be flexible purchased tickets earlier, saving money and increasing their overall usage. The additional revenue from filling more seats offset the lower prices. This price-prediction tool became a major innovation that spoke directly to Trainline’s mission and provided a significant marketing advantage just in time for its successful IPO.

Key Takeaways: What You Need to Remember

Core Insights from Transformed

• Transformation is a fundamental shift in mindset, not just process. It requires moving from viewing technology as a cost center to the core engine of the business.
• The CEO’s active support is the single most critical success factor. Without it, resistance from other parts of the organization will derail the effort.
• Empowered, cross-functional product teams are the heart of the model. These teams are given problems to solve, not features to build, and are held accountable for business outcomes.
• True product management is a new and difficult competency that most transforming companies must build from the ground up. Simply retitling business analysts is a recipe for failure.
• Innovation comes from empowered engineers who are closest to the technology and are engaged in discovering the solution, not just building it.

Immediate Actions to Take Today

• Assess your organization honestly against the three dimensions of transformation: how you build, how you solve problems, and how you decide which problems to solve.
• Start a conversation with your CEO and executive team about the need to transform, using the case studies in this book as evidence of what’s possible.
• Identify a pilot team of willing volunteers and influential stakeholders to test the new way of working on a small scale.
• Mandate that every product team starts continuous customer discovery, with at least three customer interactions per week.
• Begin the work of insourcing your engineering talent, starting with the tech lead for each team, as this is a non-negotiable prerequisite for innovation.

Questions for Personal Application

• For Leaders: Am I willing to be the chief evangelist for this change? Do I have the corporate courage to see this difficult transformation through?
• For Product Leaders: Am I willing to take responsibility for raising the skill level of my team? Do I have a plan to establish true product management, design, and engineering competencies?
• For Product Teams: How can we start acting like an empowered team today, even within our current constraints? How can we start focusing on outcomes over output?
• For Stakeholders: Am I willing to move from a command-and-control relationship to a collaborative partnership with the product teams? What would it take for me to trust them?