Empowered – Complete Book Summary & All Key Ideas

Empowered by Marty Cagan: A Complete Summary of How to Build Extraordinary Product Teams

Quick Orientation

In EMPOWERED: Ordinary People, Extraordinary Products, Silicon Valley Product Group partners Marty Cagan and Chris Jones deliver an essential guide for leaders aiming to cultivate highly effective product organizations. This book serves as a vital companion to INSPIRED, shifting the focus from the mechanics of product management to the overarching leadership and managerial responsibilities required to foster an environment of genuine empowerment. Cagan and Jones assert that many companies are trapped in a “feature factory” model, where development teams act as mere implementers of predetermined features, often leading to wasted effort and minimal innovation. In stark contrast, the most successful and consistently innovative tech companies operate with “empowered product teams”—groups of “missionaries” entrusted with significant problems to solve and the autonomy to devise the best solutions.

This summary will meticulously unpack every core concept, illustrative example, actionable framework, and profound insight presented in EMPOWERED. We will delve into the critical distinctions between traditional and progressive approaches to technology, explore the multi-faceted roles of product leadership, and detail the practical strategies for coaching, staffing, and organizing product teams. Furthermore, we will examine the crucial elements of product vision, strategy, and objective setting, culminating in a comprehensive understanding of how to achieve meaningful organizational transformation. Every important idea, no matter how granular, will be clearly explained and integrated, ensuring a complete and accessible overview of the book’s wisdom.

Part I: Lessons from Top Tech Companies

Chapter 1: Behind Every Great Company

This foundational chapter sets the stage by contrasting the operational philosophies of leading tech giants—Amazon, Google, Apple, and Netflix—with the prevailing practices in most other companies. It argues that while cultures may vary, these successful companies share fundamental principles regarding technology, leadership, and team empowerment.

The Striking Differences: Beyond “Product Culture”

Cagan emphasizes that superficial “product culture” isn’t the differentiating factor; rather, it’s a deeper philosophical alignment on the role of technology and the purpose of people working with it. Drawing inspiration from Bill Campbell, the “Coach of Silicon Valley,” the book highlights that leadership’s job is to create an environment where the “greatness in everyone can emerge.” This requires three core distinctions from traditional organizations:

The Role of Technology: Most companies treat technology as a necessary expense or a cost of doing business, often outsourcing it or relegating it to an “IT mindset” where technology teams “serve the business.” This leads to disengaged teams seen as unappreciated mercenaries. In strong product companies, technology is the business itself, powering core products and services and enabling novel solutions. Here, product teams serve customers by leveraging technology, leading to higher morale and innovation.
Strong Product Leadership: In many organizations, product leadership is notably absent, acting merely as a facilitator for a “feature factory.” There’s often no true product strategy beyond trying to please multiple stakeholders with a prioritized list of features. In contrast, strong product companies possess impactful product leaders who are responsible for staffing, coaching, and developing product teams. They define and communicate a clear product strategy and actively manage for business results, moving beyond a passive, command-and-control style to enable empowered teams.
Empowered Product Teams: The most crucial distinction lies in how development teams operate. Feature teams implement pre-defined features and projects, focusing on output rather than outcome. They are cross-functional but act as order-takers, leading to low motivation and rare innovation. Empowered product teams, however, are given problems to solve and the autonomy to discover the best solutions. They are held accountable for results (outcomes). The product manager, designer, and tech lead collaborate to address value, usability, feasibility, and viability risks, owning the problem end-to-end.

The Problem of “Feature Teams” and the Promise of “Empowered Teams”

The chapter highlights that many companies mistakenly believe they’ve achieved “digital transformation” by adopting Agile, yet they remain stuck with feature teams. This results in wasted talent, vulnerability to disruption, and a struggle to achieve meaningful business results. The shift to empowered teams requires acknowledging that customers and stakeholders cannot dictate solutions because they don’t know what’s technologically possible, and predicting what will work is inherently difficult. Product discovery, therefore, becomes essential for systematically uncovering valuable, usable, feasible, and viable solutions.

Chapter 2: The Role of Technology

This chapter delves into the fundamental philosophical difference in how technology is viewed, arguing it’s the root cause of the gap between top tech companies and the rest.

The Deep Misunderstanding of Technology’s Role

Cagan emphasizes that while many companies now spend more on software and adopt Agile, they haven’t truly transformed because they haven’t embraced technology as a core business enabler. Marc Andreessen’s “Why Software Is Eating the World” warned of this disruption a decade ago, but many companies, like Boeing with its 737 MAX crisis, still treat technology as a mere cost, outsourcing critical software development to save money. This leads to catastrophic failures. Conversely, companies like Tesla and Pixar demonstrate what’s possible when technology is central to the product, allowing for continuous improvement (Tesla’s over-the-air updates) or entirely new creative possibilities (Pixar’s animation). Disney’s transformation with Disney+ and its theme parks further illustrates embracing technology to reimagine existing businesses.

The CIO vs. CTO Divide: A Symptom of Deeper Issues

The organizational structure often reveals this fundamental misunderstanding. If engineers building customer-facing products report to a Chief Information Officer (CIO) (who manages internal IT), it signals a “serve the business” mindset. A CIO’s very traits—focus on cost management, process efficiency, and reliability for internal systems—can inadvertently undermine product innovation. Product engineers, who are essential for building competitive products, often refuse to work for CIOs because they seek environments where their contributions are valued as core to the business. In contrast, a Chief Technology Officer (CTO) leads product engineering, fostering an environment akin to empowered product teams. Cagan sometimes advises a CIO to re-title as CTO if they can embrace the larger role, or for CEOs to hire a true CTO to lead product engineering. The key takeaway is that companies spending massively on outsourced, mercenary engineering often get far less return than if they invested in a smaller number of empowered, internal employees focused on outcomes.

Chapter 3: Strong Product Leadership

This chapter outlines the indispensable role of product leadership in building successful product organizations. Cagan differentiates between leadership (inspiration) and management (execution), highlighting that empowered teams require better leadership, not less.

The Role of Leadership: Inspiring the Organization

Strong product leadership is crucial for driving consistent innovation. The individuals in these roles (CPO, VP of Product/Design/Engineering) are tasked with inspiring and motivating the entire product organization. Their key responsibilities include:

Product Vision and Principles: Leaders define the product vision, a compelling future state (3-10 years out) that describes how the product will profoundly improve customers’ lives. This vision acts as the organization’s North Star, providing a shared goal and inspiring engineers. Complementing this are product principles, which articulate the organization’s values and guiding beliefs, helping teams make informed trade-offs in their daily work (e.g., valuing user experience over short-term revenue).
Team Topology: Product leaders are responsible for designing the team topology, which defines how product people are organized into teams, their scope of responsibility, and their interdependencies. This strategic decision impacts ownership, autonomy, and alignment, ensuring teams can do great work.
Product Strategy: Leaders craft the product strategy, which is the plan for how to achieve the product vision while meeting current business needs. This involves focus (choosing the most critical problems), insights (identifying levers from data, customers, and technology), action (converting insights into team objectives), and management (active oversight to unblock teams).
Product Evangelism: A continuous effort to communicate the product vision, principles, and strategy throughout the company. As John Doerr emphasizes, the goal is to build “teams of missionaries, not mercenaries“—individuals deeply committed to the larger purpose. This ongoing persuasion is vital for recruiting, onboarding, and securing company-wide support.

The Role of Management: Ensuring Effective Execution

First-level people managers (Director of Product/Design, Engineering Manager) are the bedrock of empowered teams. Their effectiveness directly determines the success of the product organization. Their three core responsibilities are:

Staffing: Managers are directly responsible for building their teams—sourcing, recruiting, interviewing, hiring, onboarding, and performance management (evaluating, promoting, and, when necessary, terminating). They are supported by HR but ultimately own the quality of their hires.
Coaching: This is the most crucial, yet often overlooked, responsibility. Managers conduct regular 1-on-1s with their direct reports, providing tailored guidance, feedback, and support to help them develop their skills and reach their full potential. They connect team members to broader organizational context and help resolve cross-team issues.
Team Objectives: Managers ensure that each product team has clear, problem-oriented objectives (e.g., using OKRs) that derive from the product strategy. This is where empowerment is realized, as teams are trusted to determine how best to solve the assigned problems, rather than being handed a list of features. This requires managers to be secure enough to truly empower their reports.

Chapter 4: Empowered Product Teams

This chapter addresses the core obstacle to widespread adoption of empowered teams: a lack of trust from leadership.

The Trust Barrier: “Ordinary People” Creating “Extraordinary Products”

Cagan highlights that many companies struggle to empower their teams because leaders simply don’t trust them. They often believe their current staff isn’t skilled enough, and they can’t attract the “10X” talent of top tech companies. This leads to a perpetuation of the “command-and-control” model. Cagan refutes this by pointing out that many individuals who struggle in “feature factory” environments thrive when they move to leading tech companies. He posits that the key difference isn’t necessarily a higher percentage of “exceptional” hires, but rather that strong companies know how to leverage their existing talent to help “ordinary people reach their true potential and create, together, extraordinary products.” The emphasis is on building systems and environments that enable greatness, rather than just acquiring it.

Chapter 5: Leadership in Action

This chapter serves as an introduction to the leader profiles that will appear throughout the book. It explains that, similar to INSPIRED which profiled successful product managers, EMPOWERED will highlight the journeys and philosophies of impactful product leaders. The goal is to provide concrete examples of what strong product leadership looks like in practice, offering insights into their approaches to guiding and developing teams at iconic tech companies. These profiles offer a glimpse into the diverse paths to leadership and the common principles that underpin their success.

Chapter 6: A Guide to EMPOWERED

This chapter provides a quick orientation to the book’s audience and structure, setting expectations for the reader.

Who This Book Is For and How It’s Organized

The book is primarily intended for product leaders and aspiring product leaders, including managers, directors, VPs, CPOs (Chief Product Officers), and CTOs (Chief Technology Officers). While it covers content relevant to product managers, designers, and engineers, its advice is generally aimed at those responsible for leading and developing these roles. The authors, Marty Cagan and Chris Jones, write in the first person to create a conversational, coaching-like experience, drawing on decades of collective experience from SVPG partners. The book is structured into several parts, each focusing on a critical aspect of building an empowered product organization:

Part II: Coaching: The most extensive section, emphasizing the manager’s primary role in developing people.
Part III: Staffing: How to identify, recruit, hire, and onboard talent effectively.
Part IV: Product Vision and Principles: Defining the inspiring future and guiding values.
Part V: Team Topology: Structuring teams for optimal empowerment.
Part VI: Product Strategy: Deciding which problems are most important to solve.
Part VII: Team Objectives: Translating strategy into actionable problems for teams.
Part VIII: Case Study: A detailed, real-world example illustrating all concepts in practice.
Part IX: Business Collaboration: Building effective relationships with other company functions.
Part X: Inspired, Empowered, and Transformed: Tying everything together for organizational transformation.

The authors explicitly state that while transformation is hard, it is absolutely possible, and the book is designed to provide the necessary knowledge and skills for success.

Part II: Coaching

Chapter 7: The Coaching Mindset

This chapter emphasizes that effective coaching begins with the right mindset from the coach (the manager). Without it, even good tools can be misused. It highlights Bill Campbell’s philosophy that “coaching is no longer a specialty; you cannot be a good manager without being a good coach.”

Cultivating the Right Intent: Principles for Coaches

A coaching mindset is the foundational intent that guides all coaching techniques. Key principles include:

Developing People Is Job #1: Managers must dedicate significant time and energy to assessing, planning, and actively helping their teams improve. Their own performance should be measured by the success of their reports.
Empowering People Produces the Best Results: The manager’s role is to create a space where teams own outcomes, not just tasks. This means stepping back to allow autonomy while stepping in to remove impediments and clarify context. This reinforces the “missionaries, not mercenaries” ethos.
Beware Your Own Insecurities: Insecure managers may micromanage or control visibility to protect their own perceived contribution, seeing team success as a threat. Self-awareness is crucial to prevent this behavior from undermining empowerment. Managers lacking experience in coaching should actively seek it for themselves.
Cultivate Diverse Points of View: Good leaders encourage and leverage dissenting opinions. This starts in hiring by building a team with diverse strengths and backgrounds, then fostering an environment where alternative ideas are welcomed, helping teams make better decisions collaboratively.
Seek Out Teaching Moments: Coaches actively look for opportunities to help people stretch beyond their comfort zones, using judgment to right-size challenges. Pushing through discomfort is how individuals realize their true capabilities, addressing both competency gaps and inherent strengths.
Continually Earn the Trust of Your Team: Trust is paramount and is built by consistently demonstrating genuine commitment to the team’s success. This involves supporting them publicly and privately, and being honest in both praise and constructive criticism, always delivered privately. Sharing personal challenges can also humanize the relationship.
Have the Courage to Correct Mistakes: If, despite best efforts, a team member cannot become successful, the manager must act decisively. Prolonging the situation hurts the individual, the team (by signaling tolerance for mediocrity), and the manager, often due to spending too much time on the struggling individual. The advice is: when you know, don’t wait.

Manager as Coach: Alternatives in Organizational Structure

While the ideal is for direct managers to also be coaches, some alternative structures (e.g., a general manager from business development leading a cross-functional product team) may mean the manager lacks the specific domain expertise to coach. In such cases, other experienced individuals within the organization (e.g., a design manager from another team) must be explicitly tasked with providing that specific coaching. The key is that someone must be responsible for each product person’s development.

Chapter 8: The Assessment

This chapter introduces a practical coaching tool: a gap analysis designed to assess a product person’s current performance against expectations for their role. This assessment forms the bedrock for creating a targeted coaching plan.

The Gap Analysis: People, Process, and Product

Cagan advocates for assessing product individuals (PMs, designers, tech leads) across three fundamental pillars, mirroring the taxonomy from his book INSPIRED:

Product Knowledge: This is considered “table stakes” and the foundation for everything else. Without deep product knowledge, other skills are moot. Key areas include:
- User and customer knowledge: Understanding target users/customers as acknowledged experts.
- Data knowledge: Proficiency with analytics tools and understanding data semantics.
- Industry and domain knowledge: Familiarity with the competitive landscape and relevant trends.
- Business and company knowledge: Understanding various business dimensions (marketing, sales, finance, legal, etc.) and stakeholder concerns.
- Product operational knowledge: Being an expert user of the product itself, able to demo, train, and troubleshoot.
- Ramp-up time: A new PM typically needs 2-3 months of aggressive, coached learning to gain this level of knowledge.
Process Skills and Techniques: These are the methodologies and practices used in product development. Key areas include:
- Product discovery techniques: Understanding product risks (value, usability, feasibility, viability), how to de-risk them early, and collaborative problem-solving (qualitative and quantitative).
- Product optimization techniques: Knowing how to use methods like A/B testing for live products.
- Product delivery techniques: Understanding their supporting role in engineers’ delivery processes (e.g., continuous delivery, release planning).
- Product development process: Solid understanding of the broader discovery/delivery lifecycle and their administrative role as a product owner (e.g., Scrum).
- Development: New PMs need basics, but strong PMs continuously learn advanced techniques.
People Skills and Responsibilities: These “soft skills” are crucial for effective collaboration and leadership, often differentiating competent from truly effective PMs. Key areas include:
- Team collaboration skills: Effectiveness in working with engineers and designers, fostering mutual respect, and leveraging their expertise.
- Stakeholder collaboration skills: Building trust and partnership with cross-company stakeholders, understanding their concerns.
- Evangelism skills: Ability to share vision and strategy, motivating both the team and broader company.
- Leadership skills: Influencing and inspiring without direct authority, effective communication, and demonstrating leadership in stressful situations.
- Development: While foundational, these skills can be significantly improved with coaching, provided the individual is open to it. If not, a different role might be more suitable.

Performing the Gap Analysis and Creating the Coaching Plan

For each skill, the manager assigns two ratings (e.g., 1-10 scale):

Expectations Rating: Where the employee should be for their role level. This differentiates between, for example, a PM and a Senior PM.
Capability Rating: Where the employee currently performs.
The “gap” (difference between ratings) highlights areas needing the most attention. The manager then focuses the coaching plan on the top 2-3 biggest gaps. Cagan encourages self-assessment by the employee, but stresses the manager’s responsibility to confront any discrepancies between self-perception and reality. This assessment is distinct from annual performance reviews, which often serve HR compliance rather than active development. If successful in closing gaps, the assessment can then be used to outline the expectations for the next career level, guiding promotion discussions.

Chapter 9: The Coaching Plan

This chapter serves as a practical sequel to the assessment, offering concrete strategies and recommendations for coaching product people on each specific skill gap identified previously. Cagan notes that this entire book, in essence, constitutes the “full version” of a coaching plan.

In-Depth Coaching for Each Skill Area

The chapter systematically goes through the “People, Process, Product” taxonomy, providing actionable advice for managers.
Product Knowledge (Foundational)

User and Customer Knowledge: Emphasizes immersion. Managers should encourage starting with internal resources (user research, customer success, product marketing, founders/CEO) to gain diverse perspectives. Crucially, PMs must then engage directly with real users and customers. Marty shares his personal anecdote of visiting 30 customers before making major decisions, recommending at least 15 customer visits for new PM onboarding. The goal is to learn who customers are, their problems, how they solve them, and what would prompt a switch.
Data Knowledge: Focuses on becoming proficient with user analytics, sales analytics, and data warehouse tools. The key is not just operating the tools but understanding what the data is saying. Managers should connect PMs with data analysts, stressing that analysts are there to empower the PM to answer questions, not to receive delegated work. This ties into understanding key performance indicators (KPIs) and their business implications.
Industry and Domain Knowledge: PMs are expected to become competent in their specific domain (e.g., media, developer tools). This often involves leveraging in-house subject matter experts. For broader tech industry knowledge, resources like stratechery.com are recommended. Competitive analysis is crucial; PMs should evaluate top competitors and write narratives on their strengths, weaknesses, and opportunities.
Business and Company Knowledge: This often requires the most work for new PMs. Managers recommend using a business model canvas to quickly identify unknown areas. Specific areas include:
- Sales and Marketing (Go-to-Market): Understanding the entire funnel from awareness to conversion, and the capabilities/limitations of various sales channels (direct, resellers). Product marketing is a key resource.
- Finance (Revenue and Costs): Gaining a deep understanding of product financials, including KPIs like Customer Lifetime Value (CLV). Befriending someone in finance is suggested.
- Legal (Privacy and Compliance): Understanding legal constraints, especially around new product ideas.
- Business Development (Partnerships): Knowing the contractual constraints of technology, sales, or marketing partnerships.
- Additional Areas: Recognizing company-specific functions like editorial (for media), merchandising (for e-commerce), or international teams.
Product Operational Knowledge: The PM must be an expert user of their own product beyond basic demos. This involves reading documentation, taking training, spending time with customer service, and dogfooding (using the product daily). A litmus test is whether the PM could confidently brief a major industry analyst on the product.

Process Skills and Techniques (Continuous Learning)

Product Discovery Techniques: PMs must master the four product risks (value, usability, feasibility, viability), forms of prototypes, and qualitative/quantitative testing. INSPIRED is explicitly recommended reading. Managers should test understanding by presenting scenarios and asking PMs how they’d approach risk.
Product Optimization Techniques: For live products with traffic, PMs need to understand and utilize commercial tools for A/B testing, often for funnel optimization.
Product Delivery Techniques: While engineers own delivery, PMs need to understand concepts like continuous delivery and parallel deployment, and their implications for product decisions.
Product Development Process: PMs must understand their responsibilities within the team’s chosen process (Scrum, Kanban, XP). Taking a CSPO (Certified Scrum Product Owner) course is recommended, though Cagan cautions that CSPO training alone is insufficient for the full PM role.

People Skills and Responsibilities (Requires Willingness to Improve)

Team Collaboration Skills: Managers should observe and coach PMs on their interactions with designers and engineers. True collaboration means leveraging everyone’s skills and minds, not just taking orders. Managers often sit in on team meetings (e.g., problem discussions with PM, designer, and tech lead) to identify coaching opportunities.
Stakeholder Collaboration Skills: Building trust with often-senior stakeholders is critical. PMs must put in effort to understand stakeholder constraints and then actively work to convince them that proposed solutions address their concerns. Managers can observe and provide feedback on these interactions.
Evangelism Skills: So much of product work is persuasion. Managers should encourage the use of the written narrative (Chapter 11) and recommend presentation skills classes (with video recording and professional critiques).
Leadership Skills: PMs must earn leadership through influence and persuasion, as they often lack direct authority over their team. This builds on mastering the other skills. Managers should encourage lifelong study of leadership and facilitate discussions on defining characteristics of good/bad leaders.

Coaching Tech Leads and Product Designers

The chapter also provides specific coaching advice for these critical roles:

Coaching Tech Leads: Tech leads are senior engineers who participate in product discovery. Their potential comes from combining deep technical knowledge with customer understanding. Managers should encourage customer visits and regular discussions about insights from customer interactions. Sometimes, encouraging a tech lead to temporarily explore the PM role can be invaluable for future startup goals.
Coaching Product Designers: Designers need competence across various design disciplines (service, interaction, visual, industrial, prototyping, user research). Design managers play a crucial role in filling skill gaps and ensuring a holistic view of design across multiple product teams through standards, guidelines, and review sessions. They also need to educate PMs and engineers on the value of strong product design.

LOVED: A Call for Strategic Product Marketing

The chapter includes an excerpt from SVPG Partner Martina Lauchengco’s book LOVED, emphasizing that product marketing is not just a launch checklist or demand generation. Great product marketing understands the market first, pressure-tests assumptions, positions the product effectively, and makes clear why customers should care and love it. It’s about achieving market adoption and momentum, often needing to be involved much earlier than many companies realize.

Chapter 10: The One-on-One

This chapter focuses on the most fundamental coaching tool: the weekly one-on-one (1:1) meeting. Cagan stresses that this isn’t a status update but a sacred opportunity for employee development.

Keys to Effective One-on-Ones

The Purpose: The 1:1 is primarily for the product person’s development and improvement. While updates occur, the main goal is to help them reach competence and potential.
The Relationship: It must be built on trust. The employee needs to believe the manager is genuinely committed to their success, fostering honest and frank discussions.
The Onboarding: For new hires, especially those not yet competent, 1:1s are more frequent (2-3 times/week or even daily) and involve close oversight to ensure they ramp up effectively and don’t “do harm.” The manager takes responsibility for ensuring initial competence.
The Frequency: No less than 30 minutes, once per week. This meeting is “sacred” and should be rescheduled, not canceled, to signal its importance. Video calls are acceptable once trust is established.
Sharing Context: Managers must provide strategic context (company mission, objectives, product vision, strategy, team objectives) to empower good decision-making.
Homework: The manager guides the employee to resources, but the employee must commit the time to learn. For PMs, this means deep dives into customers, data, business, technology, and industry.
Thinking and Acting Like a Product Person: Coaching involves shaping the employee’s mindset—focusing on outcome, considering all four risks (value, usability, feasibility, viability), thinking holistically, anticipating ethical issues, and demonstrating creative problem-solving and persistence. It also involves coaching behaviors like listening, collaborating, evangelizing, and building relationships.
Holistic View (“Connecting the Dots”): Managers, by interacting with multiple reports and teams, are uniquely positioned to spot brewing issues, conflicts, or duplications across the organization and encourage collaboration or make decisions to resolve them.
Providing Feedback: This is the manager’s main value-add. Feedback must be frequent, timely, honest, and constructive. Praise publicly, criticize privately. Managers should actively seek feedback about their reports from colleagues and stakeholders. Nothing in an annual performance review should be a surprise.
Continuous Improvement: Product work is a journey, not a destination. Managers should measure their success by how many people they’ve helped earn promotions or move into more impactful roles.

Common Anti-Patterns (Why 1:1s Fail)

Cagan highlights frequent reasons managers fail to develop their people via 1:1s:

Manager Just Doesn’t Care: Development is pushed aside, leaving employees on their own.
Manager Reverts to Micromanaging: The manager gives specific instructions, stifling empowerment and scalability.
Manager Spends Time Talking and Not Listening: The meeting becomes the manager’s soapbox, rather than focusing on the employee’s needs and learning style.
Manager Doesn’t Provide Difficult Feedback: Conflict-averse managers avoid constructive criticism, leading to employee surprise and resentment at performance reviews.
Manager Is Insecure and/or Incompetent: The manager fears others’ success or lacks the skills to coach effectively. In such cases, the leader of that manager must intervene.
Manager Doesn’t Cut Losses: Despite sincere effort, some individuals are not cut out for product roles (e.g., someone simply reassigned who lacks core foundation). Managers must take responsibility to help them find a more suitable job rather than allowing mediocrity to fester, which harms the team.

Chapter 11: The Written Narrative

This chapter introduces Marty Cagan’s “single favorite coaching tool” for developing exceptional product people: the written narrative. Despite initial resistance, Cagan asserts its profound effectiveness, especially for tackling complex, high-stakes decisions.

The Power of the “Six-Pager”

The written narrative, famously championed by Amazon’s Jeff Bezos (and known as a “six-pager”), is a roughly six-page document that articulates an argument and recommendation in narrative form. It’s explicitly not a specification or a slide deck. Its purpose is to be persuasive by demonstrating thoroughness and deep understanding.

Problem Statement: It clearly describes the problem the team is trying to solve.
Value Proposition: Explains why the solution will be valuable for customers and the business.
Strategy: Outlines the approach to solving the problem.
FAQ Section: This is a critical component. It anticipates concerns and objections from key executives and stakeholders, providing clear, pre-considered answers. This demonstrates that the product person has done their homework and thought through various perspectives.

Why It’s So Effective (and Painful)

No Faking It: Unlike a glib presentation, a written narrative exposes any “glaring holes” in thinking or research. It forces the product person to truly know their topic and consider all constraints.
Forces Homework: It compels the product person to delve deeply into the subject matter, addressing potential objections before they are even raised.
Faster, Better Decisions: By forcing rigorous preparation, the narrative enables quicker, more informed decision-making meetings, preventing unproductive “design by committee” or deferral to the highest-paid person.
Builds Credibility: A well-crafted narrative leaves the audience impressed by the preparation and expertise, building trust with executives and stakeholders.

Cagan admits he had to be “forced” to use this technique early in his career, but it transformed his ability to influence and make better decisions. He continues to use it for keynote presentations, iterating on the narrative before creating any slides. For managers, coaching a product person through this “uncomfortable” process is vital for their growth, helping them confront the depth of their own understanding (or lack thereof).

Chapter 12: Strategic Context

This chapter elaborates on a crucial aspect of coaching: ensuring product teams possess a deep understanding of the broader business environment in which they operate. This collective information is termed strategic context, essential for empowered teams to make sound decisions.

The Six Types of Strategic Context

Strategic context, typically introduced during new employee onboarding, provides the “why” behind the work. This applies broadly across the company, though large organizations with distinct business units (e.g., Google’s YouTube vs. AdWords) may have different contexts for each.

Company Mission: The fundamental purpose of the company (e.g., “organize the world’s information”). It’s a simple, durable statement, usually lasting decades. Every employee should know it and understand how their work contributes.
Company Scorecard: A set of Key Performance Indicators (KPIs) that provide an overview of the business’s overall health and performance. For a two-sided marketplace, this might include metrics for both sides (e.g., job seekers and employers) and their balance. Leaders use this to judge company health.
Company Objectives: The specific, outcome-oriented goals the company is focused on for the year, chosen by senior leadership and often approved by the board. These objectives should be business results (outcomes), not specific projects or outputs. They are nearly always measured by KPIs from the company scorecard.
Product Vision and Principles: The product vision describes the inspiring future (3-10 years out) that the company is trying to create through its products, explaining how it improves customers’ lives. It’s the tangible manifestation of the mission and a powerful recruiting tool. Product principles complement this by outlining the values and beliefs that guide daily product decisions and trade-offs.
Team Topology: The structure of the product teams—what each team is responsible for and how they relate to other teams. This helps each team understand their place within the larger organizational puzzle.
Product Strategy: This is where the concepts become more specific. It describes how the product vision will be achieved while meeting business needs. The strategy connects company objectives to specific team objectives, guiding which problems each team should solve.

Cagan asserts that every product person, especially the product manager, must deeply understand this strategic context and demonstrate through their actions and decisions how their team contributes to these common goals.

Chapter 13: Sense of Ownership

Moving beyond mere competence, this chapter explores a crucial mindset for strong product people: the difference between thinking like an owner versus thinking like an employee. Cagan stresses this is a “best practice” from top tech companies, not a subjective preference.

The Owner’s Mindset: Responsibility for Outcomes

Drawing from Jeff Bezos’s consistent emphasis in his shareholder letters, the concept of “thinking like an owner” is fundamental. It’s akin to being a “missionary” but goes deeper, meaning taking personal responsibility for the outcome, not just the activities or effort.
Cagan recounts how this concept was explained to him when he became a PM:

Obligation: Feeling a real responsibility to customers, the team, stakeholders, and investors.
Providing Context: Leading the team by providing the strategic context for optimal problem-solving, as teams thrive when given context and problems, not just requirements.
Doing the “Homework”: Deeply understanding customers, data, the business, and the industry to contribute essential knowledge.
Overcoming Obstacles: Committing to finding a way “over, around, or through” inevitable challenges, recognizing that technology products are never easy.
Measuring by Results: Focusing on achieving actual business outcomes, never confusing effort or activity with results.
Building Relationships: Establishing and maintaining trust with cross-company partners (sales, marketing, legal) to navigate constraints and ensure solutions work for the business.
Serving as a Canary in the Coal Mine: Executives rely on PMs to signal potential issues early.
Taking Blame, Giving Credit: Demonstrating true leadership by taking responsibility for failures and sharing successes with the team.
Motivating and Evangelizing: Inspiring the team to be missionaries, not mercenaries.
Responsibility Without Authority: Influencing and persuading without direct command, especially with design and engineering partners.

In essence, thinking like an owner is about taking responsibility for the outcome, not just the activities. Cagan notes that some designers and engineers resist moving into PM roles precisely because of this implied pressure of outcome responsibility.

The Practical Power of Equity

Cagan argues that spreading equity (stock options or grants) is a direct way to foster an owner’s mindset. Top tech companies use equity for this reason. While tax laws can complicate this in some regions, leading to more “that’s not my job” attitudes, Cagan believes companies should compensate key people like owners if they want them to behave like owners. Evergreening equity (continuing to award stock to strong performers) also encourages long-term retention, creating a clear win-win where employees remain invested in the company’s sustained success.

Chapter 14: Managing Time

This chapter addresses a universal complaint from product managers: a lack of time for “real product work.” Cagan argues that this isn’t about working harder but smarter, by protecting time for product discovery.

The PM’s Core Work: Product Discovery

Cagan states that a product manager needs four solid hours a day for quality, uninterrupted work on product discovery—figuring out solutions to difficult problems. This is distinct from email, Slack, or meetings. The “frenzied PM” rushing from meeting to meeting is often doing project management work, not product management.

Why PMs fall into the project management trap:
- The work is urgent and needs doing, and they may feel no one else is available.
- They may not have been trained on what true product management entails.
- Project management tasks can feel tangible, productive, and comfortable to check off.
The PM’s Highest Contribution: Ensuring that what engineers build is worth building and will deliver necessary results. This involves collaborating with designers and engineers to ensure solutions are valuable, usable, feasible, and viable.
The Solution: Block off dedicated “discovery time” (e.g., four hours a day) and fiercely protect it. The ideal solution is often to partner the PM with a delivery manager who can handle the project management tasks, freeing the PM to focus on their core product responsibilities.
Consequences of Not Managing Time: Without dedicated discovery time, PMs will either extend their workday (leading to burnout and the infamous 60-hour workweek) or fail to deliver results, ultimately failing at their job. This applies specifically to PMs of empowered product teams, not to product owners of delivery teams or project/delivery managers of feature teams. Taking control of one’s time is more important than ever for product managers.

Chapter 15: Thinking

This chapter delves into a crucial, yet sometimes awkward, coaching topic: the ability to think deeply and solve complex problems. Cagan differentiates this from mere intelligence or knowledge acquisition.

The Core of Product Work: Problem Solving

While intelligence is a prerequisite, Cagan argues that many intelligent people “waste their minds” because they don’t know how (or are unwilling) to actually engage in rigorous thinking. Similarly, readily available knowledge (via Google) is distinct from the ability to apply that knowledge.

Designers and Engineers as Problem Solvers: Cagan highlights that thinking is core to these roles. Designers solve for user experience constraints, and engineers solve for implementation challenges, often with many technical limitations. They are inherently skilled at problem-solving.
Product Managers as Problem Solvers: PMs solve problems related to customer needs, industry dynamics, and business viability (e.g., marketability, sales, finance, legal, support, affordability, ethical considerations). The unique challenge of technology products is simultaneously solving for product, design, and engineering constraints, necessitating true collaboration.
Identifying Weak Thinking: It’s evident when a product person asks basic questions without first putting in the “intellectual effort” or doing their homework.
Developing Thinking Skills: Good companies use interview processes to assess problem-solving skills, focusing on what a candidate does when they don’t know the answer. Cagan reiterates the written narrative as his favorite technique for developing this. He acknowledges it’s “truly painful” for those unaccustomed to deep thinking, but that’s precisely why it’s so necessary. For some, it may reveal they are not suited for a product role. However, with sufficient intelligence and willingness, the ability to think and solve hard problems can absolutely be developed through active coaching and sincere effort.

Chapter 16: Team Collaboration

This chapter stresses the fundamental importance of team collaboration within an empowered, cross-functional product team, emphasizing that it’s often misunderstood and requires active coaching.

Defining True Collaboration

Cagan clarifies what collaboration is and isn’t in the context of modern product teams:

Not Consensus: Collaboration doesn’t mean everyone has to agree. The team relies on the expertise of each member, generally deferring to the tech lead on architecture and the designer on user experience. Disagreements are often resolved by running tests.
Not About Artifacts: Collaboration is not about PMs producing “requirements” documents or user stories that are then handed off. Such artifacts often impede true collaboration by moving discussions from problem-solving to mere implementation, stifling innovation and fostering a “Waterfall” dynamic.
Not Compromise: True collaboration doesn’t lead to mediocre solutions where everyone gives up a little. The goal is to find a solution that works holistically—valuable, usable, feasible, and viable.
What It Is: True collaboration is about product management, product design, and engineering working together from the outset to solve problems. Each member brings necessary skills and has done their homework, counting on the others. This often happens by “sitting around a prototype” (often created by the designer), where the team collectively explores different approaches, considering technical possibilities, user implications, and business consequences.

The Magic of Cross-Functional Collaboration

Cagan describes the “magic” that occurs when motivated and skilled individuals from different disciplines (PM, designer, engineer) interact with a prototype or observe a user. Engineers identify new possibilities enabled by technology, designers discover different user experiences, and PMs weigh in with business viability and constraints (privacy, sales channel impact, financial implications). This iterative process leads to solutions that are truly optimal across all dimensions.

Common Pitfalls and Coaching Opportunities

Two main situations lead to collaboration breakdown:

PM Hasn’t Done Their Homework: If the PM lacks deep understanding of the business (sales, marketing, finance, legal), the team cannot effectively solve problems that work for the business, often reverting to feature implementation. The manager’s initial priority is to coach the PM to competence.
Arrogance: If the PM believes their pre-conceived solution is superior, collaboration is stifled, turning missionaries into mercenaries.

Collaboration also extends to engaging with prospective customers (via customer discovery programs) to understand their underlying problems rather than just accepting feature requests. Ultimately, getting good at true collaboration is a combination of skills and mindset that often requires active coaching from the manager.

Chapter 17: Stakeholder Collaboration

This chapter further distinguishes empowered product teams by how they interact with stakeholders, moving beyond the typical adversarial relationship found in feature teams.

A Partnership, Not a Client-Service Relationship

In companies with feature teams, stakeholders are often seen as “the client” that technology teams “serve,” leading to a mindset of “stakeholder management” to cope with demands. This is a remnant of the old view of technology as a subservient function.
However, for an empowered product team, the purpose is to “serve the customers in ways customers love, yet work for the business.” In this model, stakeholders are partners in collaboration.

Shared Goal: The product team’s job is to find solutions that work for customers and for the various parts of the business (e.g., legal, finance, sales).
Leveraging Expertise: Stakeholders bring critical knowledge about their specific business constraints (e.g., legal implications, financial models, sales processes). The PM collaborates with them to understand these constraints and incorporate them into solution discovery, rather than just taking orders. For instance, a legal stakeholder is a partner in evaluating the suitability of approaches to ensure compliance, not just a blocker of ideas.
Building Trust: A constructive relationship with stakeholders is predicated on the product manager having done their homework and demonstrating a deep understanding of each stakeholder’s concerns. This builds mutual trust, ensuring stakeholders feel the PM is a genuine partner committed to their success. This is especially critical when dealing with senior executives.

Building the Foundation for Trust: A Practical Exercise

Cagan offers a practical exercise for PMs to improve stakeholder collaboration:

List Collaborators: Write down all regular collaborators and necessary input providers, including executives and stakeholders.
Identify Critical Relationships: Circle the 3-5 most important relationships for the PM’s success.
Identify Dreaded Relationships: Circle the 1-2 people the PM most dreads dealing with. This identifies the relationships that need the most investment.
Invest in Personal Connection: Encourage the PM to get to know these individuals one-on-one, building rapport by discussing non-work interests over coffee or lunch. This humanizes the relationship and builds trust. For remote stakeholders, dedicated non-work chat time on calls is important.
With mutual trust, disagreements can remain professional, and everyone’s job becomes more enjoyable.

The Agency Model Parallel

Cagan draws a parallel between feature teams and the agency model (outsourced design or development). Both function on a client-service basis where the “client” (stakeholder) dictates what to build, reducing the development team to a group of mercenaries. This stifles innovation and often leads to dissatisfaction for all parties involved, as the agency’s people are also capable of more but are forced to comply or lose the business. He notes that while some agencies are trying to pivot to empowered team services, it requires an unusually high level of client trust. People from agencies often bring the “client-server” mindset, which needs to be re-coached when they join an empowered team.

Chapter 18: Imposter Syndrome

This chapter offers a unique, pragmatic perspective on imposter syndrome, reframing it not as a debilitating psychological issue but as a crucial signal for preparation.

Reframing Imposter Syndrome: A Healthy Warning

Cagan distinguishes imposter syndrome from severe mental illness, acknowledging its reality for most mentally healthy individuals who experience self-doubt. However, he also points out the existence of actual “imposters” (people advocating nonsense without sufficient knowledge) in the product and design world. His key insight is that imposter syndrome is a “very healthy and necessary emotion” and an “important signal” from our minds.

The Misinterpretation: Most people mistakenly believe this signal is simply natural fear that needs to be overcome by “pushing past” it.
Cagan’s Interpretation: He sees it as a warning of the consequences of not doing your homework and truly preparing. This fear of “looking clueless” is what drives him to prepare rigorously—studying, thinking, writing, rehearsing, and iterating.
Seeking Honest Feedback: A critical part of preparing is seeking out trusted individuals who will provide “honest and expert feedback” on your ideas or presentations before they are public. Cagan shares anecdotes where such feedback saved him from missteps.

The Manager’s Responsibility

Cagan places the burden squarely on the manager. When a product person delivers an underwhelming presentation or appears unprepared, the frustration should be directed at their manager, not the individual.

Preparation: Did the manager ensure the product person was prepared? Did they provide relevant, actionable, honest feedback? Did they insist on reviewing drafts or rehearsals?
Support: If the topic was outside the manager’s expertise, did they connect the product person with others who could provide useful feedback? If the person had public speaking anxiety, did the manager provide progressive opportunities or presentation training?
Impact on Trust: Empowered product teams thrive on trust, especially the PM’s trust with executives. An unprepared or naive appearance diminishes this trust, which is hard to regain.
“Only as Strong as Your Weakest Employee”: Cagan uses this adage to highlight that a manager’s reputation is tied to the performance of their team.

Ultimately, Cagan argues there’s no reason to be an imposter. By listening to the internal warning signs, seeking honest feedback, and committing to thorough preparation, product people can truly add value and overcome their fears, with the active support of their managers.

Chapter 19: Customer-Centricity

This chapter explores how to cultivate genuine customer-centricity within a product organization, distinguishing between mere claims and demonstrated commitment.

Beyond Lip Service: True Customer Care

While most leaders and product people claim to care about customers, Cagan points to observed behaviors as the true measure:

How does the company handle outages that impact customers?
How do they respond when product changes cause customer confusion or frustration?
How frequently do they actually sit down with real users and customers?
Genuine customer-centricity, Cagan argues, originates from the very top leadership of the company.

Making Customer-Centricity Real

Protect the Sacred Term “Customer”: A common problem is diluting the term “customer” to include stakeholders, internal teams, or even the CEO. Cagan insists that only actual paying users or the target audience of the product are true customers. Advertising partners, for example, are not the customer; they are partners who help reach the customer. This clear distinction prevents confusion and ensures the product team’s ultimate focus remains on the end-user.
Leverage Storytelling: Use powerful anecdotes like the FedEx Wedding Dress story or the REI Hiking Boot Replacement story (from Wild) to illustrate what true customer care looks like in practice. These stories embed the values in the culture.
Mandate Customer Interactions: Product teams (PMs, designers, engineers) should engage in a minimum of three one-hour customer interactions every week, ongoing. Managers should discuss these interactions in 1:1s, asking what was learned, and encouraging the PM to share these stories widely within the company to build their reputation as customer experts.
Demonstrate Urgency in Crises: The “true test” of customer-centricity is how the product person responds to a “showstopper” customer problem. It should elicit a sense of urgency, with the product person leading by example to find effective solutions. In truly customer-centric companies, leaders proactively offer help, sending a clear message of importance. However, if product teams fail to prioritize customer problems, executives may intervene, as they prioritize customer care over the empowered team model.
Innovate On Behalf Of Customers, Not By Asking What to Build: Cagan cautions against simply asking customers what features to build (like traditional focus groups). The job is to innovate on behalf of customers, solving their underlying problems in novel ways they might not have imagined possible.

Cagan concludes that sincere customer-centricity takes time (a year or more) to develop, requiring active coaching and willingness from the product person.

Chapter 20: Integrity

This chapter and the next (Decisions) cover two of the toughest yet most crucial aspects of successful product teams. Here, the focus is on integrity as the foundation for good decision-making and the bedrock of trust in empowered teams.

The Challenges of Maintaining Integrity

Integrity, particularly for product managers of empowered teams, is not an abstract concept but a daily requirement. It forms the basis of trust with executives, stakeholders, customers, and the product team itself. Cagan acknowledges that maintaining integrity is difficult due to constant pressures and conflicting demands (e.g., CEO demanding urgent delivery while the team needs more time, a frustrated customer, a stakeholder feeling unsupported). An experienced manager is crucial for coaching a new product person through these “landmines,” helping them understand priorities and navigate complex personalities.

The Three Essential Behaviors of Integrity

Cagan outlines three behaviors he focuses on when coaching product people on integrity:

Dependability: This begins with impressing upon the product person that their word and commitments are taken very seriously. Misleading others, even with good intentions, can permanently damage reputation and trust. This directly relates to the concept of high-integrity commitments.
- Informed Judgment: Commitments must be based on sufficient product discovery to reasonably assess value, usability, feasibility (with engineers’ input), and viability.
- Delivery: Once a commitment is made, the team must do everything possible to deliver. For empowered teams, this means the solution must actually work and solve the problem, not just be shipped.
- Reputation Building: Consistently managing high-integrity commitments builds a dependable reputation for the team.
The Company’s Best Interests: The product manager must always be perceived as acting in the best interests of the entire company, not just their own team or a “fiefdom.”
- Overall Objective: They must understand the company’s broader goals and be sincerely committed to its success. Equity-based incentive plans are effective here.
- Beyond Team: Opportunities to demonstrate this include helping other teams, going above and beyond for customers, publicly crediting others, and supporting decisions that benefit the broader organization even if not optimal for their specific team.
- Missionary Mindset: Leadership can gauge a team’s engagement by their passion for the company’s mission, not just their adherence to deadlines.
Accountability: With empowerment comes accountability for results. This does not necessarily mean being fired for every failure.
- Responsibility for Mistakes: Accountability means a willingness to take responsibility for mistakes, even when others may be at fault. A PM should ask what they could have personally done to mitigate risk (e.g., if engineering takes too long, did the PM properly assess feasibility risk during discovery?).
- Not Perfection: Mistakes will happen, but a PM’s career survives if they are generally dependable, act in the company’s best interests, and take responsibility for misses.

Cagan contrasts this with feature team PMs, who are often mere messengers. Empowered PMs are expected to creatively figure out solutions that work for both customer and business, possessing deep business knowledge.

Chapter 21: Decisions

Building on the foundation of integrity, this chapter focuses on how to coach product teams to make good decisions, especially as decision-making power is pushed down to the team level in an empowered model.

The Qualities of “Good Decisions”

“Good decisions” are not just logical or data-informed; they are also understandable and supportable by the product team, executives, stakeholders, and customers, even if there’s disagreement. This requires:

Integrity: The manager must be perceived as dependable, acting in the company’s best interests, and accountable.
Desired Outcome: Decisions should lead to successful outcomes, and the rationale should be clear and respected, even if others would have chosen differently. Parties involved should feel heard and respected.

Five Key Behaviors for Decision Making

Right-Size Decision Analysis: Not all decisions are equally important. Teams should assess the level of risk and consequence (e.g., easily reversible in hours vs. jeopardizing the company’s future). The depth of information gathering should match the impact. This is a key coaching area for managers to help novice PMs avoid underestimating or overestimating risk.
Collaboration-Based Decision Making: This is about leveraging the team’s expertise. The PM generally defers to the tech lead on technology/feasibility and the product designer on user experience/usability. If the decision is primarily about business viability, the PM collaborates with relevant stakeholders. This rejects consensus, voting, or benevolent dictator models.
Resolving Disagreements: Disagreements are normal and healthy in strong teams. When conflict arises (e.g., tech lead vs. designer), the critical step is to run a test. An experienced manager can coach the team on the least expensive and most appropriate discovery technique (e.g., a feasibility prototype) to collect evidence and resolve the debate with data. This greatly reduces the need for PMs to override their team or escalate decisions.
Transparency: Decisions, especially major ones, should be transparent. This helps others understand the rationale and prevents assumptions of ignorance or hidden agendas. For minor decisions, a simple note suffices; for major ones, the written narrative with its FAQ section is highly effective, anticipating objections and addressing them.
Disagree and Commit: Passionate debate is a sign of missionaries. However, once a decision is made (even after testing and continued disagreement), the team—especially the product manager—must commit to making it successful. This means understanding the rationale, even if it wasn’t their preferred choice, and actively working to implement it. Hiding personal disagreement or complaining to the team undermines trust and toxicity.

Cagan concludes that decision-making is a lifelong skill that develops with experience and active coaching. He also references Jim Barksdale’s three rules for decisions: “If you see a snake, kill it. Don’t play with dead snakes. All opportunities start out looking like snakes.”

Chapter 22: Effective Meetings

Acknowledging his personal bias against poorly run meetings, Cagan dedicates this chapter to coaching product teams on how to make meetings genuinely productive and purposeful.

Meetings: When and Why

Cagan differentiates between daily product team interactions (like a designer and PM looking at a prototype, which is “daily work”) and formal meetings that involve people beyond the immediate product team (stakeholders, executives, partners). The biggest pain point of meetings is their synchronous nature, requiring everyone to stop what they’re doing. If the purpose can be achieved asynchronously (e.g., status updates via email), that’s generally preferable.
The three main types of meetings in product organizations are:

Communication: To convey non-trivial or complex information that cannot be effectively sent asynchronously (e.g., an all-hands meeting on product strategy).
Decisions: When a decision is needed that exceeds the product team’s autonomy, usually due to company-wide impact or substantial risk. Cagan is a strong advocate for starting these meetings with everyone reading a written narrative to ensure informed discussion.
Problem Solving: When the best course of action is unknown, and the collective minds of the right people are needed to collaboratively find a solution (e.g., a postmortem after an outage).

Organizing Effective Meetings: A Coaching Framework

Cagan’s coaching framework for meetings includes:

Purpose: Clearly define the meeting’s objective (communication, decision, or problem-solving).
Attendees: Create two lists: essential attendees (whose absence would require rescheduling) and optional attendees.
Preparation: This is crucial for all meeting types. For communication, ensure clarity and suitable visuals. For decisions, have the written narrative prepared and reviewed. For problem-solving, gather relevant data and anticipate questions.
Facilitation: The organizer’s role is to facilitate effectively, ensuring the meeting achieves its purpose without policing.
Follow-up: Conclude the loop by notifying relevant parties of decisions or next steps.

The bottom line is that meetings should only be called if truly necessary, and they must be efficient, effective, and achieve their stated purpose. Poorly run meetings reflect negatively on the product team, especially the product manager, and can undermine trust with other executives.

Chapter 23: Ethics

This chapter tackles a sensitive but increasingly vital topic: ethics in product development. Cagan argues that ethical considerations are often overlooked or subsumed within other business viability concerns.

The Fifth Risk: “Should We Build It?”

Traditionally, product teams consider four risks: value, usability, feasibility, and business viability. Cagan advocates for adding a fifth explicit risk: ethical risk.

Why It Gets Lost: Business viability is already complex (covering sales, marketing, finance, legal, compliance, privacy), and there’s rarely a dedicated “ethics stakeholder” in most companies. This leads to ethical lapses and potential damage to the company, customers, environment, and society.
Airbnb’s Model: Cagan highlights Airbnb’s former Chief Ethics Officer, Rob Chesnut, as an example of a progressive company that explicitly prioritizes ethics. Chesnut argues that companies can no longer focus solely on shareholders; they must recognize all stakeholders (employees, guests, hosts, communities) and understand the impact of product solutions on them. Consistently making decisions that negatively impact stakeholders will harm the business long-term.

Applying Ethics to Product Work

Ethical considerations apply to every employee, but product teams are on the “leading edge” of new creations, bearing a special responsibility. Rob Chesnut’s advice for product teams:

Understand Implications: Consider the impact of solutions not just on revenue, but on the broader stakeholder community and the environment.
The “Published Online” Test: Would you be embarrassed if all internal emails, documents, and discussions about a product were published online?
Government Reaction: How would regulators react if they knew everything?
Personal Brand: Would you be proud of this product as part of your personal brand?
Culture of Inquiry: Foster a company culture where “everyone is comfortable asking the uncomfortable questions”—this protects against “disastrous ethical failures.”

Handling Ethical Issues

If an ethical issue is spotted, Rob Chesnut advises:

Speak Up Thoughtfully: Raise concerns in a clear, non-accusatory way, framing it as protecting the company’s best interests.
Understand Business Context: The product person needs a deep understanding of the business economics to be taken seriously and not perceived as naive. Managers should help here.
When to Leave: If a company fundamentally ignores ethical implications, Cagan (and Chesnut) encourage employees to leave. While most tech companies genuinely care about ethics, good intentions can still lead to unintended consequences.

Coaching product people on this “should we build it?” question is increasingly important, especially with the advent of new technologies like machine learning.

Chapter 24: Happiness

This chapter explores a less obvious but crucial aspect of management: contributing to the happiness of your team members. While not directly responsible for happiness, managers can easily cause misery or foster an environment of fulfillment.

Near-Universal Truths for Coaching Happiness

Cagan emphasizes that a manager’s role is to ensure their reports feel they are doing meaningful work, progressing in their careers, and building necessary relationships. While individual motivators vary, he identifies several common factors:

Meaningful Work: This is often the largest factor in happiness, surpassing even compensation (unless the manager is poor). Managers must clearly and explicitly articulate how an individual’s small team contributes to the company’s mission and positive impact on customers, reinforcing this frequently.
Personal Relationship: Managers should strive for their team members to like them for a specific reason: believing the manager is genuinely committed to their professional and personal success. Building trust through honest feedback and sharing personal challenges (without prying) humanizes the working relationship.
Personal Recognition: Most people want to feel valued, especially by those they respect, even if they’re uncomfortable with public fanfare. Beyond promotions, compensation, and equity, managers should offer frequent, personal forms of recognition (e.g., a thoughtful book, a gift certificate, tickets to an event). These gestures demonstrate genuine care.
Work Habits: Cagan distinguishes between working long hours out of choice (when deeply engaged in meaningful work) versus working long hours due to pressure or necessity (common in “mercenary” feature teams). In empowered teams, managers must watch for signs of burnout, encouraging time off and explaining the importance of recharging for creative problem-solving and long-term sustainability. This requires active coaching to prevent the “silly spiral” of managers modeling overwork.
Modeling Good Behaviors: Managers must lead by example. If they work crazy hours, they implicitly pressure their teams to do the same. Managers should be intentional about when they send emails, how they manage their own time, and openly share how they recharge. Actions speak louder than words.
Career Planning: Sometimes, true happiness for an employee means a different job or career path. Managers must be willing to honestly discuss career aspirations, provide clear paths to promotion, and even help individuals transition out of product roles if their passion lies elsewhere, as Marty did for a talented PM who wanted to write fiction. Managers play a significant role in their employees’ professional and personal lives.

The Legacy of Bill Campbell: The Greatest Coach

Cagan reflects on the profound influence of Bill Campbell, “The Coach of Silicon Valley,” who coached Steve Jobs, Larry Page, Sergey Brin, and Jeff Bezos. Campbell’s philosophy—”Empowered engineers are the single most important thing that you can have in a company”—and his belief that he measured his own success by “how many people who’ve worked for me… are great leaders now,” deeply resonated with Cagan. This highlights the ultimate purpose of product leadership: developing people to create great teams and products.

Chapter 25: Leader Profile: Lisa Kavanaugh

This profile highlights Lisa Kavanaugh, a long-time engineering leader who transitioned into coaching other technology leaders. Her career journey from HP to Ask.com (where she became CTO) and ultimately to full-time coaching underscores her passion for developing people and improving organizations.

Lisa’s Approach to Leadership Transformation

Lisa specializes in helping technology leaders evolve into strong, confident, and inspiring guides for empowered teams. She identifies four critical skills necessary for this transformation:

Self-Awareness: The ability to honestly recognize one’s own behaviors or traits that might be hindering progress, especially those that were assets earlier in a career but are now detrimental. For example, a leader known for reliable personal execution might struggle with micromanaging as their role scales, needing to realize that the skills that got them promoted won’t work for the next level.
Courage: The bravery to change deeply ingrained behaviors, especially when it means trusting others more. This involves courage to allow teams to make mistakes, give honest feedback, take a “leap of faith” in empowerment, and be vulnerable. Lisa shares an example of a leader who bravely initiated a difficult conversation with a peer to rebuild a damaged partnership, a turning point that required significant personal vulnerability.
Rules of Engagement: Establishing clear agreements with teams about the level of visibility and information the leader needs to feel comfortable granting autonomy. This involves defining what context the team needs and what signals they should provide to ensure the leader can trust them. These rules evolve as trust grows.
Disrupting Yourself: The commitment to breaking long-held habits that are at the core of one’s identity. This is like asking a leader to “disrupt herself.” It acknowledges that there will be mistakes and regressions, but the ongoing process involves identifying triggers and finding better responses. The initial phase is the hardest, but consistent practice leads to easier adoption of new, empowering behaviors.

Lisa’s experience demonstrates that transformation is possible if a leader truly desires to improve and possesses the courage to trust others, ultimately becoming the leader their company needs and their employees deserve.

Part III: Staffing

Chapter 26: Competence and Character

This pivotal chapter addresses common misconceptions about hiring and lays out the two essential qualities Cagan believes are necessary for building strong, empowered product teams: competence and character.

The Flawed Pursuit of the “10X Employee” and “Cultural Fit”

Cagan argues against two common, yet often harmful, hiring approaches:

Obsessing over “10X Performers”: While a 10X employee (someone contributing 10 times more than peers) might exist, their individual output doesn’t necessarily translate to 10X team results. If that individual brings toxic behaviors, they can cause far more damage to team morale, collaboration, and overall organizational performance than any individual contribution. Empowered teams succeed through collective effort.
Hiring for “Cultural Fit”: This is described as “one of the most damaging concepts for your efforts to build a great organization.” Often, “cultural fit” is a polite term for “hire people who look and think like we do,” leading to homogenous teams (e.g., primarily males with technical degrees from top universities). This stifles diversity of thought, which is crucial for innovation.

The Foundation: Competence and Character

Drawing from Stephen Covey’s definition of trust as “a function of two things: competence and character,” Cagan argues that these are the true non-negotiables for hiring onto empowered product teams:

Competence: The individual must possess the necessary skills for the role (e.g., as an engineer, product designer, or product manager).
- The “A’s Hire A’s, B’s Hire C’s” Principle: A manager who is not competent themselves will struggle to assess talent, leading to poor hires.
- Hiring for Potential: It’s acceptable to hire based on potential (e.g., a university hire) only if the hiring manager is committed to actively coaching that person to competence and taking responsibility if it doesn’t work out.
- No Lasting Empowerment Without Competence: Competence is essential for the team to earn the trust of management and leadership.
Character: Beyond skills, the individual must have strong character.
- The “No Assholes Rule”: Inspired by the New Zealand All Blacks rugby team’s policy, this means proactively filtering out individuals who, regardless of skill, are toxic to team dynamics. These individuals often hide their problematic personalities in interviews but are known by past employers.
- Embracing Diversity: Instead of narrowing the talent pool for “fit,” keep it broad and actively seek people who think differently—from diverse backgrounds, educational experiences, work histories, and life experiences. This directly addresses the problem of homogenous thinking and significantly increases the chances of solving hard problems effectively.

Cagan concludes that many companies hire people who are a “cultural fit” but lack competence, or they justify hiring an “asshole” because of perceived exceptional skill. Both scenarios undermine the necessary trust for empowered teams.

Chapter 27: Recruiting

This chapter argues that recruiting is a proactive and continuous responsibility of the hiring manager, not a reactive process driven by HR.

The Active Role of the Hiring Manager

Most companies treat staffing as an HR-driven process, where the hiring manager passively waits for resumes. Cagan asserts that in strong product companies, the hiring manager actively recruits talent, much like a college or professional sports coach. This means building relationships and actively persuading desired candidates to join.

Speed and Diversity: Proactive recruiting is the fastest way to improve diversity because it allows managers to seek out individuals with different educational backgrounds, problem-solving approaches, life experiences, and strengths, rather than waiting for “cultural fit” candidates to apply.
Building Your Network: Recruiting is an ongoing activity. Managers should continuously meet people at industry conferences, professional meetups, competitors, partner/customer visits, and through referrals. These interactions can evolve into mentoring relationships and ultimately lead to coaching opportunities.
Thought Leadership: Hosting talks, writing company blogs (like Etsy’s Code as Craft), and showcasing great product work can help build the organization’s reputation and attract candidates.
Internal Talent: Managers should also look for high-potential individuals within their own company, in various departments (engineering, finance, marketing, sales, legal). The goal is to ensure people are in roles where their talents are best utilized.
Patience and Persistence: Recruiting can be a long game, sometimes taking years to develop a relationship with a desired candidate, nurturing their interest in product roles and discussing career goals.
Leveraging Product Vision: The product vision itself is a powerful recruiting tool, attracting people who want to work on something meaningful and be “missionaries.” Successful products also attract talent.

Making Recruiting a Priority: A Personal Anecdote

Chris Jones shares a personal story of being a new product manager overwhelmed with work, passively waiting for HR to find candidates. His manager intervened, stating that hiring a new product manager was his single most important task, demanding he spend a minimum of 50% of his time on it. The manager then coached him on actively brainstorming strategies for tapping his network and driving the process, shifting his “mental framing” from reactive sourcing to proactive recruiting. This experience profoundly changed Jones’s view of leadership.

The Folly of Outsourcing Core Product Roles

Cagan reiterates his strong stance against outsourcing core product roles (PMs, designers, engineers, data scientists). While temporary outsourcing for specific tasks (e.g., test automation, large migrations) might be acceptable, outsourcing critical product development functions effectively creates “mercenary teams” and almost certainly kills any chance of continuous innovation. Despite perceived cost savings, it inevitably leads to higher overall costs (due to overhead, communication issues) and, more importantly, the opportunity cost of losing the ability to innovate, which is vital for survival. A smaller team of internal “missionaries” will almost always outperform a larger, more expensive outsourced team.

Chapter 28: Interviewing

Building on the proactive nature of recruiting, this chapter details how to conduct an effective interview process that identifies competent people of character and elevates the team’s average capability.

The Hiring Manager’s Ownership of the Interview Process

The hiring manager is ultimately responsible for the effectiveness of the interview team and the candidate’s experience. The overarching goal is to hire individuals who will raise the bar for the team.

Avoiding Inclusivity Over Quality: A common pitfall is making the interview team too large or inclusive to ensure everyone has a say. This often lowers the bar. Instead, the hiring manager must carefully select and curate the interview team, choosing individuals who are both competent and have strong character—people a top candidate would be proud to work with and enjoy.
Clear Responsibilities for Interviewers: Each interviewer must understand specifically what skills or experiences they are assessing and be prepared.
Resolving Open Questions: The interview process should be designed to resolve all open questions by the end of the day. Interviewers should communicate their findings to the next interviewer, and the hiring manager (often the last interviewer) should extend time as needed to get clarity. It’s also acceptable to end the interview day early if it’s clear the candidate is not a fit.
Hiring for Potential (with Caveats): While generally seeking demonstrated competence, hiring for potential (e.g., university hires) is acceptable if the hiring manager explicitly communicates this to the interview team and personally commits to intense, often daily, coaching for months. They must also take responsibility if the hire doesn’t reach competence.
Seeking Diversity, Not Sameness: Interview teams should be reminded that the goal is not to find “more of the same.” Innovation thrives on diversity of thought, education, life experiences, cultures, and problem-solving approaches.
Prioritizing Skills Over Domain Knowledge: For most positions, it’s better to hire for the right product skills. A skilled person can learn a new domain much faster than someone with deep domain knowledge can acquire the necessary product skills. In fact, too much domain knowledge can be a liability if the person assumes they are the customer.

My Favorite Interview Question (Chris Jones)

Chris Jones shares a unique interview question designed to assess a candidate’s self-awareness and ability to admit weaknesses. Late in the interview, he asks the candidate to stack rank four broad work attributes (execution, creativity, strategy, growth) from strongest to weakest. The setup disarms the candidate, as there’s no “right” answer, encouraging an honest conversation about areas for growth. This also serves as a check on the hiring manager’s own biases, helping to avoid hiring a team of clones.

Chapter 29: Hiring

This chapter details the final steps in the staffing process: extending an offer and successfully bringing a new employee onboard. While compensation and HR compliance play a role, the hiring manager’s personal involvement is paramount.

The Final Stretch: Offer and Close

Speed is Critical: If a strong candidate has been identified, it’s crucial to extend an offer within 24-48 hours. Delay signals indecisiveness and risks losing the candidate to other offers.
Personal Reference Checks: The hiring manager must conduct reference checks personally, not delegate them. The most important question to ask is: “Would you hire this candidate again?” These checks are invaluable for identifying toxic personalities that might have been hidden during interviews. Cagan also suggests reviewing a candidate’s social media behavior for insights into their interactions with others.
The Personal Commitment: The most impactful part of the offer, from the candidate’s perspective, is the hiring manager’s personal promise to invest in coaching and developing them to reach their potential. This commitment from a dedicated manager often outweighs other factors, especially for top talent.
CEO/Leader Outreach: For particularly strong candidates, a call from the CEO or another key leader can be a powerful differentiator, signaling the company’s commitment and setting the relationship off to a good start.

Cagan concludes that while the employment offer is made on behalf of the company, the act of hiring talent is deeply personal—a commitment from the manager to the individual’s growth and from the new hire to the company’s vision.

Span of Control: Balancing Management and Coaching

This section addresses the crucial decision of how many direct reports a manager should have. It argues against rigid, standardized ranges and instead emphasizes factors influencing the time needed for effective coaching:

Level of Operational Responsibility: If a manager has significant operational duties (e.g., product strategy, design strategy, architecture debt), their span of control should be smaller.
Employee Experience Level: Managers with less experienced reports (who require more intensive coaching to reach competence) should have fewer direct reports (e.g., 4-5 instead of 6-8).
Manager Experience Level: More experienced coaches are more efficient and effective, potentially allowing for a slightly larger span of control.
Organizational Complexity: In larger organizations, the “connecting the dots” and “managing up and across” demands increase significantly, requiring more manager time.

Typical Ratios:

Group Product Manager (Player-Coach): Smallest span, typically 2-3 direct reports.
Engineering Manager: Largest span, possibly 10-15 individual contributor engineers of varying levels.
Most Managers: Somewhere in between, often 5-7 direct reports.

Companies that boast very flat structures with large spans of control often either pay a premium for already highly experienced talent or completely neglect coaching and development.

Chapter 30: Remote Employees

This chapter addresses the increasing reality of remote or distributed teams, acknowledging that while co-location has distinct advantages for innovation, practical considerations often necessitate remote work. The focus is on how to maintain effectiveness in discovery and delivery despite geographical distance.

The Challenges of Remote Product Discovery

While remote teams can perform well in delivery (coding, QA), the real challenge lies in product discovery, which relies on intense, spontaneous collaboration. Cagan highlights three persistent problems in remote settings that can significantly damage innovation:

Reverting to Artifacts: When PMs, designers, and tech leads are separated, there’s a strong pull to create formal “artifacts” (e.g., PM writes requirements, designer creates wireframes, tech lead plans based on those) instead of real-time collaborative problem-solving. This reverts the process to a less effective, Waterfall-like handoff, where innovation suffers, and focus shifts from outcomes to output. Cagan emphasizes the need to continuously fight this tendency and prioritize live, synchronous discussions. Prototypes should remain the primary artifact during discovery.
Erosion of Trust and Psychological Safety: Distance can diminish the natural filters and sensitivity of in-person interaction. Misunderstandings increase, and it’s easier to inadvertently (or intentionally) be cruel or insensitive in written communication (email, Slack). This undermines psychological safety, which is essential for innovation. Managers must actively coach employees on online interactions, stressing that sensitive topics should always be handled over video to leverage facial expressions, tone, and body language, which are vital for maintaining trust.
Fragmented Time: Not all remote employees have equally conducive work-from-home environments. Some may find increased productivity, while others (especially those with childcare or family obligations) struggle to find contiguous, uninterrupted time for deep work. Managers must be flexible and accommodate different schedules, recognizing that finding even one solid hour of overlapping, uninterrupted time for key team members can be challenging but worthwhile.

Cagan concludes that while these challenges are real and difficult, they can be mitigated through awareness, active managerial coaching, and intentional efforts to preserve the collaborative spirit and trust of an empowered product team. The distributed team can still achieve good product discovery work if these issues are addressed.

Chapter 31: Onboarding

This chapter stresses the critical importance of the first three months for a new employee. Effective onboarding is crucial for setting the tone for their entire tenure and maximizing their contribution.

Critical Checkpoints and Manager’s Responsibility

The hiring manager’s work is far from over once a candidate is hired. The onboarding period is crucial for ensuring success:

Initial Impressions: Many first impressions are made quickly, especially by senior leaders, and these are hard to correct.
Ramp-Up is Universal: No matter how competent, every new employee needs time to learn the company’s customers, people, culture, technology, and industry.
Early Checkpoints: Cagan suggests specific checkpoints:
- End of Day 1: Has the new hire made a friend, and do they understand expectations?
- End of Week 1: Have they personally met every team member?
- After First Paycheck: Subconscious assessment of their choice to join.
- After First Month: Good understanding of the company and their potential.
- After 60 Days: Has the new hire achieved a “public win” to establish their value?
Establishing Trust: The manager must establish a relationship based on trust, where the new hire feels comfortable being coached and believes the manager is committed to their success. Managers should share their own development journey to address any defensive behavior or insecurity from the new hire.
Consequences of Neglect: Cagan admits his “biggest regrets” as a manager were times he failed to invest sufficiently in onboarding, leading to “countless hours of grief and damage control.”

Onboarding Focus: Competence and Relationships

The primary focus of onboarding is:

Establishing Competence: Using the initial assessment (Chapter 8) to create a coaching plan, providing time and opportunities for learning, and personally ensuring the new employee achieves competence.
Building Solid Relationships: Fostering connections with the manager, the product team, and soon, key executives and stakeholders.

Deep Customer and Business Knowledge (for PMs): This is foundational. It includes:
- Customer Visits: A series of visits with extensive debriefs covering not just customers but also go-to-market mechanisms (sales, marketing) and customer service.
- Financials: Time with the finance team to understand critical KPIs and their calculation.
Proactive Introductions: Once knowledgeable, the new employee should be personally introduced to key leaders and stakeholders by the manager, with the manager “vouching” for their preparation and collaborative intent. The manager should then follow up with these leaders to track the new employee’s progress.

APM Programs: Developing High-Potential PMs

Cagan highly recommends establishing Associate Product Manager (APM) programs (pioneered by Google) for medium to larger companies. These programs address the scarcity of strong PMs by taking high-performing/high-potential individuals (from internal or external sources) and putting them through a 1-2 year intensive coaching program to develop them into exceptional PMs and future leaders.

Key Principles:
- Strong, Proven Leaders: Requires exceptional leaders who are willing and able to provide intense, often weekly, coaching.
- High Bar for Acceptance: Only the “best and brightest” are accepted.
- Thorough Assessment: Individualized coaching plans based on skill gap assessments.
- Hands-on Learning: APMs are put on key product teams but with ongoing, intense coaching.
Benefits: APM programs are effective for improving diversity (as they select based on potential, not just experience) and ensure a continuous supply of strong product managers.

Chapter 32: New Employee Bootcamp

This chapter, contributed by SVPG partner Christian Idiodi, offers a detailed look at his highly effective New Employee Bootcamp designed to set product people up for success from day one, going far beyond typical new-hire orientations.

The Problem: Capable Hires Still Fail

Idiodi observed that even highly capable product people from successful companies often struggle in new organizations because they lack crucial context and understanding of how things actually get done. Standard new-hire orientations are insufficient for preparing product people for the complexities of decision-making, trust-building, and organizational dynamics. The PM’s need for deep customer, business, industry, and product knowledge isn’t magically acquired.

Idiodi’s 5-Day Intensive Bootcamp Program

Designed for product managers, product designers, and tech leads, this program addresses the gap between individual capability and organizational success:

Personal Growth Component (Daily Start): Each day begins with inward-focused exercises (communication, personality tests, personal skills, career growth planning). This signals the company’s commitment to the employee’s holistic development and ensures leaders are “healthy” to coach others (“put on your own oxygen mask first”).
Strategic Context (Daily Product Training Topic): This is the core knowledge transfer, specific to the company’s history and goals.
- Day 1: Understanding the Customer: Goes beyond generic “customer understanding” to delve into the company’s specific customer history, vision, financial models, and customer discovery processes.
- Throughout the Week: Covers validation, building/prioritizing, learning/measuring, and go-to-market strategies, all contextualized to the organization’s unique ways of working.
Guest Speakers (Internal Product People): After the strategic context session, a current product person from the company shares their personal experiences related to the topic. This is crucial for establishing relationships, building trust, and providing real-world insights into team dynamics, stakeholder collaboration, and navigating the company environment.
Product Workshop (Daily Afternoons): Participants immediately apply the morning’s learnings in practical, on-the-job scenarios. Importantly, their actual team members are brought in, creating a safe space for practicing collaboration and shortening the learning curve for inter-team dynamics.
Reinforces Culture: The Bootcamp reinforces a culture of learning and growth. New hires leave knowing “the next, right thing to do,” equipped to make quick decisions, and with pre-built relationships that accelerate results.

The central message is that companies don’t hire smart product people to tell them what to do; they hire them to solve hard problems in ways customers love, yet work for the business. This requires significant investment beyond a mere orientation packet, directly enabling empowerment by providing the necessary information and fostering trust.

Chapter 33: Performance Reviews

This chapter offers a critical perspective on annual performance reviews, arguing that while often unavoidable due to compliance, they should never be the primary feedback mechanism.

Performance Reviews: Too Little, Too Late

Cagan’s stance is blunt: if it were up to him, annual performance reviews would be “entirely dispensed with.” He acknowledges their reality for HR compliance and salary administration but emphasizes their fundamental inadequacy as a tool for people development.

The Primary Feedback Tool: The weekly 1:1 is the essential, ongoing feedback mechanism. It’s continuous, timely, and focused on development.
No Surprises: The most critical principle is that there should never be any performance-related surprises in an annual review. If an employee learns of negative feedback for the first time during their review, the manager has “utterly failed.”
Managerial Failure: Cagan describes the common scenario of conflict-averse managers who avoid giving necessary constructive criticism. When HR then requires documentation of issues for a termination or performance plan, the employee is blindsided. Cagan treats such situations as a “serious performance problem” of the manager, often requiring the manager to show their weekly 1:1 notes and, if necessary, for Cagan himself to directly intervene with the employee.
Basic Managerial Skill: The ability and willingness to provide honest, timely, and constructive feedback is the “most basic skill” for a competent manager. If hints aren’t taken, the feedback must be made “unmistakably clear.”

Ultimately, managers should perform reviews for compliance, but their true development work happens in the continuous, active coaching provided during weekly 1:1s.

Chapter 34: Terminating

This chapter addresses the most difficult aspect of being a people manager: terminating an employee. Cagan provides guidance on handling these sensitive situations responsibly and with the broader organizational impact in mind.

Decisive Action: Beyond the Problem Employee

Cagan stresses that while terminations are unpleasant, a manager must consider not just the individual, but also:

The Rest of the Team: How are other team members being impacted (e.g., carrying extra burden, dealing with issues)?
Organizational Message: What message does failing to address the problem send to the broader team, organization, leaders, and stakeholders?
Balance: Managers must balance compassion for the individual with their responsibility to the company and other employees, navigating company culture and local employment laws. HR partners assist with compliance.

Two Main Situations for Correcting Hiring Mistakes

Cagan distinguishes between two primary reasons for termination:

Lack of Competence (Despite Coaching):
- Process: After sincere, ongoing coaching efforts (typically 3-6 months), if the employee still cannot perform at the necessary level, the manager must acknowledge it’s not working. This lack of progress should have been communicated with “increasing urgency and clarity” in weekly 1:1s.
- Responsibility: Cagan views this as partly the manager’s (or company’s) fault for the initial hiring mistake. In these cases, he believes the manager has a responsibility to help the person find a more suitable position, either internally or externally, where they can be successful.
Toxic Behavior:
- Identification: This refers to serious behavioral issues that damage trust, psychological safety, and leave others feeling disrespected (distinguished from occasional bad days).
- Correction Attempt: Managers should determine if it’s a temporary issue or a chronic problem, and if the person is willing and able to control their behavior. An attempt to correct should still occur (3-6 months is normal).
- Protection of Team: If the problem persists, the focus shifts to protecting the rest of the team and organization.
- No Re-placement: In these cases, Cagan is not willing to help the person find another job. He is honest about their behavior and its impact on team culture.
- Impact: While toxic behavior sometimes comes with strong skills, removing such individuals is “always the right thing to do.” While there may be temporary difficulty, the broader organization is usually grateful for the improved workplace atmosphere, and others will often rise to the occasion.

Cagan concludes that dealing with hiring mistakes is never enjoyable, but it is “truly essential” for building a strong product organization.

Chapter 35: Promoting

While terminations are the least favorite part of staffing, promotions are Cagan’s favorite, viewing them as the most visible and tangible sign of a manager’s success.

The Manager’s Role in Career Progression

Visibility of Success: When a manager’s people are promoted, it’s a direct reflection of their effectiveness.
Career Ladders: Most companies have clear career ladders (e.g., Engineer to Senior Engineer, PM to Senior PM, or cross-functional shifts like Senior Product Designer to Manager of Product Design).
Understanding Aspirations: Managers should actively engage in career discussions with their employees, understanding whether they aspire to remain individual contributors (and reach senior levels within that track), move into leadership, or even start their own companies.
Personal Commitment: Cagan promises his reports that if they put in the effort, he will do his best to help them reach their goals, considering it his job.
Clear Path to Next Goal: This involves:
- Assessment: Comparing the employee’s current knowledge and skills against the requirements for the new role.
- Gap List & Plan: Generating a list of gaps and discussing how the employee can learn and demonstrate the necessary skills. Self-assessments can be useful for comparison.
Advocacy: Once qualified, the manager does “everything I can to get her that promotion.” While external approvals or immediate openings might be factors, the manager prepares the employee to seize the opportunity when it arises. The more skilled the person, the more valuable they are to the company, making promotion a win-win.
IC to Manager Promotion: This is a special case. It’s not just a senior role but a fundamentally different job requiring distinct skills. The manager must ensure the individual understands these requirements and wants the role for the right reasons (not just money, which is why dual-track career ladders are important in tech).
Creating More Leaders: Cagan echoes Tom Peters: “Leaders don’t create followers, they create more leaders.” He expresses deep pride in seeing people he coached become exceptional leaders themselves.

Retention: The Manager’s Impact

Cagan reiterates the adage, “People join a company, but leave their manager.” While some attrition is normal (spouse relocation, starting a startup, retirement), consistent departures of highly valued employees often signal a problem in management. Cagan conducts exit interviews to gather feedback for the manager. He asserts that managers genuinely concerned about their employees’ careers, who constantly coach and promote, rarely have retention issues; instead, they gain a reputation that attracts talent to their teams.

Chapter 36: Leader Profile: April Underwood

April Underwood, former CPO of Slack, shares her diverse path to product leadership, emphasizing the evolving nature of the product manager role and the importance of functional breadth. Her career spanned engineering, product management, and leadership roles at Travelocity, Apple, Google, Twitter, and Slack, culminating in her advisory and investment work with #Angels.

April’s Insights on Product Leadership

Underwood highlights several key patterns from her experience:

The Evolving Product Manager Archetype: She notes that the “ideal” product manager has changed over time. Early in her career, the archetype was a business-minded MBA. As technology advanced, more technical PMs were favored (e.g., with the rise of mobile apps, design-savvy PMs were prized). When innovation shifted to operations (e.g., rideshare, delivery), the PM-as-general-manager (business-oriented) archetype resurfaced.
- Intentional Hiring: As VP/CPO at Slack, Underwood was deliberate in defining the “flavor” of PM needed for each role, whether it was specific functional experience, subject matter expertise from other products, or experience in particular company growth stages. This allowed her to narrow candidates and hire the right fit for each unique need.
Functional Breadth as a Prerequisite for Company Leadership: Underwood argues that the best product leaders are not just skilled at defining and building products; they deeply understand adjacent functions.
- Holistic View: Insights from marketing, partnerships, finance, and other functions are crucial inputs for building successful products. Products must always serve the broader company mission, not just the product itself.
- Valuable “Sidesteps”: Her own career involved various functional “hats” (sometimes by choice, sometimes by necessity). These “sidesteps” became her most valuable asset, enabling her to understand how to hire and develop leaders for diverse roles, build bridges across organizational lines, and consistently align product with the overarching business mission.

April’s journey illustrates that there are many paths to product leadership, and that a broad understanding of different business functions is essential for moving from product executive roles to broader company leadership.

Part IV: Product Vision and Principles

Chapter 37: Creating a Compelling Vision

This chapter emphasizes that a product vision is a critical, high-leverage “product artifact”—a persuasive tool that serves numerous vital purposes beyond a simple mission statement. It details what makes a vision strong and compelling.

The Power and Purpose of a Strong Product Vision

A well-crafted product vision is fundamental to an empowered product organization. It’s the “how” we plan to deliver on the company’s mission.

Customer-Centricity: The vision keeps the organization focused on the customer’s needs. While company objectives often relate to business growth, the vision ensures that benefits are derived from providing real value to customers. It’s told from the perspective of users, demonstrating how their lives will improve. Cagan stresses collaborating with a strong product designer to create a compelling visiontype (a conceptual, high-fidelity prototype) or video.
North Star for the Organization: The vision acts as a unifying “North Star,” guiding all product teams towards a common goal, regardless of their specific area of work. It helps every team understand how their piece contributes to the larger purpose (e.g., addressing global warming through mass-market electric cars). This prevents teams from getting lost in their individual problems and fosters understanding of the “endgame.”
Inspiration and Meaningful Work: A compelling vision inspires ordinary people to create extraordinary products. It provides meaningful work that goes beyond a mere list of features, exciting teams month after month, year after year.
Leveraging Industry Trends: A strong vision identifies and leverages major industry trends (e.g., mobile, cloud, machine learning, augmented reality) and enabling technologies that offer new, just-now-possible solutions for customers. It distinguishes true trends from fleeting fads. Importantly, customers care about solved problems, not technology itself.
Informing Architecture: The product vision provides crucial clarity for the engineering organization, guiding architectural decisions to support long-term needs and avoid costly re-engineering.
Powerful Recruiting Tool: The product vision is often the single most powerful tool for attracting strong product people who seek meaningful work.
Evangelism Tool: It helps secure necessary help and support from across the company—executives, investors, sales, marketing, customer service, and key influencers.

Ownership of the Product Vision

While the Head of Product (CPO) is responsible for ensuring a compelling product vision exists, its creation is a collaborative effort:

Cross-Functional Collaboration: The CPO must work closely with the Head of Design and Head of Technology, as the vision integrates customer experience, enabling technologies, and business needs.
CEO Buy-in: The CEO must feel a “very real sense of ownership” of the vision, as they will need to “sell” it thousands of times internally and externally. The product leader’s role is to help the CEO feel shared ownership.

The product vision is an art form, a persuasion tool that must be compelling, inspiring, and empowering without being overly prescriptive about details, leaving those for the product teams to discover.

Chapter 38: Sharing the Product Vision

This chapter focuses on the crucial act of communicating the product vision, emphasizing that a compelling vision is only powerful if effectively shared and understood.

Effective Communication Strategies

Investing time in how the product vision is communicated is as important as its creation. The goal is to inspire and persuade.

Visiontype and Video: PowerPoint presentations rarely inspire. The minimum is a visiontype—a high-fidelity conceptual prototype that depicts the future product experience (3-10 years out). Many companies go further by producing a scripted video showcasing this visiontype, leveraging music and emotion to increase impact. This may show different user types interacting with the future product. Product designers play a key role in crafting and communicating this experience.
Storyboarding: Similar to film, storyboarding can effectively communicate the vision, focusing on emotion and customer experience rather than technical details.

Validating the Product Vision: Yes and No

A common question is whether modern discovery techniques can validate the product vision.

Yes (Demand): You can validate the demand for the vision. You can determine if customers have the problems you think they have and if those problems are serious enough to make them open to new solutions if they were available today.
No (Solution): You cannot validate the solution itself because it doesn’t exist yet and will take years of discovery work to uncover. Pursuing a product vision requires a “leap of faith”—a belief that the organization can discover a solution that fulfills the promise of the vision.

Product Vision as a Powerful Tool

The product vision serves multiple strategic purposes when effectively shared:

Recruiting Tool: It is one of the most powerful tools for attracting strong product people who seek meaningful work and want to be “missionaries.” Leaders must be persuasive in articulating this vision to candidates.
Evangelism Tool: It’s essential for getting buy-in from executives, investors, stakeholders, sales, marketing, customer service, and key influencers. All these groups need to understand the future and contribute to its realization. Evangelism is never finished; it requires constant, repeated communication through various channels.

Sharing Product Vision vs. Roadmaps: A Critical Distinction

In companies with direct sales forces, there’s often pressure to share product roadmaps with customers, who are making significant long-term investments. However, Cagan strongly advises against this.

Roadmap Problems: Roadmaps typically list features and release dates. Most specific features on a roadmap end up not solving the underlying problem or providing the expected value, leading to wasted effort. Changing a roadmap after a customer has made a purchase decision based on it becomes extremely difficult, leading to legal ramifications if not delivered.
Vision as the Preference: Customers are often “hungry for” the product vision—the long-term direction and benefits—even if they don’t use that terminology.
“Stubborn on Vision, Flexible on Details”: Product leaders should be stubborn about the long-term vision but flexible on the tactical roadmap. Sharing the vision is safe and helps validate demand; sharing a roadmap is dangerous because it prematurely commits to specific solutions that will inevitably change. Exceptions exist for specific integrations treated as high-integrity commitments.

Product Vision and Architecture: Guiding Engineering Decisions

The product vision is crucial for the engineering organization. It provides the necessary clarity for engineers to make architectural decisions that will support the long-term needs of the vision, even if capabilities like machine learning are years away. This prevents costly re-engineering down the line. A clear vision also informs the team topology, especially for platform teams. This is particularly vital for organizations struggling with technical debt, as a re-platforming effort without a clear product vision will likely fail to build what’s truly needed for the future.

Chapter 39: Product Principles and Ethics

This chapter highlights the importance of product principles as a complement to the product vision, guiding countless daily decisions made by empowered product teams, particularly in areas involving trade-offs and ethics.

Product Principles: Guiding Trade-Offs and Empowerment

Product principles are statements of values and beliefs that inform product decisions. When teams are empowered to solve problems and make decisions, they need context beyond just the vision. Principles provide this context by:

Informing Decisions: Guiding teams when faced with difficult choices and trade-offs during product discovery and delivery.
Prioritizing Values: Illuminating which values are prioritized when conflicting goals arise. For example, a common trade-off is between ease of use and security (e.g., in a rapid growth phase, teams might prioritize ease of use, potentially downgrading security importance). Principles clarify the company’s stance on such conflicts.
Providing Guidance: While impossible to anticipate every situation, principles offer clear guidance for the majority of normal product decisions, reducing the need for constant escalation.

Ethics: An Explicit Product Principle

Cagan reiterates his advocacy for explicitly considering ethical implications by adding “Should we build it?” as a fifth product risk (beyond value, usability, feasibility, and viability). This is where product principles can be particularly powerful.

Addressing Malicious Use: For example, a product solution might provide value when used as intended, but could cause harm if used maliciously. Product principles can define the team’s responsibility in preventing such unintended use.
Proactive Guidance: Product leaders should create principles that specifically guide ethical decision-making, encouraging teams to proactively consider and discuss potential ethical issues. This helps ensure that the product vision is realized in a way that benefits all stakeholders and society.

Product principles are often used by teams most frequently in their daily discovery work and are increasingly important with new technologies, especially machine learning.

Chapter 40: Leader Profile: Audrey Crane

This profile features Audrey Crane, a product design leader and partner at DesignMap, whose unique background in pure mathematics and theater profoundly shaped her leadership style. She learned from design pioneers like Hugh Dubberly and worked at pivotal internet companies like Netscape.

Audrey’s Leadership Style: Lessons from Theater

Audrey’s management philosophy is deeply rooted in her early experiences in theater production. She likens her role as a leader to that of a director:

The Vision: Just as a director sets a shared artistic, strategic, and pragmatic goal for a diverse cast and crew, Audrey believes her job is to set a clear vision for her teams. She loves the “big-picture puzzle solving” of gauging constraints, weighing goals across the organization and with customers, assessing capabilities, and creating a vision for how to solve all of it. She collaborates on goals before finalizing them.
It’s Not About You (“No Line Readings”): A fundamental rule in directing is “no line readings”—the director dictating an actor’s delivery. This implies either the director’s incompetence or the actor’s inability to bring their own unique interpretation. Similarly, Audrey believes a leader’s job is not to get people to mimic their own approach, but to bring out the best in each team member. She acknowledges that her team members are better at many things than she is, and her role is to organize their collective brilliance toward a common goal.
Bring Their Best: A director’s highest responsibility is to enable each team member to contribute their unique skills in service of the shared goal. Audrey applies this by identifying “talent and aptitude in people who weren’t aware of it themselves” and then convincing them of their strengths. This allows teams to operate with passion and excel, creating something much greater than any individual could achieve. Teams where everyone operates in their area of brilliance are “transformational.”
Critique: Just as a director regularly “gives notes” (constructive feedback) on performances, Audrey emphasizes the importance of providing clear, direct feedback. This is a given in any relationship with a director and is essential for mutual respect and collaboration.
Celebration: Theater productions have built-in celebrations (opening night, wrap parties) to acknowledge collective accomplishments. Audrey believes business doesn’t celebrate enough and actively seeks ways, large and small, to honor individuals and teams.

Audrey credits mentors like Marty Cagan and Hugh Dubberly, who inspired her to reach potential she didn’t believe in herself. She also acknowledges Ken Norton for teaching her the crucial partnership between product and design. Her leadership style focuses on assembling talented individuals, inspiring them with a story, coaching them to reach their potential, and then watching them create something special together.

Part V: Team Topology

Chapter 41: Optimizing for Empowerment

This chapter introduces the concept of team topology as the intentional design of how product people are organized into teams. It stresses that this is one of the most critical decisions product leaders face, directly impacting the level of team empowerment.

Intentional Design vs. Organic Growth

Many companies allow their team topology to happen “organically”—mirroring existing org charts, engineering skill sets, or stakeholder responsibilities. This passive approach often creates unnecessary dependencies and complications that work against team empowerment. Cagan asserts that topology decisions must be intentional and revisited periodically, especially if existing structures hinder progress. The goal is to optimize for empowerment.

Balancing the Three Interrelated Goals

Optimizing for empowerment requires carefully balancing three key goals when designing a team topology:

Ownership: Each product team needs a meaningful scope of responsibility for functionality, experience, quality, performance, and technical debt.
- Meaningful Scope: Teams feel more motivated and pride of ownership when they are responsible for a significant problem or area, rather than feeling like a “small cog in a big wheel.”
- Right-Sized Scope: While broader ownership generally aids empowerment, a scope that’s too vast for a team’s size and skill set can lead to high cognitive load (too much complexity to master) and hinder innovation.
- Clarity of Ownership: Ambiguity about which team owns what work undermines empowerment. A good topology resolves most ownership questions.
Autonomy: This means that when teams are given problems to solve, they have sufficient control to solve those problems in the best way they see fit.
- Minimizing Dependencies: While some inter-team dependencies are inevitable, an empowering topology actively minimizes them. A structure that divides teams strictly by technology subsystems (e.g., database team, UI team) often makes it difficult for any single team to deliver a holistic customer solution.
- Trust in Decisions: Leaders trust teams to use product discovery to explore options and make good decisions because they are closest to the problem.
- Enabling Business Outcomes: Autonomy directly contributes to a team’s ability to achieve necessary business outcomes.
Alignment: This refers to how well the team boundaries align with other aspects of the strategic context.
- Improved Empowerment: High alignment generally leads to fewer dependencies, faster decisions, and a stronger connection to business-level outcomes.
- Alignment with Architecture: Ideally, the architecture is based on the product vision. A topology aligned with this technical architecture will also be aligned with the product vision, allowing teams to own meaningful scope and make significant decisions. However, technical debt or legacy systems can create misalignment and hinder progress.
- Alignment with Business: This includes how teams relate to business units, go-to-market strategies, customer types, or market segments.

Cagan emphasizes that there is no single “perfect” team topology. It requires careful consideration of trade-offs, and product, design, and engineering leadership must determine the topology together to balance their respective needs.

Chapter 42: Team Types

This chapter categorizes product teams into two fundamental types: platform teams and experience teams. Understanding these distinctions is crucial for designing an effective team topology that optimizes for empowerment. The chosen topology must consider both the underlying technology architecture and the broader strategic context.

Platform Teams: Enabling Leverage and Encapsulating Complexity

Platform teams exist to provide common services or manage complex, specialized areas of the product, thereby creating leverage for other teams. They allow services to be implemented once and reused across multiple parts of the product.

Examples of Leverage:
- Authentication and authorization services.
- Libraries of reusable interface components (e.g., design systems).
- Tools for developers (e.g., test and release automation, DevOps).
Examples of Encapsulated Complexity:
- Abstractions for integrating with legacy systems.
- Payment processing.
- Highly specialized tax calculations.
Importance: While end customers may not directly see their work, platform teams are often staffed with a company’s best engineers due to the high leverage and critical importance of their work.
Reduced Cognitive Load: A robust platform significantly reduces the cognitive load on experience teams, allowing them to focus their energy on customer or business problems rather than underlying technical complexities. In large tech companies, platform teams can constitute up to half of the product teams.

Experience Teams: Delivering Product Value to Users

Experience teams are responsible for how the product is directly experienced by users. This includes apps, user interfaces, and overall solutions.

Customer-Facing Experience Teams: Work on products used by external customers who buy or use the product.
Customer-Enabling Experience Teams: Work on tools and systems used by the company’s internal employees (e.g., customer service agents, in-store associates) who are vital for delivering the customer experience. If their system goes down, it directly impacts external customers.
End-to-End Responsibility: Experience teams are most empowered when they have as much end-to-end responsibility as possible for a user journey or product area. This provides a meaningful sense of ownership, greater autonomy, and a clearer line of sight to solving customer problems and achieving business results.
Leveraging Platforms: A rich platform enables experience teams to have this broader end-to-end scope by handling underlying technical complexities.

Design and Reporting Structure in Topology

The chapter also touches on how design and reporting structures fit into topology:

Design and Topology: Experience teams should include a dedicated product designer as a first-class member (alongside PM and tech lead). The “internal agency model” for design, where designers are a separate service team, is discouraged because it removes designers from “the room where it happens”—key decision-making, hindering collaboration and optimal user experience. Design managers ensure holistic design through standards and reviews, not by centralizing designers.
Reporting Structure and Topology: Engineering reporting structures are often organized by skill set (e.g., front-end engineers, mobile engineers). However, the team topology should not rigidly align with this. Dividing product teams purely by technical skill (e.g., a “web team” and an “iOS team”) makes it very difficult for any single team to own a multi-channel customer experience. Cagan cites Conway’s Law (“organizations… produce a design whose structure mirrors the organization’s structure”) as a caution against “shipping your org chart.” The key is that cross-functional teams’ membership should be determined by what is best for the product, not dictated by reporting lines.

Chapter 43: Empowering Platform Teams

This chapter delves into the specific strategies for empowering platform teams, acknowledging their unique role in enabling other product teams rather than directly serving end customers.

The Indirect Contribution of Platform Teams

Platform teams’ purpose is to enable experience teams to better solve problems for their customers. This makes their contribution indirect, and their empowerment strategy slightly different from experience teams.

Keep-the-Lights-On (KLO) Work: All product teams have KLO obligations (bug fixes, performance issues, compliance). Platform teams often have a higher proportion of KLO work due to their enabling nature, potentially consuming 10-50% of their capacity. This needs to be factored into their objectives.

Two Main Ways to Empower Platform Teams

Beyond KLO work, platform teams move their platform forward through two primary methods:

Shared Team Objectives: The most common approach. A platform team shares the same objective as one or more experience teams. This means the platform team is directly connected to the strategic context and business goal of the experience team they are supporting.
- Deep Collaboration: Sometimes, this requires intense, almost co-located collaboration (e.g., a platform team managing backend storage and an experience team managing content workflow might share an objective to enable video support in a CMS product). They work closely on both experience and implementation.
- Segmented Collaboration: Other times, the collaboration can be more segmented. The platform team defines an API (a contract) with the experience team, and then each team works largely independently, coming together for testing and delivery (e.g., a payments platform team providing an API for a checkout experience team to add a new payment type).
- Key: Regardless of depth, the platform team shares the strategic context and “why” of the work.
Platform-as-a-Product Objectives: For companies whose primary product is a platform (external platforms selling APIs to developers), the platform is treated as a true product, with objectives focused on customer growth, adoption, or monetization.
- Internal Platforms: An emerging trend is to manage internal platforms more like external products, focusing on their “developer experience” (DX) and user adoption by internal teams.
- Quality/Performance Objectives: Even for internal platforms, major quality, performance, or developer-experience issues can be elevated from KLO work to explicit team objectives.

In essence, by distinguishing KLO work and by leveraging shared or product-focused objectives, platform teams can achieve levels of empowerment comparable to experience teams, ensuring they are truly pushing the platform forward strategically.

Chapter 44: Empowering Experience Teams

This chapter elaborates on how to maximize empowerment for experience teams, emphasizing that providing them with end-to-end responsibility is key. This is best achieved through aligning teams with customer-centric patterns.

Alignment by Customer: Driving Ownership and Impact

Experience teams are most empowered when their scope of ownership naturally aligns with identifiable customer segments or journeys. This allows teams to directly impact business outcomes and feel greater autonomy.

Minimizing Translation: Aligning by customer means less translation is needed between business outcomes (e.g., “reduce churn for X customer type”) and the team’s product work.
Examples of Customer Alignment:
- By User Type/Persona: (e.g., “Riders Team,” “Drivers Team” in a ride-sharing app).
- By Market Segment: (e.g., “Electronics Team,” “Fashion Team” in e-commerce).
- By Customer Journey: (e.g., “Onboarding Team,” “Retention Team”).
- By Sales Channel: (e.g., “Self-Service Team,” “Direct Sales Team”).
- By Business KPI: (e.g., “New-User Growth Team,” “Conversion Team”).
- By Geography: (e.g., “North America Team,” “Asia Pacific Team”).

Specific Examples of Alignment for Different Product Types

Cagan provides common patterns that have proven effective:

Media Product (e.g., news sites, VOD): Experience teams can be organized by content section (e.g., “Sports,” “Local News”) or brand. Platform teams handle common capabilities (content management). This meets diverse customer needs and aligns with per-category business goals.
E-Commerce Product: Similar to media, alignment by category (e.g., “auto parts” vs. “jewelry”) if shopping experiences differ significantly. Built on a rich platform of common services (catalog, billing).
Enterprise Product: Often specialized by vertical market (e.g., manufacturing, financial services) or sales channel (self-service vs. direct sales requiring APIs for customization). Teams align to the most relevant segmentation.
Marketplace Product: Since different sides of the marketplace (e.g., buyers/sellers, drivers/riders) have distinct needs, experience teams are often organized by sides of the marketplace.
Customer-Enabling Product: Teams align with the end-to-end needs of different types of internal users (e.g., customer service agents, in-store workers) who support the external customer experience.

Cagan notes that a topology can mix different alignment dimensions where appropriate, rather than being strictly limited to one.

Design and Reporting Structure: Key Considerations

Topology and Design: Cagan strongly advocates against the “internal agency model” for product design, where designers are a centralized service team. This removes designers from key decision-making. Instead, product designers must be first-class, dedicated members of the cross-functional product team. Design managers ensure holistic design through standards, guidelines, and review sessions, not by centralizing designers away from the teams.
Topology and Reporting Structure: Cagan warns against rigidly aligning product teams with engineering reporting structures (e.g., “front-end team,” “mobile team”). This creates “feature teams” that struggle to own holistic customer experiences. He invokes Conway’s Law (“shipping your org chart”) to highlight that such structures inevitably lead to fragmented products. Cross-functional team membership should be determined by what’s best for the product, not by reporting lines.

Chapter 45: Topology and Proximity

Beyond team composition and scope, this chapter considers the critical practical factor of physical location (proximity) when designing team topology, especially in an era of remote work.

Trade-offs in Proximity for Distributed Teams

Even before the pandemic, talent shortages and high costs in tech hubs pushed companies towards remote offices or fully remote work. Cagan explores the trade-offs of various forms of proximity:

Proximity to Team Members:
- Co-located: All team members physically sit together. This offers significant advantages for product discovery due to intense, spontaneous collaboration, particularly for PMs, designers, and tech leads.
- Fully Distributed: Each team member works from home. While delivery can be effective, discovery is harder. The burden of increased communication falls on the tech lead to bridge the distance.
- Mixed: (e.g., PM/designer/tech lead co-located, engineers remote/different office). This is a common compromise.
Proximity to Customers: Being geographically near customers (e.g., a team building for India based in India) offers real advantages. However, tools exist for remote interaction, especially with in-country assistance for language/culture. This primarily impacts the product manager and product designer, requiring additional effort.
Proximity to Business Partners: If a product team needs close collaboration with internal business functions (e.g., operations, customer success), physical proximity can be beneficial. This can be mitigated by additional effort (travel, frequent calls) from the PM and designer.
Proximity to Managers: It’s generally easier for managers to coach and observe their direct reports when they are local. However, experienced managers can overcome this distance through increased outreach, frequent calls, and travel.
Proximity to Other Product Teams: When product teams have significant interdependencies, physical closeness facilitates collaboration. This can be overcome remotely through increased communication, travel, and techniques like “swarming” (intense, temporary co-location for a specific problem).
Proximity to Senior Executives: Some company cultures or executives prefer close proximity to product teams. For remote or distributed teams, the PM must make extra effort to build and maintain relationships with executives and stakeholders, often requiring managers to play a larger role.

Optimizing for the Product Team

As a general principle, Cagan advises optimizing for the product team itself. This often means prioritizing co-locating the PM, designer, and engineers together, even if it means they are remote from their managers, customers, or business partners. This is because the most critical collaboration happens within the cross-functional product team to tackle discovery. Managers must understand these trade-offs and mitigate disadvantages through intentional effort. For example, if the choice is between co-locating PMs/designers with customers or with engineers, Cagan typically recommends co-locating with engineers.

Chapter 46: Topology Evolution

This chapter discusses the dynamic nature of team topology, emphasizing that even the most empowering structure will need to evolve over time. It provides guidance on when and how to proactively adjust the topology and warning signs that indicate a need for change.

When and How to Evolve a Topology

Team topology often begins organically in startups (when engineering exceeds ~15 people) or reactively in larger companies adopting Agile. However, it’s a strategic decision that needs to be revisited, especially in response to significant changes:

Strategic Shifts: A major change in product vision, product architecture, or overall company strategy (e.g., expanding into a new market, sunsetting a product, a large re-platforming effort, or needing to expose core capabilities as an internal platform).
Resource Allocation: A product team needing to double its resources, or a new business objective requiring significant new investment.

When evolving the topology, the goal remains to optimize for empowerment by focusing on ownership, autonomy, and alignment.

Prioritize Team Stability: As much as possible, try to keep existing product teams intact. Significant investment has gone into building collaborative relationships, so it’s often better to assign an existing team a new set of responsibilities rather than breaking up teams and redistributing people.
Avoid Frequent Major Changes: Changing topology too frequently (more than once a year) is a warning sign of deeper organizational issues. It’s extremely disruptive, impacting daily work, relationships, and morale. Temporary team movements for urgent priorities should also be used carefully due to their disruptive nature.

Warning Signs for a Stagnant Topology

Even without a major strategic shift, leaders should actively look for “warning signs” that their current topology might be hindering empowerment:

Frequent Developer Shifting: Constantly moving engineers between teams signals a lack of clear ownership or stable priorities.
Frequent Dependency Conflicts: Managers constantly stepping in to resolve issues between teams indicates high coupling and low autonomy.
Developer Complaints of Dependencies: Teams report too many external dependencies to ship even simple things.
Limited Scope of Ownership: Teams feel their work is too small or insignificant, making it hard to feel ownership or impact.
Excessive Complexity: Developers dealing with too much complexity across too many areas, indicating high cognitive load for the team.

These signs indicate that the topology may be creating friction and working against empowerment. Proactive review and adjustment are necessary to ensure the organization remains effective and innovative.

Chapter 47: Leader Profile: Debby Meredith

This profile features Debby Meredith, an engineering leader with a distinguished career from HP to Netscape, and now a sought-after expert for transforming engineering organizations in startups. She gained renown for her ability to “significantly or urgently raise the bar” on engineering quality and delivery.

Debby’s Transformative Approach to Engineering Organizations

Debby’s method involves diagnosing the unique challenges of each company and then focusing on four fundamental areas to rebuild trust and drive effective execution:

The Example Starts at the Top: She first identifies and addresses issues stemming from senior leadership. Many startup founders or CEOs misunderstand technology’s role and their own impact on engineering. Debby educates them on the necessity of engineers as partners (to product management and product design) and makes them aware of their influence on the engineering organization’s challenges and successes. This top-down cultural shift is crucial for lasting change.
Focus and Strategy: Companies often struggle with overwhelming work backlogs and lack true focus. Debby insists that leaders make hard choices about what’s truly important, recognizing that “trying to do too many things at once will damage even the best engineering organizations.” Her arrival often serves as the catalyst for re-establishing clear strategic focus, which is essential for effective resource utilization.
Establish Trust: Trust is the “heart and soul” of a company. When engineering struggles to deliver, trust erodes between engineers and executives, leading to “bad behaviors and morale issues.” Debby works to re-establish and maintain this trust, recognizing that it requires consistent effort at every organizational level. She emphasizes that engineering’s unique value is continuous innovation with technology to deliver winning products.
Deliver on Promises: This is a critical component of rebuilding trust. Debby works with engineers to understand the importance of delivering on commitments. This involves two aspects:
- Rigor in Estimation: Replacing “unreliable estimation games” with a more rigorous approach. This often means embracing new methods, building feasibility prototypes (which uncover true costs during discovery), and practicing accurate prediction. The goal is to provide high-confidence dates when truly needed.
- Serious Commitment: Once a commitment is made, engineers must take it very seriously and follow through. This “do what you say you’re going to do” mentality is vital for engineering to become known for reliability.

Debby acknowledges that scaling engineering organizations is complex but asserts that successful transformation is achievable, leading to organizations that can “deliver with pride the products their companies and their customers depend on.”

Part VI: Product Strategy

Chapter 48: Focus

This chapter is dedicated to the critical element of focus within product strategy, arguing that most organizations fail to truly pick their battles, leading to wasted effort and diluted impact.

The Illusion of “Good at Focus”

Many company leaders believe they are good at focus, often because they’ve already said “no” to numerous ideas. However, Cagan frequently encounters organizations with 20-50 “critically important” objectives for a quarter or year. This is a literal “order of magnitude too many.” This stems from a fear of missing out, a desire to place many bets, and a need to respond to every competitor, lost deal, or customer request. This signals an “intervention” is needed to reset their understanding of true focus.

The Pandora Example: A Cautionary Tale of No Strategy

Cagan cites the Pandora music service as a clear case study of no product strategy and a complete absence of focus. Their “Pandora Prioritization Process” involved letting stakeholders “buy” features until their budget ran out—a classic example of “feature teams striving to serve the business.” This approach generated many features but led to minimal results or innovation, contributing to the company’s eventual decline. This is a common pattern: “stakeholder-driven roadmap processes” that prioritize “fairly” dividing engineering capacity rather than strategic impact.

The Power of True Focus

“Generating activity is not a problem; in fact it is easy.” As Stephen Bungay explains, the real challenge is “getting the right things done—the things that matter, the things that will have an impact.”
Lessons from HP’s Applied Research Lab: Cagan shares a personal anecdote from his early engineering career at HP. His mentor taught him that for performance optimization, while many areas could be improved, only a few “hot spots” (identified by performance analysis tools) would yield a perceptible impact for the user. Investing effort everywhere else was “wasted effort.” This illustrates that most work in unfocused organizations makes “absolutely no difference,” and critical priorities receive insufficient concentrated attention.
Work in Progress (WIP) Limits: This concept, common in Kanban, states that limiting the number of things a team (or organization) works on simultaneously increases throughput and reduces context switching. Having 20-50 “high-priority” initiatives simultaneously overwhelms organizations, making it impossible for any team to achieve significant results on their assigned objectives. Each high-priority effort incurs a real cost in management time and decisions.

Cagan concludes that an organization will accomplish more critical work by focusing on just a few items at a time, based on what truly matters. As Richard Rumelt states, “Good strategy works by focusing energy and resources on one, or a very few, pivotal objectives whose accomplishment will lead to a cascade of favorable outcomes.” If leaders cannot make these tough choices, the product strategy is doomed.

Chapter 49: Insights

This chapter explores the most difficult, yet crucial, aspect of product strategy: identifying and leveraging the insights that form its foundation. These are the “pivot points” that multiply the effectiveness of effort.

The Elusive Nature of Insights

Cagan dismisses the idea of a “paint-by-number playbook” for generating insights. He emphasizes that effective product strategy requires “real effort and thought.”

Preparation is Key: Epiphanies may happen in the shower, but only after “hours studying your data, your customers, the enabling technologies, and your industry.” Understanding the strategic context (company objectives, scorecard, product vision) is foundational homework.
Insights from Anywhere: Insights can arise from unexpected sources—an industry analysis, a salesperson’s comment, a new technology, a customer’s offhand remark, or an academic paper. The key is constant vigilance and an open mind to “connect the dots.”

Four Consistently Effective Sources of Insights

Strong product leaders continually contemplate these sources:

Quantitative Insights (Data Analysis): Major strategic insights often come from analyzing product data, particularly related to business model, acquisition funnels, customer retention, and sales execution.
- Testing Theories: Managers might have a theory (e.g., which customers respond best) and construct live-data tests to obtain specific data. Running these tests frequently (even daily) is crucial.
- Spotting Breakthroughs: The challenge is to recognize the truly important learnings among the vast amounts of data and leverage them into meaningful action.
Qualitative Insights (User Research): User researchers generate profound insights, even if not statistically significant.
- Evaluative Insights: Learning from testing new product ideas (did it work, and why/why not?).
- Generative Insights: Uncovering entirely new opportunities or unmet needs during customer interactions, even when focused on testing specific ideas. This can lead to “bigger opportunities than the ones we’re looking into at the moment.”
- Ignoring Learnings: Too many organizations fail to act on these qualitative insights, especially if their feature teams are already oversubscribed.
Technology Insights: New enabling technologies can solve long-standing problems in “just-now-possible” ways.
- Internal Exploration: Rather than outsourcing, the best organizations empower their own engineers to explore new technologies, often through prototypes, and bring possibilities to leaders.
- Continuous Change: Technology is constantly evolving, requiring leaders to identify technologies relevant to their product vision and empower teams to learn them.
Industry Insights: Learning from the broader industry, including competitors, major trends, and insights from similar markets globally.
- Industry Analysts: Following top analysts in your space.
- Management Consultancies (with caveats): While firms like McKinsey might offer insights, Cagan expresses “mixed feelings.” Their focus is usually on business strategy, not product strategy, and their engagement duration is often too short for deep understanding. Insights from third parties are also easily discounted.
- Long-Term Relationships: More helpful are small firms or individuals willing to engage long-term as trusted team members, or recruiting such consultants to join the product organization.

Shared Learnings: Disseminating Insights

Half the battle, especially in larger organizations, is getting the right insights to the right minds at the right time.

Beyond Documents: Simply writing down learnings (email, Slack, reports) is rarely effective.
Manager’s Role: Product and design leaders often “connect the dots” between learnings from different teams. They must take learnings from 1:1s (where teams share issues and discoveries) and proactively disseminate them to other relevant teams.
Head of Product’s Role: Cagan advocates for the Head of Product to aggregate key learnings and insights from all teams and share them in weekly/bi-weekly all-hands meetings. This ensures leaders truly “grok” the insights and broadly distributes knowledge, especially to other product teams where unanticipated impacts might occur.

Ultimately, product leaders must identify and leverage insights to achieve necessary impact. This process leads to identifying the “linchpins” for moving the needle on critical problems, preparing the organization to turn these insights into concrete actions.

Vision Pivots: When Insights Change Everything

Cagan notes that while the book lays out an ideal linear flow from vision to strategy to execution, reality is not always so clean.

The “Aha!” Moment: Sometimes, during product strategy work or team discovery, an insight emerges that fundamentally changes everything, leading the company (and often the board) to decide to pivot the product vision. Examples include Slack, YouTube, Facebook, and Netflix.
Stubborn vs. Flexible: Cagan cautions against abandoning vision too easily (“stubborn on vision”), but recognizes that a pivot is appropriate when insights reveal a larger or better opportunity, not merely when problems are harder than expected. This pivot signifies a strategic realignment based on profound new understanding.

Chapter 50: Actions

Continuing the series on product strategy, this chapter focuses on how to convert insights into actionable work for product teams. It highlights a critical fork in the road that distinguishes empowered organizations from those stuck in the feature team model.

The Fork in the Road: Features to Build vs. Problems to Solve

Even with a strong product strategy, companies face a choice in how they translate that strategy into daily work.

Feature Teams: Leaders who believe they know the necessary features to execute the strategy will put those on a product roadmap and assign them to teams. This is typical of the “feature factory” model.
Empowered Product Teams: Leaders who want teams to take ownership of results will provide them with problems to solve, giving them latitude to determine the best solutions. This is the model of “missionaries.”

Why “Problems to Solve” is Superior

The shift from assigning features to assigning problems is profound:

Optimal Solutions: The people closest to the problem (the product team) are best positioned to determine the most appropriate and effective solution.
Accountability for Outcomes: If a team is given a problem, they can be held accountable for achieving the desired outcome (e.g., reducing churn). If they are given a feature, and that feature fails to deliver results, accountability is diluted.
Increased Ownership: Teams feel much greater ownership when they are entrusted to find the solution.
Iterative Problem Solving: If the first solution doesn’t work, the empowered team knows it’s their responsibility to iterate or try alternative approaches until the problem is solved.

Team Objectives: The “What” and the “How We’ll Measure”

In the empowered model, actions are translated into team objectives, most popularly using the OKR (Objectives and Key Results) system.

Objective: The problem that needs to be solved (qualitative and aspirational).
Key Results: How success is measured (quantitative and outcome-based). Cagan stresses that these must not be activities or deliverables, as shipping output doesn’t guarantee solving the underlying problem. Typically, 2-4 key results per objective, including primary measures and “guardrail” or “backstop” key results to prevent unintended negative consequences (e.g., “reduce incorrect deliveries” while “ensuring total deliveries continue to grow”).
Team Ownership of Key Results: Crucially, the quantitative values for key results must come from the team. This fosters ownership. Leadership provides guidance on ambition, but the team defines what it believes it can achieve. A back-and-forth dialogue between leaders and teams is healthy and normal.
Strategic Context: Empowering teams means providing them with the necessary strategic context (product vision, product strategy) so they can make good decisions and understand the “why” behind their problems.

Cagan emphasizes that while OKRs are a popular and useful technique, the core requirement is simply for knowledgeable leaders to explicitly tell teams which problems to work on and how success will be measured, trusting them to figure out the solution. The OKR system merely formalizes this.

Chapter 51: Management

This chapter explains that even with a clear product strategy and well-defined team objectives, active management is still essential for success. Product strategy is not static; it constantly encounters challenges in the real world.

The Necessity of Active, Servant Leadership

Cagan states that if leaders stop after defining objectives, they will inevitably be disappointed. “No product strategy survives its initial encounter with the real world.” Numerous issues and obstacles will emerge, and while empowered teams handle most of these, they will frequently need management’s help.

Removing Obstacles: Managers are responsible for identifying, tracking, and resolving impediments that team members cannot handle on their own. Examples include:
- Dependencies: One team discovering a dependency on another team that is already consumed with its own objectives.
- Technology Access/Knowledge: A team needing to acquire or learn a new technology quickly.
- Customer Issues: Major customer problems requiring leadership intervention to balance customer care with objective progress.
- Stakeholder Concerns: Senior stakeholders raising significant concerns impacting key objectives, requiring quick decisions.
Information Flow: The primary source of information for the product leader is the weekly 1:1 with the product manager. Urgent issues should be raised immediately.
Coaching in Action: During 1:1s, the manager coaches the PM on how to handle issues, and sometimes directly intervenes by talking to stakeholders, finding resources, or coordinating with other teams.
Not Command-and-Control: This active management is not micromanagement. It’s servant leadership—responding to teams’ requests for help and removing impediments, not dictating solutions.
Weekly Tracking: Regular tracking of objectives (weekly check-ins) is crucial to ensure progress and to aggregate and disseminate learnings or identified issues across relevant teams.

Cagan reiterates his core message: with empowered product teams, “you don’t need less management, you need better management.” This ongoing, engaged leadership is vital for converting product strategy into tangible results.

Chapter 52: Leader Profile: Shan-Lyn Ma

This profile features Shan-Lyn Ma, founder and CEO of Zola (an online wedding registry and planning company), highlighting her journey from a fast-growing e-commerce company (Gilt Groupe) to founding her own successful startup. Ma’s leadership is defined by a deep commitment to building a company culture that values people, trust, and innovation.

Shan-Lyn’s Leadership Principles and Culture at Zola

Ma’s philosophy was shaped by a negative experience at a previous job where a leader criticized her for engineers liking her “too much,” advocating for a more pressure-driven approach. This reinforced her belief that innovation thrives in an empowered, trusted environment. At Zola, she and her co-founder, Nobu Nakaguchi, explicitly bet the company on this belief:

Valuing and Respecting People: They aimed to create an environment where people felt valued and respected, believing this would lead to the best customer experiences.
No Assholes, No Politics, No Games: Their kitchen has signs explicitly stating “NO ASSHOLES,” “NO POINTING FINGERS,” and “NO POLITICS, NO GAMES.” This reinforces a culture of trust and directness.
Diversity as an Explicit Goal: They made diversity (in skills, talents, gender, orientation, education, and problem-solving approach) an explicit hiring goal from the beginning for every open role. They believed this would drive innovation and better serve their diverse customer base (engaged couples).
Collaboration and Speed: They prioritize early collaboration, believing it yields faster and better results. They also emphasize getting ideas in front of customers as quickly as possible to facilitate real learning.
Personal Impact: Ma shares how a serious car accident reinforced her desire to “live life more in the present” and pursue what she loves. This deep personal motivation underscores her commitment to her work and the people she works with.

Ma’s story exemplifies how strong leadership, driven by deeply held values, can build a company that is both financially successful and a great place to work, fostering innovation through empowered teams.

Part VII: Team Objectives

Chapter 53: Empowerment

This chapter initiates the detailed discussion of team objectives, emphasizing their core purpose: to empower product teams by shifting from assigning features to assigning problems and providing necessary strategic context.

The Core Purpose: Problems to Solve, Not Features to Build

Team objectives (often framed as OKRs) are designed to empower teams by:

Assigning Problems: Giving teams problems to solve, rather than a pre-defined list of features or projects to build.
Providing Strategic Context: Ensuring teams understand the “why” behind the problem, enabling them to make informed decisions.

This is a stark contrast to traditional roadmaps. The critical lesson is that how work is assigned matters profoundly.

Why Problems are Better than Features:
- Optimal Solutions: Teams closest to the problem, with the necessary skills (PM, designer, engineers), are best equipped to determine the most appropriate solution.
- Accountability for Outcomes: When teams are given a problem, they take responsibility for achieving the desired outcome. If a pre-defined feature fails, accountability is diluted.
- Ownership: Empowering teams to solve problems fosters a much greater sense of ownership.
- Iteration: If an initial solution doesn’t work, empowered teams know they must iterate or try alternative approaches until the problem is truly solved.

Objectives: Defining the Problem

Qualitative & Aspirational: Objectives are qualitative statements of the problem to solve. They are aspirational, meaning they articulate a desired state without prescribing the solution.
Examples: “Reduce the frequency of parcels delivered to the wrong address,” “Increase the percentage of new customers that successfully create an account,” “Improve the site availability.”
Flexibility: Teams should have the flexibility to rephrase, change emphasis, or generalize objectives as they investigate and gain deeper understanding. This back-and-forth with leadership is healthy, signaling an engaged team.
Collaboration: Many objectives require collaboration with other product teams or different parts of the organization.

Key Results: Measuring Success (Outcomes, Not Output)

Defining Success: Key results tell us how we define success and must be measured by business results (outcomes), not activities or output. This is the second most common reason OKRs fail: teams listing deliverables as KRs. Shipping a deliverable doesn’t guarantee solving the underlying problem.
Quantity: Typically 2-4 key results per objective.
Primary & Guardrail KRs: The first is usually the primary measure. Subsequent KRs act as “guardrails” or “backstops” to ensure the primary KR isn’t achieved by inadvertently harming something else (e.g., reducing incorrect deliveries while ensuring total deliveries continue to grow).
Team-Owned Values: The quantitative values and timeframes for KRs must come from the team, fostering ownership. Leaders provide guidance on ambition levels, but the team commits to what they believe is achievable.
Avoid “Tail Wagging the Dog”: Teams should not define KRs by what’s easy to measure, but by what’s most meaningful for the business.
Strategic Context: Providing teams with product vision and product strategy (the “why”) is crucial context for making good decisions and understanding the problem’s importance. This encourages teams to contribute ideas and express interest in specific problems.

Chapter 54: Assignment

This chapter details the mechanics of assigning objectives to product teams, clarifying leadership’s role in this top-down/bottom-up process, and how “keep-the-lights-on” work fits in.

Assigning Objectives: A Combined Top-Down and Bottom-Up Process

Cagan explicitly states that leaders are responsible for deciding which problems should be worked on by which product teams. Companies that let teams entirely self-select objectives often struggle with lack of direction. The assignment process is iterative:

Top-Down Guidance: The product strategy dictates which problems need solving. The team topology (how teams are scoped) suggests which teams are best positioned to tackle each problem.
Team Input (Bottom-Up): While leaders make the final decision, they encourage teams to volunteer for objectives they are passionate about or optimistic about. Leaders try to accommodate these desires where possible, balancing team motivation with overall organizational objectives.
Holistic View: Managers must look holistically at all teams and objectives to ensure comprehensive coverage of the company’s goals. This is not about control, but about responsible management.

Determining Key Results: Team Ownership of the “What”

Once an objective is assigned, the team’s first task is to define the appropriate key results and what they believe they can accomplish.

Baseline & Learning: If it’s a new problem, teams may need time to collect baseline data and understand the dynamics. Leaders should encourage jumping in without “analysis paralysis,” acknowledging initial low confidence levels.
Guidance on Ambition: Leaders provide guidance on how ambitious (Chapter 55) the team should be (e.g., “very ambitious” vs. “conservative”).
Leader-Team Iteration: If a team’s proposed KRs are insufficient for the necessary business results (e.g., too low of an improvement on a critical KPI), leaders might ask them to focus on fewer objectives, or bring in another team to collaborate. The crucial point: if leaders want ownership, KRs must come from the team. The leader’s job is to ensure the team is engaged and debating.

Alignment: Ensuring Coordinated Effort

After objectives are assigned, leaders must ensure alignment across product teams and with other organizational functions (sales, marketing, etc.). If sales is targeting a different market than a new product team, that’s a sign of misalignment.

Keep-the-Lights-On (KLO) Work: The Constant Baseline

Team objectives are not the only work teams do. There’s always ongoing KLO work (bug fixes, customer issues, technical debt, support for other teams, compliance). Teams gain an understanding of this overhead over time. If KLO work spikes and impedes objective progress, leaders must address it (e.g., growing the team, reducing expectations for objectives, finding ways to reduce KLO burden).

Longer-Term Objectives: Breaking Down Multi-Quarter Goals

It’s common for significant objectives to span multiple quarters (e.g., a multi-year re-platforming effort, or achieving product/market fit).

Long-Term Objectives, Shorter-Term KRs: While the objective might be long-term, the key results for a given quarter should be intermediate product results—leading indicators of progress towards the larger goal.
Example: For a goal of 6 referenceable customers for product/market fit (which might take 2-3 quarters), the first quarter’s KR might be “get 8 prospective customers to sign a non-binding letter of intent to buy.” This is a strong, measurable leading indicator with business meaning.

Chapter 55: Ambition

This chapter focuses on a critical aspect of setting team objectives: clarifying the level of ambition expected from product teams in their discovery work. This is directly related to managing risk and communicating expectations.

Beyond Effort: Level of Ambition in Solutions

When leaders ask a team to solve a problem, they need to communicate how ambitious the team should be. This is distinct from work ethic or urgency, which are cultural. Different levels of ambition imply different types of product discovery work and techniques.

Portfolio of Bets: Leaders are essentially placing a series of bets on people, technologies, market conditions, and insights. Some bets are low-risk, some high-risk.
Ambition vs. High-Integrity Commitment: It’s important not to confuse the level of ambition with a high-integrity commitment (Chapter 56). An ambitious goal (moon shot) might not be a high-integrity commitment, meaning there’s no guarantee of success.
Risk Management: For critical problems (e.g., a high churn rate), experienced leaders will attack from multiple angles and risk levels. Some teams might pursue low-risk, quick wins, while others tackle more ambitious, higher-risk approaches.

Communicating Ambition: Roof Shots and Moon Shots

Roof Shot: A conservative approach, aiming for low-risk, highly likely, tangible results. Optimization work fits here.
Moon Shot: A very ambitious approach, striving for 10X improvements. This is high-risk but potentially high-reward, encouraging teams to think beyond incremental improvements and “break through” current limitations.
Confidence Levels: Some companies assign a degree of confidence to objectives (e.g., “70% confidence” of achieving a roof shot vs. “20% confidence” of achieving a moon shot).
Range of Bets: Leaders manage a portfolio of risk and reward, placing a range of bets based on circumstances, not just extreme “roof shots” or “moon shots.”
Clear Communication: It’s vital to clearly communicate the desired level of ambition to the teams and across the organization to prevent misunderstandings (e.g., someone assuming a high-risk moon shot is a high-confidence sure thing).

By clearly communicating the desired ambition, leaders empower teams to choose appropriate discovery techniques and manage expectations for potential outcomes.

Chapter 56: Commitments

While most team objectives are aspirational, this chapter addresses the crucial concept of high-integrity commitments—situations where a team must deliver something by a specific deadline with very high confidence.

The Necessity of High-Integrity Commitments

Cagan acknowledges that deadlines are a reality in business (e.g., for trade shows, partner contracts, tax seasons, marketing campaigns). One of the main reasons leaders revert to command-and-control with roadmaps is their need for predictable dates.

Empowered Teams’ Prerequisite: For the empowered team model to work, teams must be able to provide high-confidence dates and deliverables when necessary. These are not the “low-integrity dates” of the roadmap era (which were often guesses without proper discovery).
Prerequisites for a High-Confidence Date: A high-confidence date can only be provided after sufficient product discovery has been completed on the item (usually taking a few days) to understand its value, usability, feasibility, and viability. This often involves creating a feasibility prototype to ensure engineers understand the work scope.
Internal Dependencies: High-integrity commitments also apply to critical internal dependencies, such as a platform team providing a new service that an experience team needs to build upon.
Not All Work is a Commitment: KLO work and most minor dependencies are not high-integrity commitments. These are reserved for significant external or substantial internal commitments.

Tracking High-Integrity Commitments

Binary Outcome: High-integrity commitments are binary: the team either delivers what was promised or not. There’s no talk of “ambition” for these; they are expected to be met.
Early Warning: At the first sign of trouble, the team must raise the flag immediately and ask for help.
Explicit Tracking: These commitments are tracked explicitly, often with high-level visibility (e.g., the CTO might personally sign off on them due to reputational risk).
Trust Building: High-integrity commitments are a key way empowered product teams build trust with leadership.
Warning: These should be the exception, not the rule. If they become too frequent, objectives devolve into a list of deliverables and dates, reverting to a re-formatted roadmap, undermining empowerment.

Chapter 57: Collaboration

This chapter clarifies different forms of collaboration that are essential for empowered product teams, distinguishing between shared team objectives and common objectives.

Shared Team Objectives: Working Together on One Problem

This occurs when multiple teams share the exact same team objective. This is common for large company initiatives that require contributions from many product teams.

Example: Platform and Experience Team: A platform team might share an objective with an experience team when the platform needs to provide new services to enable the experience.
- Contract via API: Often, teams establish an API as a contract, work largely independently, and then collaborate on testing and delivery.
- Deep Collaboration: Sometimes, the collaboration is deeper, requiring teams to work very closely, almost as one (e.g., enabling video support in a CMS product requires intense collaboration between backend content storage and user-facing workflow teams).
Temporary Combination: Multiple teams might temporarily combine their talents to solve a particularly hard problem that benefits from diverse skills. This can involve an intense, temporary co-location called a “swarm” for focused discovery and/or delivery.

Common Objectives: Multiple Teams, Same Problem, Different Approaches

This form of collaboration occurs when multiple teams are asked to pursue the same problem, but each in their own way. This is a deliberate risk management strategy for especially difficult or critical problems.

Mitigating Risk: For hard problems where the optimal approach is uncertain (e.g., reducing subscriber churn), asking multiple teams to tackle it from different angles increases the likelihood that at least one approach will yield significant impact.
Independence: Teams usually tackle the problem based on their unique perspective, skills, and the code/technology they own. Approaches are generally largely independent and cumulative.
Communication & Coordination: Teams need to communicate to avoid conflicts, but otherwise, they pursue their separate approaches.
Product Attribution Problem: A challenge with common objectives is attributing progress to specific teams when multiple changes are happening simultaneously. Cagan mentions two common approaches:
- A/B Testing: Isolates a single team’s contribution. Requires sufficient traffic.
- Slicing: Dividing contributions by channel or source (e.g., mobile team owns applications from mobile notifications, search team owns applications from search results). Simpler but less rigorous.

Cagan emphasizes that having shared or common objectives is normal and often wise for solving the toughest problems, and organizations that avoid them in the name of autonomy may limit their innovation capacity. Teresa Torres’s “Opportunity Solution Trees” are noted as a helpful technique for exploring multiple approaches to a problem.

Chapter 58: Management

This chapter returns to the theme of active management required for team objectives. Once objectives are set, leaders and teams must continuously track and manage progress, practicing servant leadership.

Ongoing Management of Team Objectives

Keep-the-Lights-On (KLO) Work: Managers must monitor the ongoing KLO work to ensure it doesn’t spike and impede progress on strategic team objectives.
Weekly Tracking: Teams must actively manage their own progress, typically through weekly check-ins (either dedicated meetings or integrated into stand-ups). This mechanism allows teams to track progress, identify upcoming issues, and request help.
Staying on Track:
- PM Communication: Product managers must communicate any important issues to their manager immediately, not waiting for the 1:1, to enable timely assistance.
- Ongoing Coaching: Team members should receive continuous coaching related to the objective-specific issues they face. Managers of less experienced teams need to be more proactive in their questions.
- Early Warning for Commitments: If a team is facing issues with a high-integrity commitment, they must alert management as early as possible.
- Dependency Management: Teams must carefully manage and track dependencies on other product teams, ensuring their work is completed in time for those who depend on them.
Helping Our Colleagues: Empowered product teams optimize for themselves but also recognize the need to help colleagues on other teams. In tech companies, the mindset is “we either all succeed, or none of us succeed.” This means sometimes making decisions that are not in the best interest of one’s own team but are clearly in the best interest of the customer and the broader organization.

This active, continuous management, operating as servant leadership, is crucial for navigating the inherent urgencies and interruptions of company life and ensuring meaningful progress on product strategy. It’s not about command-and-control but about supporting and enabling teams.

Chapter 59: Accountability

This chapter addresses the critical companion to empowerment: accountability. It outlines what accountability means in practice, especially when teams fail to meet objectives, and how to attribute results in collaborative environments.

Accountability in Practice: Learning from Failure

Ambition and Accountability: Accountability is directly tied to the level of ambition. If a team fails on a very ambitious “moon shot,” it’s often expected and a sign of appropriate risk-taking. However, failing on a conservative “roof shot” or, critically, a high-integrity commitment, demands closer scrutiny.
Learning Opportunity: Failures provide excellent learning opportunities for both the product team and its managers.
Postmortems (Like Outages): If a team substantially fails on objectives, Cagan encourages treating it like a postmortem for an outage.
- Process: The product team meets with peers (especially those impacted by the failure) to discuss the root cause of the failure and what they “could—and should—have done differently.” This creates constructive learning.
- Managerial Accountability: Managers also need to self-reflect: Were signs missed? Could earlier coaching have been provided? Were the right questions asked?
- Embarrassment as Feedback: While “not fun,” the embarrassment of admitting failures to peers is part of the necessary feedback for growth.

Attribution of Key Results: Who Gets Credit for Success?

When multiple teams work on the same objective or share key results, attributing success can be complex. Cagan outlines two common approaches to the product attribution problem:

A/B Testing: This is the most rigorous method. It isolates the contribution of one team’s changes from all other concurrent activities across different teams or marketing programs. Requires sufficient traffic to yield dependable results.
Slicing: This involves dividing contributions to a key result by channel or source.
- Example: For “increase job applications” (a common objective for multiple teams), applications could be sliced by source: “mobile team: applications from mobile notifications,” “search team: applications from search results,” “recommendations team: applications from recommendations.”
- Pros/Cons: Slicing is conceptually simpler and gives teams a feeling of control over a narrower target. However, it’s less rigorous and predictive (e.g., the same user might interact with multiple channels). It’s also not always possible (e.g., for factors like subscriber churn).

Cagan concludes that it’s normal and often wise to have multiple teams pursue the same objectives simultaneously.

Chapter 60: Objectives in Perspective

This chapter provides a concise, 10-point summary of the most important aspects for effectively using team objectives (like OKRs) to manage and assign work, assuming an empowered product team model and capable leadership.

The 10 Keys to Effective Team Objectives

Empowerment via Problems: The most crucial point is to empower teams by assigning them problems to solve, not features to build, and providing them with the necessary strategic context (especially product strategy) to make good decisions.
Volunteering vs. Assignment: Leaders appreciate teams volunteering for objectives to leverage their motivation, but they must ultimately decide which teams work on what to ensure overall organizational coverage.
Leadership Assigns, Teams Define KRs: Product leadership assigns the objectives (the problems). Crucially, the key results (how success is measured) must come from the team.
Back-and-Forth on KRs: A negotiation happens between leaders and teams on KRs, judging investment against risk. Leaders might adjust assignments (e.g., fewer objectives, or collaboration with another team) if proposed KRs are insufficient.
Multiple Teams, Same Objective (Common Objectives): It’s often wise and effective to have multiple teams pursue the same problem from different perspectives, especially for difficult problems, acknowledging that not all will make the same level of progress.
Multiple Teams, Shared Objective (Collaboration): Teams can and often should collaborate on the same objective, especially when different skill sets are required (e.g., platform team and experience team).
Ambition Levels: Teams need clear guidance on the desired level of ambition for their KRs: “moon shot” (very ambitious, high risk), “roof shot” (conservative, high confidence), or “high-integrity commitment” (binary delivery expectation).
Accountability and Empowerment: Teams can only be accountable for results if they are empowered to figure out the solution and define their own key results.
Keep-the-Lights-On Work: Leaders must remember that objectives are not the only work. Every team has ongoing “keep-the-lights-on” activities (bug fixes, customer support, technical debt) that must be managed.
Quarterly Review (Flexibility): Objectives are typically created or updated quarterly, providing enough time for progress but allowing for business adjustments. Changes during the quarter should be exceptions.

Cagan concludes by emphasizing that the formal technique (like OKRs) is less important than the underlying conversation: knowledgeable leaders explaining the strategic context, defining the problem, and empowering teams to solve it effectively.

Chapter 61: Leader Profile: Christina Wodtke

This profile features Christina Wodtke, a prominent product and design leader, author, and Stanford faculty member. Her journey from art school photography to design leadership at Yahoo, LinkedIn, MySpace, and Zynga, and her eventual role as a teacher, highlights her deep commitment to coaching and empowering teams.

Christina’s Journey to Empowered Leadership

Wodtke attributes her leadership philosophy to pivotal mentors and experiences:

Irene Au (Yahoo!): Her first design manager, Irene Au (who also led design at Netscape and Google), mentored Christina into management, providing a role model of strength combined with kindness and empathy. Christina learned that “you don’t have to choose between empathy and authority.”
Jeff Weiner (Yahoo!, LinkedIn CEO): Jeff Weiner (then leading search at Yahoo!, later LinkedIn’s CEO) was instrumental in pushing Christina into a large-scale leadership role, managing 80 people across 9 managers. Despite her doubts, Weiner’s belief in her (“I know you can do this job”) made her believe in herself. This forced her to shift from designing products to “designing a place where good design could happen”—i.e., designing effective, self-managing teams.
- Shift to “We”: A pivotal moment was when she responded to a manager’s problem by asking what he thought they should do, then agreeing to his suggestion. This shifted the power dynamic from “me to we,” fostering a collaborative, team-based problem-solving approach. She has been “making teams out of groups of individuals ever since.”
- Trust and Scale: She realized that with such a large, diverse group, she couldn’t be an expert in everything. Success depended on trusting her team, the only way she could “sleep again.”
Ken Norton (Yahoo!, Google, Google Ventures): Ken, a product management leader, fundamentally changed Christina’s perception of product managers. Before meeting him, she viewed them as “project managers I had to chase away from my designers.” Ken demonstrated what real product management looks like, establishing that product and design should be equal partners, built on mutual respect. She emphasizes, “We are better together.”

Wodtke’s career exemplifies how leaders can pay it forward by investing in others, helping them reach their full potential. Her work at Stanford and her books (Radical Focus, The Team That Managed Itself) continue to advocate for strong, empowered product teams.

Part VIII: Case Study

Chapter 62: Company Backgrounder

This chapter sets the stage for the detailed case study, providing essential high-level context about the featured company: a typical two-sided jobs marketplace. This case study, though based on a real company, is anonymized and includes additional complexities for illustrative purposes.

Key Characteristics of the Company

Business Model: Connects employers (businesses needing to hire) with job seekers (individuals looking for employment).
- Employer Side: Sells job postings and premium services (featured jobs) to individual hiring managers at small-to-medium businesses. At the time of the case study, they were seeing interest from larger enterprises but their product wasn’t yet suitable for that market.
- Job Seeker Side: Focuses on professional (white-collar) job seekers actively looking for new employment.
Company Stage & Size:
- Age: Five years old.
- Revenue: Approximately $45MM annually, growing at ~30% per year.
- Financials: Close to profitability, but prioritizing growth.
- Headcount: ~230 people total, with a significant proportion in product/engineering (~95 people).
Executive Team: CEO, CFO, Head of Sales (CRO), Head of Marketing (CMO), Head of Product (CPO), and Head of Technology (CTO).
Applicability: The case study is chosen for its representativeness of a growth-stage company facing scale and tech debt challenges, with elements of enterprise business and early-stage startup dynamics, making it broadly applicable. The two-sided marketplace model allows for illustrating complex interactions.

The chapter emphasizes that while based on a real example, some complexities are layered in from later periods to provide a richer illustration of the concepts discussed in the book. The anonymity allows for candid discussion of both successes and challenges.

Chapter 63: Company Objectives

This chapter outlines the high-level annual company objectives set by the board of directors for the jobs marketplace company, providing the strategic framework for all subsequent product work. These objectives reflect the company’s overall business strategy and investment priorities.

Annual Focus Areas

Each year, the board, in collaboration with the executive team, determines the most important strategic objectives, considering the competitive landscape, potential investments (e.g., raising capital vs. focusing on profitability), and growth priorities.
For this particular year, the company’s board set two primary objectives:

Objective 1: Continue to Grow Core Business.
- Key Result 1: Grow core business revenue by at least 25%.
- Key Result 2: Reduce annual employer churn from 6% down to 5% or lower.
- Key Result 3: Increase seeker success rate from 23% to at least 27%.
- Context: This objective emphasizes continued growth and improvement of the existing employer and job seeker sides of the marketplace, ensuring they don’t “take the eye off the ball.”
Objective 2: Establish Company as a Proven Provider for Enterprise-Class Companies.
- Key Result 1: Demonstrate product/market fit by developing no fewer than six enterprise-class reference employers.
- Context: This represents a new, promising expansion opportunity. The board approved increased investment (additional product team, plus sales, marketing, customer success staff) for this initiative. This objective is considered an initial foray, with potential for larger investment in subsequent years if successful.

Cagan reiterates that these company objectives are outcomes (business results), not outputs (specific projects or features), and are measured by KPIs on the company scorecard.

Chapter 64: Product Vision and Principles

This chapter briefly notes the presence and importance of the company’s product vision and principles without revealing their specific content to maintain anonymity for the case study.

The Guiding Light: Vision and Values

The company possessed a strong and compelling product vision and a set of product principles.

Core Purpose: The company was founded on the mission of helping people find the best jobs and helping employers find strong candidates.
Demonstrated Values: Crucially, the company consistently prioritized its long-term benefits for customers over short-term company gains, demonstrating that its values and principles were more than just “empty words.”
Foundation for Decision-Making: The product vision, principles, and strategy were actively kept in mind by product management, engineering, and design leaders, and the product teams, as they pursued their team objectives. This strategic context was vital for decision-making and ensuring alignment throughout the organization.

Chapter 65: Team Topology

This chapter provides a detailed overview of the jobs marketplace company’s team topology at the beginning of the quarter. It describes how the 16 product teams are structured, aligning with the company’s two-sided marketplace and internal platform.

Organizational Structure and Resources

Total Product Teams: 16
Total Product/Engineering Staff: 95 individuals.
- 60 Engineers
- 12 Product Managers (note: 16 teams with 12 PMs means some PMs cover multiple smaller teams, or some teams are “PM-less” or covered by a Tech Lead)
- 10 Product Designers
- 2 User Researchers
- 3 Data Analysts
Product Leadership:
- 2 Directors of Product Management (one for employer, one for seeker), reporting to the CPO.
- 1 Director of User Experience Design, reporting to the CPO.
- 3 Directors of Engineering (one each for employer, seeker, and platform), reporting to the CTO.

Team Topology Overview: Aligning with the Business

The company’s topology is designed to align with its core business structure:

Employer Teams: Focus on the needs of hiring managers and HR departments.
Job Seekers Teams: Focus on helping individuals find jobs.
Platform Teams: Approximately one-third of resources are dedicated to an internal platform that supports both employer and seeker experience teams.

Detailed Team Descriptions

Employer Teams (5 Teams)
These teams serve hiring managers and HR, managing a freemium service for job postings and premium features.

Employer Home: Manages the employer dashboard, job posting functionality, and SEO for organic search visibility.
Recruiter Tools: Provides advanced capabilities for HR departments, including managing large job volumes, application flows, and proactive candidate outreach (searching the marketplace).
Premium Services: Manages optional services designed to help employers fill positions faster (e.g., featured jobs, email inclusions).
Employer Communications: Handles ongoing transactional (job status) and marketing (encouraging new postings) communications with employers via email, text, and notifications. Also responsible for online recruiting of new employer customers (SEO/SEM).
Enterprise Tools (New Team): A newly formed team focusing on enterprise-specific capabilities like integration with large Applicant Tracking Systems (ATS), aiming to identify and deliver what’s needed for this new market. This team embedded a full-time product marketing person due to the critical go-to-market work needed for reference customers and sales enablement.

Job Seeker Teams (6 Teams)
These teams focus on helping individuals find jobs.

Seeker Home/Personalization: Provides the core web and native mobile dashboard for job seekers, tracking jobs, application status, and recommendations.
Job Search: Manages the core search functionality allowing seekers to find jobs based on attributes.
Job Recommendations: Utilizes collected data and seeker profiles to generate personalized job recommendations.
Job Applications: Manages the process for seekers to apply for specific jobs, making it faster and easier after the first application.
Seeker Communications: Handles transactional (application status) and marketing (encouraging return visits) communications via email, text, and notifications. Also responsible for online recruiting of new job seekers (SEM/SEO).
Mobile Apps: Provides the native iOS and Android experience, working closely with the Seeker Home team to ensure comparable web and mobile experiences. (This team later evolved, with mobile development integrating into other seeker teams as native app development skills became more widespread.)

Platform Teams (5 Teams)
These teams exist to improve the efficiency and capabilities of the Employer and Job Seeker experience teams by providing reliable underlying services.

Shared Services: Consolidates duplicate efforts across teams, providing common services like authentication, preference management, and other utilities to increase productivity for experience teams.
Payments and Billing: Manages all financial transactions (recurring payments, discounts, methods), encapsulating significant complexity for other teams.
Data and Reporting: Provides reporting infrastructure for marketplace activity, feeding employer/seeker dashboards and enabling self-service reporting for other company functions (finance, marketing, sales, leadership).
Infrastructure: Responsible for the core technology infrastructure, leading major technical debt initiatives, and assisting product teams with scale and performance challenges.
Tools: Develops tools and services to increase productivity for all product teams (Employer, Job Seeker, Platform), including site monitoring, test-and-release automation (DevOps), and team collaboration tools.

The chapter notes that the company has 12 PMs for 16 teams, implying some PMs cover multiple smaller teams, or some teams (especially platform teams) are PM-less, covered by a Tech Lead as the primary product partner.

Chapter 66: Product Strategy

This chapter details how the jobs marketplace company’s product leaders (CPO, CTO, and their directors) translated the annual company objectives into a quarterly product strategy, ready to be executed by product teams. This process is iterative and adaptive.

The Strategic Process: Focus, Insights, Action, Management

The product leaders’ task is to define how to deliver on the company objectives, while acknowledging there’s no guarantee everything can be done. If not plausible, they would escalate to the CEO to adjust funding or expectations. The quarterly cycle allows for adjustments based on progress and new learnings.

Focus:
- The company’s senior leaders significantly aided focus by narrowing annual company objectives to just two key areas: growing the core business and exploring a new enterprise expansion.
- Specific opportunities (geographic expansion, new employer services) were explicitly not prioritized this year.
- Crucially, the new enterprise effort was not to come at the expense of the core business.
Insights: This is where the product leaders synthesize information to identify levers for impact.
- Growing Core Business Objective (Insights):
  - Problem: 25% growth is needed, but product optimization alone won’t get them there. They need to improve care for current customers and win new ones.
  - Employer Side (Key Insight): While employers want to fill jobs quickly with qualified candidates, user research and data analysis revealed a new problem: too many applications (over 25) for a job posting is as frustrating as too few (under 8). The sweet spot is 8-25 qualified applications. This leads to faster fills and happier hiring managers, directly impacting employer churn and seeker satisfaction (fewer disappointed job seekers). This insight becomes a strategic focus for employer teams to optimize application flow.
  - Job Seeker Side (Key Insight): Data showed that if a job seeker doesn’t submit at least one application within their first 48 hours, they are unlikely to return. Only 27% of registered seekers actually apply. This leads to a strategic focus for seeker teams to increase application submission in the first 48 hours, especially for registered users. They also noted mobile app users had higher success (32% vs. 15% for non-app users), indicating a potential lever.
- Enterprise Employer Objective (Insight): The new enterprise market is fundamentally different (e.g., selling to HR departments via a direct sales force). The key insight is to prioritize identifying product/market fit first and not get distracted by other efforts. This will require significant collaboration and support from many other teams (Employer, Job Seeker, Platform organizations).
- Re-platforming Objective (Product Leader Insight): This objective originates from product leaders, addressing substantial technical debt accumulated during rapid growth. The engineering organization had a 2-year plan to move to a modern AWS/microservices architecture. This quarter is the third quarter of that plan. The leaders decided on an incremental, strategic rebuild rather than pausing other work, which would be too risky for the business.
Action: The leaders then converted these insights into actionable work for product teams.
- Shared Strategy Briefing: Product leaders held a session with the entire product organization (including engineers) to update them on company objectives and the detailed product strategy and insights.
- Team Consideration: Teams were asked to consider the problems and identify how their unique skills/technologies could contribute.
- Top-Down/Bottom-Up Negotiation: Leaders would then approach each team with 1-2 important problems, but they also explained that if a team felt particularly optimistic about a problem, they would try to accommodate that desire. This iterative process maximizes organizational coverage of objectives while leveraging team motivation. The key results always come from the team.
Management (Anticipating Obstacles): The leaders knew that strategy wouldn’t play out perfectly. They anticipated and dealt with major obstacles through active management (servant leadership, not command-and-control):
- Workload Imbalance: One team (Employer Home) was overloaded. Solutions included reassigning work or adding engineers.
- Team Dependencies: Frequent issues arose where one team needed a capability from another (often a platform team) and needed to know if/when it could be delivered. Managers directly negotiated (“horse trading”) to accommodate or adjust timelines.
- External Dependencies: The Employer Home team needed significant SEO help from product marketing, leading to an SEO person being temporarily embedded in the team.
- Re-platforming Conflict: The Enterprise Tools team identified a conflict with the Infrastructure team’s re-platforming schedule. The Infrastructure team adjusted its module sequencing to ensure the ATS integration could happen on the new foundation, saving future re-implementation.
- Platform Prioritization: The Shared Services team faced a deluge of requests, necessitating clear priority guidance and, in some cases, allowing experience teams to write and contribute code to the platform (pending approval).

Chapter 67: Product Team Objectives

This chapter presents the finalized team objectives for each of the 16 product teams, showing the outcome of the negotiations between product leaders and teams, and among teams themselves. These objectives represent the specific problems each team is committed to solving for the quarter, supporting the broader company strategy.

Key Principles Reflected in the Objectives

Negotiated Outcomes: The objectives are the result of a back-and-forth between leaders (setting direction and overall coverage) and teams (proposing KRs and specific contributions), maximizing the likelihood of achieving annual company objectives.
Focus on Problems, Not Solutions: All objectives are qualitative problems to solve, not pre-defined features to build. Teams are empowered to discover the best solutions and validate them.
Strategic vs. KLO Work: These objectives cover the critical strategic work supporting company objectives, but teams still have other “keep-the-lights-on” work.
Common Objectives: Several teams share the same problem (objective) but tackle it from their own area, reflecting the product strategy’s emphasis on important, multi-faceted problems. This requires close communication and coordination.
Ambition Levels: The implied ambition for aspirational KRs is generally “relatively ambitious” (“moon shots” not “roof shots”), as leaders believed roof shots wouldn’t achieve needed results.

Company Dashboard: Key Performance Indicators (KPIs)

A subset of the company’s KPIs that are directly related to the product strategy:

Employers: Improve success rate for employers (% of jobs filled in 60 days)
- Current success: 37%
- Postings with <8 qualified applications: 39%
- Postings with >25 qualified applications: 7%
- Postings with 8-25 applications (sweet spot): 54%
- Avg. postings per account: 5.9
- Annual employer churn: 6%
Job Seekers: Improve success rate for seekers (% of seekers finding jobs in 60 days)
- Current success: 23% (avg)
- Registered seekers submitting ≥1 application in first 48 hrs: 27%
- Seeker success for app users: 32% (vs. 15% for non-app users)
- Avg. applications per job search: 3.2

Detailed Team Objectives (Selected Examples)

Employer Organization Objectives

Employer Home: Improve success rate for employers via recommendations (KR: increase employer success from 37% to 39%; increase 8-25 qualified apps from 54% to 58%). Focus on intelligent recommendations during job posting creation.
Recruiter Tools: (Shared with Enterprise Tools) Demonstrate product/market fit for enterprise. Will work alongside the new Enterprise team to adapt tools for enterprises.
Premium Services: Improve success rate for employers via premium services (KR: improve employer success for test cohort to 40%; listings revenue neutral/positive). Hypothesis: making certain premium features available to all employers will increase success and reduce churn, with tests to validate.
Employer Communications: Improve success rate for employers via communications (KR: improve success to 40%; increase 8-25 qualified apps to 56%). Leverage CRM best practices to improve recruiter/hiring manager interaction and loop closure.
Enterprise Tools (New Team): Lead on enterprise objective (KR: Get at least 8 customer discovery program customers to sign letter of intent to buy). Focus is solely on product/market fit via customer discovery with prospective enterprise clients, requiring support from other teams.

Job Seeker Organization Objectives

Seeker Home: (Shared with Job Recommendations) Improve success rate for seekers via recommendations (KR: increase seeker success to 25%; increase first application in 48 hrs to 30%). Focus on intelligent personalization of seeker dashboard.
Job Search: Improve success rate for seekers via search (KR: increase seeker success to 25%; increase applications from search results to 3%). Expand search to continuous scanning/notification of new matches.
Job Recommendations: (Shared with Seeker Home) Improve success rate for seekers via recommendations (KR: increase seeker success to 25%; increase applications from recommendations to 5%). Improve quality of recommendations, help seekers find jobs they don’t realize they’re qualified for.
Job Applications: Improve success rate for seekers via applications (KR: increase seeker success to 25%; increase avg applications submitted to 4). Make application process significantly faster and easier from any device after first application.
Seeker Communications: Improve success rate for seekers via communications (KR: increase seeker success to 25%; increase first app in 48 hrs to 30%). Focus on richer, timelier experience during the “first 48 hours” until first application.
Mobile Apps: Improve success rate for seekers via app (KR: increase app user success to 35%; increase % of first-time seekers installing app to 20%; increase app store rating to 3.5). Focus on real-time notifications for engagement during first 48 hours and ongoing.

Platform Organization Objectives
Platform teams primarily support employer/seeker teams; their objectives reflect this.

Shared Services: Provide technology necessary to support experience teams (High-Integrity Commitment: Deliver 1.0 version of notification system). Supports multiple teams needing notifications.
Payments and Billing: (Shared with Enterprise Tools) Demonstrate product/market fit for enterprise (KR: inherits Enterprise Tools KRs). Support for monthly billing accounts on corporate terms.
Data and Reporting: (Shared with Enterprise Tools) Demonstrate product/market fit for enterprise (KR: inherits Enterprise Tools KRs). Enable enterprise-wide reporting for companies with multiple users.
Infrastructure: Continue major tech debt re-platforming effort (High-Integrity Commitment: Complete migration of four more major system components to new architecture). Adjusted sequencing to support Enterprise Tools’ ATS integration, avoiding wasted work.
Tools: (Shared with Enterprise Tools) Demonstrate product/market fit for enterprise (KR: inherits Enterprise Tools KRs). Focus on real-time monitoring for enterprise integration needs.

Chapter 68: Business Results

This chapter provides a concise overview of the actual business results achieved by the jobs marketplace company in the quarter of the case study, and insights from about a year later. It demonstrates the payoff of the focused product strategy and empowered teams.

Tangible Outcomes of the Product Strategy

Employer Success Rate: The concerted effort to get more jobs into the “sweet spot” of 8-25 qualified applications paid off. The “successful posting” KPI increased from 37% to 41% by quarter-end, and continued to grow to nearly 45% by year-end.
- Impact on Churn: This directly resulted in a substantial decrease in employer churn, from 6% down to 5.1%.
- Key Contributor: The Job Recommendations team had the most significant impact, driving applications to more suitable jobs that seekers might not have found. This approach continued to improve for over two years.
Job Seeker Success Rate: The fundamental changes to the registration and first application workflow dramatically improved success.
- First Application in 48 Hours: This rate increased significantly from 27% to 42%.
- Mobile App Investment: The native mobile app proved valuable, leading to marketing efforts in subsequent quarters to encourage more installations.
Enterprise Product/Market Fit:
- Timeline: Achieving six reference customers took two full quarters (longer than the initial one-quarter expectation for a “letter of intent” proxy KR).
- Challenges: The company discovered that transitioning from online sales to direct sales for HR organizations required far more significant changes than anticipated, extending the necessary foundational work (security, access control, data/reporting, payment/billing) to nearly a year.
Re-platforming: This internal effort took the full two years as planned but was highly celebrated by the product teams. It resulted in a significant increase in the organization’s ability to move faster and align better with its efforts, proving the value of addressing technical debt.
Platform Team Evolution: Initially, some platform teams (Payments/Billing, Data/Reporting) found their tech leads overwhelmed by business complexities. This led to the addition of dedicated platform product managers to these teams later in the year, acknowledging the need for specialized PM roles in these areas.
Overall Satisfaction: Despite some teams having more success than others, employees, leaders, and investors were “more than satisfied” with the progress. The level of innovation was acknowledged and celebrated.
Increased Appreciation for Product: The open and transparent approach by product leaders led to several executives and stakeholders gaining a “much better appreciation for how technology products get made, especially the level of experimentation required to solve the particularly difficult problems.”

This case study vividly illustrates that implementing empowered teams and a strategic approach leads to tangible, celebrated business results, even amidst the complexities of rapid growth and tech debt.

Chapter 69: Key Takeaways

This chapter synthesizes the most important lessons gleaned from the detailed case study, offering a concise distillation of how a strong product organization operates in practice under real-world challenges.

The 10 Most Important Points from the Case Study

Critical Role of Product Leaders: Underscores the indispensable involvement of product leaders in every stage, from setting team topology and product strategy to actively managing daily issues and obstacles.
Importance of True Product Strategy: Highlights that results are only as good as the strategy. The case study shows a strategy based on focus (a few high-impact insights) that guided the entire organization, contrasting with unfocused, reactive approaches.
Active Management of Team Objectives: Emphasizes that without continuous tracking and management by both teams and leaders, progress on objectives can quickly derail due to daily urgencies.
Value of Empowered Teams and Missionaries: Reinforces that genuine innovation and significant results stem directly from empowering teams of missionaries who are excited to solve hard problems that truly matter to customers and the business.
Limitations of Knowledge and Planning for Uncertainty: Leaders recognized they couldn’t predict which ideas would succeed. They planned for this reality by placing a series of bets.
Risk Management Through Portfolio of Bets: Shows how leaders manage risk by placing bets with varying levels of confidence (based on data insights, team strength, and team confidence), knowing some will pay off and some won’t.
Impact of Team Topology on Action: Demonstrates that the chosen team structure (topology) directly influenced how insights were converted into action and significantly impacted the resulting outcomes. Different topologies would yield different results.
Necessary Give and Take (Top-Down/Bottom-Up): Illustrates the balance between leaders providing top-down strategic direction and teams contributing bottom-up ideas and defining key results. Leaders’ willingness to accommodate team desires fostered motivation.
Importance of Sharing Broader Strategic Context: Stresses that for product teams to make good decisions, they must understand the big picture—the product vision, product strategy, and the insights driving them.
Embracing Messy Uncertainty: Leaders found success by trusting their teams, accepting inherent uncertainty in product development, and appropriately managing the risks involved.

Cagan concludes by acknowledging that every company is unique, and while the case study’s specifics may not directly apply, its principles offer a valuable blueprint for leaders facing similar challenges.

Part IX: Business Collaboration

Chapter 71: The Role of Product Leaders

This chapter transitions to the crucial topic of business collaboration, asserting that strong product leaders and empowered product teams are necessary but not sufficient for success. Effective interaction with the broader company leadership is paramount.

Building Trust with Business Leaders

Moving from a “subservient feature team model” (where technology “serves the business”) to a “collaborative empowered product team model” (where teams serve customers in ways that work for the business) requires a significant shift in mindset. This transformation begins with establishing trust between the product organization and other business leaders.

Head of Product’s Central Role: A strong Head of Product (CPO) is essential for inspiring confidence and earning the trust of the CEO and other key executives. Without this, the transformation journey is difficult.
Peer-Level Product Leadership: A key assumption for collaboration is that product leaders are peers with other key executives (sales, marketing, finance, legal, business development). In older, pre-internet companies, product leaders might be buried under a CIO or CTO, which hinders peer-level trust and collaboration.
Deep Business Understanding: Product leaders must demonstrate a profound understanding of the business and a commitment to ensuring product solutions work for all aspects of the business. This is “table stakes.”

Three Judgement Criteria for Product Leaders

Beyond basic business understanding, product leaders will be judged on:

Business Results: Ultimately, the only thing that drives transformation is tangible business results. Product organizations must deliver outcomes that prove the empowered model’s effectiveness. This requires intentional product strategy and empowered, accountable teams.
Product Strategy: The company must have a clear product strategy. Product leaders must share this strategy with executives to explain the strategic focus and decision-making behind the work. Crediting executives who provided key insights can foster a culture of shared discovery.
Product Teams: Executives will observe and judge the product teams themselves, especially the product managers. Cagan states: “I like to tell product leaders that they are only as strong as their weakest product manager, and this is why.”
- Onboarding Importance: During new-employee onboarding, managers must ensure new product managers have done their homework on customers and the business before interacting with key executives.
- Personal Introduction: The product leader should personally introduce new PMs to key executives, thereby “vouching” for their knowledge and ability, putting their own reputation on the line.

Cagan warns against placing unprepared individuals in key product leadership roles, advising executive coaching from proven product leaders if necessary.

Chapter 72: Stakeholder Management vs. Collaboration

This chapter directly contrasts the traditional concept of “stakeholder management” with the preferred model of stakeholder collaboration within empowered product teams.

Shifting the Mindset: From “Client” to “Partner”

“Stakeholder Management” (Feature Teams): In the feature team model, technology exists to “serve the business.” Stakeholders are often seen as “the client” who dictate requirements. Product managers of feature teams typically “dread” dealing with stakeholders, feeling overwhelmed by demands and unable to satisfy everyone. Their role is to “manage” these demands.
“Stakeholder Collaboration” (Empowered Product Teams): In this model, the product team serves customers with products they love, yet work for the business. Stakeholders are partners who contribute critical knowledge to achieve solutions that are valuable, usable, feasible, and viable. Their primary contribution is often in ensuring viability (e.g., legal compliance, sales channel fit, financial implications).
- Example: Collaborating with a company lawyer to discuss legal constraints and potential solutions for a product idea. The PM doesn’t just receive a legal “no,” but partners to find a legal “yes” or an acceptable alternative.
- Shared Understanding: The PM, having done their homework, acts as an effective partner, working with stakeholders to understand constraints and discover solutions. This is a more constructive relationship conducive to innovation.

The “Agency Model” Parallel

Cagan draws a direct parallel between feature teams and external design or development agencies.

Similar Problems: Both operate on a “client-service” model where the client dictates, and the team implements. Agencies, like feature teams, often suffer from the same issues of lack of ownership and disempowerment, as their people literally are “mercenaries.”
Disempowerment: Agency personnel (and feature team members) are often capable of more, but they are forced to simply build what the “client” dictates, or risk losing the business.
Transformation Challenge: While some agencies are attempting to transition to an empowered model, it requires an unusually high level of trust from the client. When individuals from agencies join empowered product teams, they often bring the “client” mindset, which needs to be re-coached (e.g., “Now I get to be the client!” is a sign they’ve missed the point).

Chapter 73: Shared Insights and Learning

This chapter highlights the importance of open and generous sharing of insights and learnings between empowered product teams and their business colleagues. This collaborative knowledge exchange is crucial for fostering understanding and driving innovation.

Why Share Learnings Broadly?

Empowered product teams, through their constant product discovery activities (meeting users, analyzing data, investigating new technologies, tracking industry trends), generate insights very frequently. Sharing these learnings beyond the immediate team is vital for several reasons:

Broader Benefit: An insight learned by one team might help others across the business (e.g., in marketing, sales, customer success, other product teams).
New Perspectives: Business colleagues can offer additional insights by viewing the data through their specific lens or expertise.
Leveraging Dynamics: Others can help explain the dynamics of an insight or suggest how to better leverage it.
Understanding “Failing Fast”: It’s critical for the broader company to understand the difference between “failing” during discovery (which is fast, inexpensive learning from a prototype getting a bad response) and actual “failing” in the market (which is slow, expensive, and occurs when a launched product doesn’t work). Sharing discovery failures helps prevent market failures.
Journey Together: Sharing insights and learnings brings business partners “on the journey” of product development, fostering a collaborative, transparent relationship.
Building Trust & Credit: Inviting key business leaders to user testing sessions can be highly impactful. Generously sharing credit when an insight from a leader or executive proves critical reinforces their involvement and encourages future contributions. Cagan mentions creating “DEPUTY PRODUCT MANAGER” badges for such contributions.

The key is to ensure insights flow in both directions (from product to business and vice-versa) and are consistently acknowledged.

Chapter 74: Keeping the Lights On

While much of the book focuses on strategic innovation, this chapter acknowledges the reality that every product team must perform a certain amount of “keep-the-lights-on” (KLO) work—non-negotiable activities essential for running the business.

The Un-Glamorous but Essential Work

KLO work typically includes:

Critical Bug Fixes: Addressing urgent software defects.
Compliance Issues: Implementing changes required by new laws or regulations (e.g., privacy laws).
Minor Reporting Changes: Adjustments for changing business reporting needs (e.g., from finance).
Analytics Instrumentation: Adding code to collect usage data.
PM’s Role: The product manager is usually responsible for understanding these KLO items, gathering necessary data, and placing them on the backlog. Unlike strategic product work, KLO items generally don’t require extensive product discovery.
Business Partner Link: The source of many KLO items is often business partners (e.g., legal officer for compliance, finance for reporting). If product teams can’t handle these, business partners face difficulties, leading to tension.
Escalation: If KLO work becomes too high and impedes progress on strategic team objectives, it indicates a serious issue that needs to be escalated to product leadership for resolution (e.g., adding resources, adjusting expectations for objectives, finding ways to reduce the overhead).
Managing New Opportunities: Business leaders will frequently bring new opportunities (monetization, services) to product teams. A key part of collaboration here is to gently but firmly remind business partners about the product strategy and the importance of focus. While these new ideas might not be bad, pursuing too many simultaneously will dilute the ability to make a significant difference on the most important strategic objectives.
Avoiding “Pet Features” as KLO: Product leaders must be vigilant against business leaders attempting to sneak “pet features” into the backlog by mislabeling them as essential KLO work. If this happens too often, the organization reverts to feature teams driven by stakeholder whims, sacrificing strategic product work.

Chapter 75: Evangelism

This chapter highlights evangelism as a critical and ongoing role for strong product leaders, particularly in medium to large-sized companies. In this context, evangelism means internally marketing the product vision and strategy to the organization.

The Purpose of Internal Evangelism

The goal is not to sell a product, but to persuade internal stakeholders (product teams, executives, key stakeholders, investors, sales, marketing, customer service) that the product vision and strategy are important, and that they should care about it and contribute to making it a reality.

Top 10 Evangelism Techniques

Use Prototypes: PowerPoint presentations are often ineffective. Show a high-fidelity prototype (even if it’s “smoke and mirrors”) to make the product idea tangible and persuasive.
Share the Pain: Demonstrate the customer pain being addressed. Use quotes, video montages, or bring developers/executives to user testing to let them “hear the customer’s words and witness their pain themselves.”
Share the Vision: People need to know where you are heading (the 3-10 year product vision), not just what’s being done today.
Share the Learnings: Regularly share insights from product discovery (data, user research, technology, industry trends), including both successes and failures. This provides essential information and demonstrates the value of rapid learning.
Share Credit Generously: Ensure the product is viewed as everyone’s product. Give public credit to teams, executives, and stakeholders for successes. Conversely, take personal responsibility for misses and demonstrate learning from mistakes.
Give a Great Demo: For executives and stakeholders, a demo should be a “form of sales,” showing value rather than how to operate the product. Practice makes perfect.
Do Your Homework: Build credibility by being an expert on your users, customers, data, business, and market. People are more likely to follow knowledgeable leaders.
Be Genuinely Excited: Passion is contagious. If you’re not excited, either change what you work on or change your role.
Show Enthusiasm: Assuming genuine excitement, leaders must actively demonstrate it. Sincerity and enthusiasm are powerful motivators.
Spend Time with Product Teams: Face-to-face interaction (even virtual) with every PM, designer, and developer allows them to see the leader’s enthusiasm and builds motivation.

Evangelism can never truly stop. If it does, progress quickly goes “sideways” as executives lose confidence and teams lose motivation. Experienced leaders know to vary techniques and examples, but evangelism must be constant.

Chapter 76: Leader Profile: Avid Larizadeh Duggan

This profile features Avid Larizadeh Duggan, a distinguished leader from eBay, Google Ventures, and Kobalt Music, renowned for her contributions to technology (including an OBE award) and her work with Code.org. Her background spans engineering, product, venture capital, and leadership.

Avid’s Leadership Philosophy for Innovation

Avid’s leadership philosophy, particularly in innovation-driven contexts, centers on three interconnected components:

Trust and Safety: Leaders don’t need all the answers; their role is to ask the right questions and, crucially, create an environment where critical questions are surfaced. This requires psychological safety, where:
- No one is smarter than everyone else.
- Trust is established, fostering natural collaboration.
- Conflicting ideas are frequent and comfortable because candor is safe.
- People don’t fear failure, as it’s part of iteration towards great ideas.
- A growth mindset is celebrated, rejecting “know-it-alls.”
- By bringing out the best in teammates, you find the best in yourself.
Freedom and Autonomy: In a rapidly changing digital world, work is complex and informal. Leaders must dismantle traditional hierarchies that silo departments. Instead, they should:
- Bring strong people together and give them greater freedom to generate ideas and execute through cross-functional collaboration.
- Articulate what needs to be done and why, then let the team decide how to do it.
- Guide the team, clear obstacles, and clarify chaos.
- Ensure teams have the data to experiment quickly and the autonomy to make informed decisions.
- A leader’s role here is akin to a product manager: leading, influencing, motivating, and trusting without direct authority.
Culture and Purpose: Culture drives innovation and performance, and “the greatest capital of an organization is its people.”
- Autonomy and Meaning: People need both to innovate.
- Clear Purpose: Leaders must define and consistently communicate the company’s purpose (its “North Star”) to everyone, internally and externally.
- Consistent Reflection: This purpose must be reflected in every aspect of the company: hiring, processes, and even office design.

Innovation in Established Companies: A Radical Shift

Avid notes that applying these principles in established companies is far more challenging than in startups. Legacy companies often struggle with:

Legacy technology and complex processes.
Complacency born from long-standing market positions.
Overestimating their speed of innovation.
The survival of these companies depends on their senior leaders understanding the “true nature and urgency of the threat” and being willing to undergo the stress of radical change, even if it impacts short-term profitability.
Required Changes: This involves fundamental shifts in how teams work, technologies used, skill sets required, company culture, and leader mindset.
Trust is Foundation: Teams need to trust their leaders to embrace change without fear of repercussions for not getting it “right” the first time. This trust must be reciprocal, with leaders empowering autonomous teams who are on the frontlines of innovation.
Motivation by Purpose: Teams need to understand why they are undergoing upheaval and be motivated by something larger than themselves.
Acquisition vs. Organic Innovation: If an established company needs significant innovation, it has two options: acquire innovative companies or learn to innovate with its own people.
- Acquisition Challenge: Acquiring innovation often fails because if the parent company doesn’t transform its own leadership, culture, and empowerment, the acquired teams and innovative products decline.
- Organic Innovation: This requires the challenging transformation of skills, culture, methods, and leadership discussed throughout the book.

Avid dedicates her time to helping leaders realize their critical role in driving these necessary changes.

Part X: Inspired, Empowered, and Transformed

Chapter 77: Meaningful Transformation

This chapter synthesizes the book’s core message: how to achieve meaningful transformation from a traditional, feature-team model to an empowered product organization. It outlines the prerequisites and the three major, sequential steps.

Prerequisites for Transformation

The most fundamental prerequisite is getting senior leaders (starting with the CEO) to understand the necessary role of technology as the key enabler of the business, not merely a cost. Without this understanding, success is unlikely.

The Three Major Steps of Transformation (in Order)

Assuming senior leadership is on board and willing to act, transformation proceeds in three sequential steps:

Ensure Strong Product Leaders are in Place: This is the “first and most critical step.” Without strong product leaders, the organization cannot effectively:
- Recruit and coach the necessary product staff.
- Develop a solid product strategy.
- Earn the trust of other leaders and stakeholders.
Recruit and Develop the Necessary Staff for Empowered Product Teams: Once strong leaders are in place, they must build capable teams. This nearly always means raising the bar for product managers, but can extend to designers and engineers.
- Incremental Approach: Transformation doesn’t require upgrading all teams simultaneously. The key is to ensure that before a product team is empowered, it is staffed with people “up to the task.”
Redefine the Relationship with the Business: This is a crucial cultural shift.
- From Subservient to Collaborative: Move from a model where feature teams are subservient to stakeholders to one where empowered product teams are true partners with the business, collaborating to find solutions that customers love and work for the business.
- Leap of Faith: This requires business leaders to take a “pretty big leap of faith,” trusting product teams with greater autonomy. What’s in it for them is that the old way was ineffective.

Cagan acknowledges that for larger organizations, transformation impacts nearly every function (finance, HR, sales, marketing), but these specifics are beyond the scope of this particular book.

The Cost of Transformation: An Irony

Cagan highlights a significant irony: it generally costs significantly less to staff and fund empowered product teams than feature teams.

Waste in Feature Teams: He observes “more waste than I find in large companies that are running feature teams,” especially those outsourcing engineering to large firms. These “mercenary teams” are often staffed by thousands of outsourced engineers on multi-million dollar annual contracts.
Efficiency of Missionaries: A much smaller team of internal “true missionaries” typically dramatically outperforms a larger, more expensive outsourced approach.
Innovation Gap: Beyond cost savings, innovation “almost never happens in the outsourced model,” and a company’s future depends on innovation.
Higher Per-Person Cost, Lower Total Cost: While empowered teams might pay more per person for higher talent, the overall number of people and management overhead are substantially less.
Challenge to CFOs: Cagan directly challenges skeptical CFOs to run a test: compare the costs and business results of an empowered product team model against their current model in a specific business area.

Chapter 78: Transformation in Action

This chapter illustrates the concept of meaningful transformation through a powerful case study provided by SVPG partner Jon Moore, detailing his experience at The Guardian newspaper in London. It showcases how a traditional media company navigated a digital crisis and transformed into an innovative, tech-powered organization.

The Guardian’s Digital Crisis and Transformation

Context (2007): The global tech landscape shifted with the iPhone’s launch. The Guardian, a UK newspaper, faced a severe crisis: advertising in freefall, revenue streams disrupted by digital rivals.
Perilous Strategy: Unlike other newspapers moving to online subscriptions, The Guardian chose an ambitious and risky strategy: to remain free online (“Nothing good ever comes of putting up a wall”). This was driven by a belief that its progressive editorial content needed maximum reach, prioritizing “Reach first, revenue later,” even if it meant shortening its runway.
Influx of Tech Talent: Jon Moore joined as the Head of Mobile, part of a rapid influx of smart technologists (from Google, Microsoft, ambitious startups) into a traditional media company. This created “cultural chaos,” as long-serving journalists and editorial staff were uncertain of these new colleagues, their ways of working, and their motivations.

Leading Innovation and Bridging Divides (Jon Moore’s Role)

Immediate Mobile Strategy (iPhone): Moore spearheaded The Guardian’s first iPhone app (2007). His small, empowered team focused on leveraging the iPhone’s “revolutionary touchscreens,” prioritizing intuitive design and content availability even without signal (innovative for 2007). This application’s quality and the Guardian’s journalism led to hundreds of thousands of downloads and consistent showcasing by Apple in marketing campaigns. This demonstrated that the Guardian could produce “world-class product.”
Bridging Editorial and Technology: Moore recognized a growing divide. He undertook extensive evangelism (countless meetings, showcases) with senior editorial managers over many months. His message: his role would create “more eyeballs for your amazing content, and more eyeballs for us to monetize.” He aimed to build a world-class product to showcase world-class journalism, gaining trust by delivering early success.
The iPad Opportunity (2010): When Steve Jobs announced the iPad and invited The Guardian to replicate their iPhone success for its launch (with a 7-week deadline), it presented a “major problem” due to significant functionality and portability challenges.
- Feasibility Risk: The biggest risk was feasibility; achieving the same level of excellence was impossible in the timeline. Moore made a decisive choice: “quality sacrosanct, we needed another product—and fast.”
- Rapid Discovery & Thin Slicing: Moore leveraged prior insights from user data (photography content was popular) and decided to “thin slice” the scope. His small, empowered team (PM, designer, 3 engineers) rapidly moved from whiteboard to customer prototype in days. The new product, “Guardian Eyewitness,” focused on a single, curated daily photo with minimal details (story behind the photo, how it was shot), designed for the iPad’s screen.
- Building Partnerships: He befriended Roger Tooth’s photography team, who “incredibly patient and very willing” to collaborate.
- Innovative Prototyping: Without actual iPad hardware, they prototyped with cardboard and laptop screens, enabling incredible speed.
- Addressing Business Viability (Apology Later): Moore deliberately kept senior stakeholders out of early work, securing agreement from his technology director and editor Alan Rusbridger for speed, knowing he’d have to “seek apology later.” Once confident in the product, he presented it to the Group’s board, securing approval partly through Judy Gibbons’s endorsement and the compelling prototype.
Success and Impact: When Steve Jobs showcased “Guardian Eyewitness” as a “cool app” at the iPad launch, it generated millions of downloads. Its design made it perfect for showcasing the iPad’s screen, leading to extensive Apple marketing. The app proved that “quality photojournalism—combined with an innovative and immersive digital experience—resulted in millions of new Guardian consumers.”

Broader Transformation: More importantly, it demonstrated that The Guardian “could lead the world, not just editorially but digitally.” This pivotal success contributed to the Guardian becoming consistently revenue-positive, ensuring its strong global voice for future generations.

This case study is a testament to the power of empowered teams, clear vision, strategic risk-taking, and active evangelism in driving profound organizational transformation.

Chapter 79: TRANSFORMED

This chapter is an excerpt from Lea Hickman’s upcoming book, TRANSFORMED, which directly addresses the challenging topic of digital transformation. Hickman, an SVPG Partner, draws on her experience, including Adobe’s notable transformation, to explain why many efforts fail and what true transformation entails.

Why Most Transformations Fail

Hickman observes that many organizations attempt digital transformation but fail to achieve meaningful results because:

Narrow Focus: They focus too narrowly on how they develop products (e.g., adopting Agile methods) rather than broadly on how they produce and deliver value to customers.
Siloed Efforts: They often silo transformation into a “digital transformation group,” preventing company-wide change.
Executive Buy-in is Missing: The most critical lesson Hickman learned is that if the executive team is not fully on board with a “product operating model,” the chances of successful transformation are slim. Many executives may lack the understanding and language to engage effectively with a product organization.
Leader Behaviors: Certain executives have the skills and personality to drive the necessary change, while others don’t. Their behaviors can either make or break the transformation.

Product as the Value Driver

Hickman argues that for a company to “raise the bar for the product organization,” they need to think differently about product itself:

From Cost Center to Value Driver: Product should transition from being just a part of the technology organization (or IT) or a “necessary expense” to becoming the primary value driver of the organization. It’s not about power structure, but about product driving value, not just being a “feature factory.”
Executive Engagement: The executive team needs to understand the product operating model and possess the language to engage meaningfully with the product organization.

SVPG’s Real-World Approach

Hickman emphasizes that SVPG’s advice is not academic theory but based on decades of real-world experience, including successes and failures as individual contributors and senior leaders who have undergone major transformations.

Honest Feedback: She notes that Marty Cagan taught her early in her career to be “honest and tell you what I believe you need to hear,” even if it’s “hard-to-hear feedback” that was foundational for Adobe’s transformation.

TRANSFORMED aims to help readers navigate the pitfalls of transformation, focusing on the fundamental changes to skills, culture, methods, and leadership necessary to move to a true product culture.

Chapter 80: The Most Important Thing

This chapter serves as a powerful capstone to the book, asserting that if there is one core concept to embrace for building an empowered organization, it is the empowered engineer. It reiterates Bill Campbell’s belief that “Empowered engineers are the single most important thing that you can have in a company.”

The Empowered Engineer: The Heart of Innovation

While extraordinary products come from product teams, Cagan argues that the empowered engineer is the “single most important ingredient.”

Source of Innovation: Engineers are the “best single source for innovation” because they work with enabling technology daily and are uniquely positioned to see “what’s just now possible.”
Strategic Alignment:
- The product vision attracts and inspires them.
- The product strategy ensures they work on the most important problems.
- Team objectives give them clear problems to solve and outcomes to strive for.
Collaboration: Product managers and designers provide crucial constraints on business viability and customer experience. User research and data science provide key insights.
Beyond Just Coding: “Just letting your engineers decide how to code a solution is not what is meant by empowerment.” Nor is it just letting them determine the architecture. Empowerment means providing engineers with the problem and strategic context, then trusting them to leverage technology to figure out the best solution to that problem.
Litmus Test: If engineers first see a product idea at sprint planning, it’s a clear sign of a feature team and disempowered engineers. “If you’re just using your engineers to code, you’re only getting about half their value.”
Core Competency: A strong tech-powered product company would no sooner outsource engineers than outsource its CEO. They are “absolutely core.”
Valued Role: The best tech companies have dual-track career ladders, with top engineers compensated at VP levels, recognizing their immense value.
Missionaries vs. Mercenaries: Engineers are the clearest indicator of whether a company has missionaries or mercenaries.

Addressing Common Objections

Cagan frequently hears the objection: “My engineers are not interested in anything but coding.” He debunks this:

PM Misconception: Most often, it’s an “overzealous product manager” (thinking like a project manager) who doesn’t want engineers involved in discovery, either hearing what she wants or not caring to ask.
Lack of Exposure: If engineers truly express disinterest in discovery, it’s often because they’ve “never” or “very long ago” personally visited a customer, meaning they haven’t been exposed to the underlying problems.
Leadership Failure: If no engineers on a team desire to do discovery, it’s a failure of the head of engineering to raise the bar on hiring. Each product team needs at least one true tech lead whose big responsibility is discovery.

Cagan concludes that if a product leader does nothing else, empowering engineers will significantly advance their use of technology, their path to empowered product teams, and their chance at continuous innovation.

Chapter 81: The Destination

This concluding chapter paints a vivid picture of the transformed state of a company that has successfully adopted the principles outlined throughout EMPOWERED. It serves as a vision for what leaders can achieve.

The Transformed Organization: A New Reality

Cagan revisits the common problems described at the book’s outset, contrasting them with the ideal state of a truly transformed company:

The Role of Technology: Technology is understood as the critical and essential enabler of the business, not just an operational cost. New technologies are immediately explored for their potential to reimagine existing business aspects and solve customer problems in new ways. Product managers, designers, engineers, and data scientists are seen as “absolutely core.”
Coaching: The company has a deeply embedded culture of coaching. Every product team member has a manager committed to their potential, building a reputation as a place where competent people of character can become extraordinary.
Staffing: Hiring managers take personal responsibility for recruiting, interviewing, hiring, and onboarding. Strong staffing has become a core competency.
Product Vision: The company has an inspiring and compelling product vision that unites all product teams in a common, meaningful purpose. Consistent progress is made quarter by quarter toward this 3-10 year vision.
Team Topology: The team structure is optimized for empowerment and autonomy. Teams feel true ownership of a meaningful piece of the product and know how to collaborate with other teams on larger problems.
Product Strategy: The company executes on a focused product strategy, powered by insights from data and ongoing customer interactions, identifying the most impactful problems for teams to solve.
Team Objectives: These impactful problems are assigned to specific product teams as team objectives. Teams then use product discovery to figure out solutions and product delivery to bring them to market.
Relationship to Business: The relationship between product teams and business leaders/stakeholders is characterized by mutual respect and true collaboration. Teams work closely with stakeholders to find solutions that customers love and work for the business, and this is understood and embraced by all.
Empowered Teams: This is the most crucial outcome. Product teams are truly empowered to devise the best solutions to their assigned problems and are accountable for the results. Engineers are constantly seeking new technological applications, designers ensure excellent user experiences, and product managers own value and viability. Teams are inspired, proud, and define success by their consistent contributions to customers and the company.

Final Thoughts

Cagan concludes with a hopeful message for product leaders:

Raising Your Game: He hopes the book serves as a resource for leaders who never received serious coaching, helping them elevate their capabilities and, consequently, their people.
Next Generation of Leaders: He particularly hopes future leaders understand what’s required to lead the people and companies they “deserve.”
Talent for Good: A final wish that readers will use their talents and energies “for good.”

This transformed state, while still challenging due to competition, equips a company to not just “fight back, but to grow and thrive by continuously innovating on behalf of your customers.”