Empowered

Behind Every Great Company

Amazon, Google, Apple, and Netflix do not succeed because of some distinctive "product culture." Their actual cultures differ quite a lot. What they share is a deeper alignment: leadership's job is to create an environment where, as Silicon Valley coach Bill Campbell put it, "the greatness in everyone can emerge."

Three commitments, not one style

• Technology as the business, not a cost. Most companies treat technology as overhead to minimize or outsource. Strong product companies treat it as the product itself, which changes how teams get funded, staffed, and trusted.
• Real product leadership. Weak organizations have product leaders who mostly triage a backlog and referee stakeholders. Strong organizations have leaders who staff, coach, and set a real strategy.
• Empowered over feature teams. This is the sharpest distinction. Feature teams implement a pre-decided list of features; they are cross-functional but still order-takers. Empowered teams get a problem and are judged on whether it got solved, owning whether a solution is valuable, usable, feasible, and viable, not just whether it shipped.

Adopting Agile ceremonies is not the same as transformation; plenty of companies run every ceremony correctly and remain a feature factory underneath. Customers and stakeholders cannot specify the right solution themselves, because they do not know what is technologically possible and nobody can reliably predict in advance what will work. That uncertainty is exactly why product discovery, not a stakeholder wish list, is how solutions actually get found.

The test for your own team is concrete: pull up the current roadmap and check whether each line is a solution someone else specified, or a problem your team is accountable for solving. If it is the former, no amount of "empowerment" language changes what is actually happening.

The Role of Technology

The taproot of the whole gap between top tech companies and everyone else is one belief: how a company answers "what is technology to us?"

The CIO/CTO tell

Even a decade after Marc Andreessen's warning that "software is eating the world," many companies still treat technology as a cost to minimize, sometimes with catastrophic results (Cagan points to Boeing's 737 MAX crisis as an extreme case of outsourced, under-invested engineering). Tesla and Pixar show the alternative: when technology is core to the product, you get continuous reinvention (Tesla's over-the-air updates) or entirely new creative capability (Pixar's animation pipeline).

The organizational chart usually gives the game away. If engineers building customer-facing product report into a Chief Information Officer, an internal-systems role built around cost control and reliability, that reporting line quietly signals "technology serves the business" instead of "technology is the business." Strong product engineers tend to avoid CIO-led orgs for exactly this reason. The blunt fix: either let a CIO grow into a true CTO role, or hire a CTO who leads product engineering directly.

Money spent on outsourced "mercenary" engineering to save cost often returns far less than a smaller, empowered internal team focused on outcomes. If your organization measures engineering primarily on cost per feature rather than problems solved, that is this diagnosis in miniature.

Strong Product Leadership

Leadership (setting direction, inspiring people) and management (staffing, running the day to day) are different jobs. Empowered teams need more of both, not less oversight replaced by hands-off delegation.

What leaders own

• Product vision and principles: a compelling 3 to 10 year picture of how the product changes customers' lives, paired with principles that let teams make trade-offs (user experience over short-term revenue, say) without asking permission every time.
• Team topology: how people are organized into teams, what each team owns, and how teams depend on each other.
• Product strategy: the plan for reaching the vision, built from focus, insights, action, and ongoing management.
• Evangelism: continuously re-selling the vision and strategy across the company, aiming, in John Doerr's phrase, for "missionaries, not mercenaries."

What managers own

First-line managers (directors, engineering managers) carry three responsibilities that determine whether any of the leadership work above actually lands: staffing (sourcing through performance management), coaching (the highest-leverage and most neglected of the three), and team objectives (translating strategy into problems the team is trusted to solve).

Coaching skill is not optional context for a manager role, it is one of exactly three things a manager is there to do, alongside hiring and objective-setting, and neglecting it quietly caps how empowered any team under that manager can become.

Empowered Product Teams

The real obstacle to spreading the empowered-team model is not a skills gap, it is a trust gap. Leaders often assume their current staff is not strong enough to be handed a problem instead of a feature, and that only "10x" hires at elite companies can operate that way.

People who struggle in feature-factory environments regularly thrive once they move to a company that actually empowers them. Top companies do not necessarily hire a higher percentage of exceptional people; they are simply better at creating the conditions, coaching, context, and trust, that let ordinary people reach extraordinary results together. The book's title is this idea compressed into two words.

If you have ever concluded a team "is not ready" for more ownership, the honest question is whether the real constraint is trust and structure rather than talent, since those are the two things leadership directly controls.

Leadership in Action

A recurring device runs through the rest of the book: profiles of real product leaders, the first, Lisa Kavanaugh, at the close of Part II. The same way INSPIRED profiled individual product managers to make abstract advice concrete, these profiles show what strong product leadership looks like in practice, in leaders' own words, not just as principles on a page.

Treat the profiles as primary evidence, not decoration. They exist specifically to show the range of paths into strong leadership, and the common threads underneath very different styles and companies.

A Guide to EMPOWERED

This book is written for product leaders and aspiring leaders (managers, directors, VPs, CPOs, CTOs), not individual contributors, though the ideas matter to product managers, designers, and engineers who want to understand what their leaders should be doing. Cagan and Jones write in first person deliberately, aiming for a coaching tone rather than a textbook one.

The road ahead: Coaching, Staffing, Product Vision and Principles, Team Topology, Product Strategy, Team Objectives, a full Case Study, Business Collaboration, and finally Inspired, Empowered, and Transformed, which ties the whole model into an organizational transformation.

Transformation, throughout, means genuinely hard, multi-year work, not a reorg announced on a Monday. Anyone expecting a quick checklist has misread the promise from here onward.

The Coaching Mindset

Bill Campbell's line sets the bar: "Coaching is no longer a specialty; you cannot be a good manager without being a good coach." Good coaching tools are wasted without the right intent behind them first.

What the mindset actually requires

• Developing people is job number one. A manager's own performance should be measured by their reports' success, not their own output.
• Empowering people produces the best results. Create the space for the team to own outcomes, then step back, stepping in only to remove impediments or add context.
• Watch your own insecurities. Managers who micromanage or hoard visibility are usually protecting their own sense of contribution, treating team success as a threat instead of the point.
• Cultivate diverse points of view. Hire for different strengths and backgrounds, then actually welcome the dissent that comes with it.
• Seek teaching moments. Right-sized discomfort is how people discover real capability.
• Keep earning trust. Praise and criticize honestly, criticism always in private, and be willing to show some of your own struggles.
• Have the courage to correct mistakes. When someone genuinely is not working out despite real effort, waiting hurts them, the team, and you. When you know, do not wait.

Not every manager has the domain expertise to coach a specific discipline (a business-development GM leading a cross-functional team, say). When that is true, someone else with the expertise still has to be explicitly assigned the coaching job. Someone always owns each person's development; the mindset above just describes what that job actually looks like day to day.

The Assessment

A coaching plan is only as good as the gap analysis underneath it. Product people get assessed across three pillars, mirrored from INSPIRED's own taxonomy: product knowledge (user and customer knowledge, data fluency, industry and business knowledge, operational fluency with the product itself), process skills (discovery, optimization, delivery, and the team's development process), and people skills (team collaboration, stakeholder collaboration, evangelism, leadership).

For each skill, a manager scores two numbers: where the person should be for their level (the expectations rating) and where they actually are (the capability rating). The gap between the two, not the raw score, is what the coaching plan targets, focused on the two or three biggest gaps rather than everything at once.

Self-assessment is worth inviting, but the manager still owns confronting any gap between how someone rates themselves and how the manager actually sees it. This is deliberately separate from an annual performance review, which mostly serves HR compliance; the gap analysis exists purely to drive development, and a track record of closing gaps becomes the evidence for the next promotion conversation.

The PM-relevant habit to take from this chapter: do not wait for a review cycle to name a specific gap. If you cannot state, right now, the two biggest skill gaps for each person on your team, you do not yet have a coaching plan, you have good intentions.

The Coaching Plan

This book, in effect, is the long-form version of a coaching plan; every later chapter fills in a specific gap from Chapter 8's taxonomy. A few techniques recur across every category worth calling out on their own.

For product knowledge, immersion beats reading: pushing a new PM through fifteen real customer visits in their first months teaches more than any onboarding deck, and a business model canvas is a fast way to expose which parts of "the business" (sales, finance, legal, partnerships) a PM does not yet understand.

For process skills, a Certified Scrum Product Owner course covers the administrative slice of the job but is not a substitute for real discovery training; testing whether a PM understands the four product risks (value, usability, feasibility, viability) is a better signal than any certificate.

For people skills, the written narrative (Chapter 11) is the single best forcing function for evangelism and leadership skills, because it is the one tool that exposes shallow thinking before it reaches an audience.

Tech leads and designers get their own coaching angle: a tech lead's value multiplies once they combine deep technical knowledge with real customer exposure, so sending them on customer visits pays off disproportionately; designers need breadth across service, interaction, visual, and research disciplines, which is usually a design manager's job to fill, not the PM's.

The throughline for a manager: coaching plans fail when they stay abstract, "get better at stakeholder skills." They work when they are this concrete, tied to a specific technique, a specific number of customer visits, a specific document to draft, and a specific person to review it.

The One-on-One

A weekly 1:1 is not a status meeting, it is development time, and treating it as the former is the single most common way managers waste their highest-leverage tool. Thirty minutes minimum, once a week, non-negotiable enough to reschedule rather than cancel. New hires need it far more often, sometimes daily, until they have reached basic competence.

What a real 1:1 actually covers

• Strategic context (mission, company objectives, product vision and strategy, team objectives), because a team cannot make good autonomous calls without it.
• Homework the manager points to but does not do for them: customer, data, business, technology, and industry depth.
• How the person is thinking, not just what they are doing: are they reasoning about all four product risks, connecting dots across teams, showing real persistence on hard problems.
• Feedback, frequent and specific enough that nothing in an annual review is ever a surprise.

Why 1:1s fail

In practice, the manager does not actually care and lets development slide; the manager reverts to micromanaging instead of coaching; the manager talks the whole time instead of listening; the manager avoids hard feedback out of conflict-aversion.

Or the manager is insecure or simply not skilled enough to coach, in which case that manager's own manager needs to step in; or the manager will not cut losses on someone who genuinely is not suited to the role, which quietly punishes the rest of the team.

A useful measure of your own success as a manager: how many people you have coached into a promotion or a bigger role, not how smooth your own meetings run.

The Written Narrative

The "six-pager," Amazon's own term for it, is a roughly six-page prose document arguing a specific recommendation: the problem, why the solution matters to customers and the business, the strategy for getting there, and an FAQ section anticipating every objection a skeptical executive would raise. It is deliberately not a slide deck and not a spec.

Why it works better than a pitch

A narrative cannot fake depth. A slide can gesture at an idea with a bullet point; a paragraph has to actually explain it, which means gaps in thinking show up on the page before they show up in a meeting. Writing the FAQ section forces you to sit with objections in advance instead of getting blindsided by them live, which is what actually builds credibility with a skeptical room, not confident delivery.

Meetings that open with everyone reading the narrative in silence run faster and better than meetings that open with a pitch, because everyone arrives at the same level of context instead of a decision getting made by whoever is most persuasive live.

Coaching someone through their first narrative is genuinely uncomfortable, because it exposes exactly how much homework they have not done yet. That discomfort is the point, not a reason to skip it. If you want a fast read on how deeply your team actually understands a problem, ask them to write the six-pager before the meeting, not to prepare slides for it.

Strategic Context

Empowered teams can only make good autonomous calls if they are actually holding the same context leadership is. Six things make up that context, and onboarding is where they should first get transmitted:

• Company mission: the durable, decades-long reason the company exists.
• Company scorecard: the small set of KPIs leadership actually watches to judge overall health.
• Company objectives: this year's specific, outcome-oriented goals, not a list of projects.
• Product vision and principles: the 3 to 10 year picture of the future, plus the values that resolve trade-offs day to day.
• Team topology: how teams are carved up and how yours fits into the larger structure.
• Product strategy: how the vision translates into the specific problems each team is on the hook for.

A product manager who cannot restate all six for their own team, from memory, does not have the context needed to make a defensible independent call, no matter how skilled they are individually. That is the practical test worth applying before assuming a team is ready for more autonomy: gap in context, not gap in talent, is very often the real blocker.

Sense of Ownership

Thinking like an owner, not an employee, is a specific, teachable habit, not a personality trait some people happen to have. Jeff Bezos's shareholder letters describe it as taking responsibility for the outcome itself, not just the activity that was supposed to produce it.

What owner-thinking looks like in practice

• Feeling real obligation to customers, the team, and the business, not just to your own task list.
• Doing the homework (customers, data, business, industry) before claiming a position.
• Committing to get over, around, or through obstacles rather than stopping at the first blocker.
• Measuring yourself by results, never by effort or activity.
• Taking blame for misses and giving credit for wins, in that order.
• Influencing without direct authority, since a PM rarely has any.

Equity is not incidental to this. Companies that want people to act like owners generally have to compensate them somewhat like owners; that is a deliberate design choice, not a perk. Some designers and engineers actively avoid moving into PM roles specifically because outcome-ownership is a heavier weight than task-ownership, which is itself a useful signal of who is ready for it and who is not yet.

Managing Time

"No time for real product work" is nearly always a symptom, not a workload problem. A PM doing product management needs roughly four uninterrupted hours a day for discovery, figuring out what is actually worth building, not the fragmented hour a frenzied meeting schedule leaves behind.

The trap is subtle: project-management tasks (status chasing, ticket grooming, meeting logistics) feel urgent, tangible, and satisfying to check off, so they crowd out discovery work that is harder to see progress on day to day. A PM who spends their time this way is doing a different job than the one they were hired for, whether or not anyone has said so out loud.

The fix is not working later, it is protecting four hours as fiercely as you would protect a customer meeting, and, where possible, pairing with a delivery manager who can absorb the project-management load entirely. Without that protection, a PM either burns out chasing a sixty-hour week or quietly fails to deliver the thing discovery time exists to produce. If your calendar has no unbroken four-hour block this week, that is the diagnosis, not a scheduling inconvenience.

Thinking

Intelligence and the ability to actually think through a hard problem are not the same thing, and Google access makes the gap worse, not better, by making information retrieval feel like problem-solving. Designers and engineers get real practice at this by default: designers solve inside user-experience constraints, engineers inside implementation constraints. PMs have to solve across customer need, industry dynamics, and business viability simultaneously, which is a harder, more diffuse kind of thinking to develop.

A basic question asked without any visible homework behind it is the clearest tell of weak thinking, more reliable than confidence or fluency. The written narrative from Chapter 11 is the best available forcing function for this specific gap too: it is uncomfortable precisely because it makes shallow thinking visible on the page, and that discomfort is diagnostic, not something to spare someone from.

For most people with enough raw intelligence and real willingness, the ability to think rigorously through a hard problem can be built through sustained coaching. For a smaller group, the discomfort reveals they are not suited to the role, which is also useful information, just earlier and cheaper to learn than after a year of underperformance.

Team Collaboration

Collaboration on a real product team gets misdefined constantly, usually into one of three wrong shapes.

What collaboration is not

• Not consensus. The team defers to the tech lead on architecture and the designer on user experience; disagreements more often get resolved by running a test than by a vote.
• Not artifacts. Requirements documents and handoff specs move a team from problem-solving into implementation-only mode, which is Waterfall wearing an Agile badge.
• Not compromise. A watered-down solution where everyone gives up a little is a worse outcome than a real one, not a diplomatic success.

Real collaboration looks like three people sitting around a prototype (usually the designer's), each bringing something the others do not have: the engineer sees new technical possibilities, the designer sees experience implications, the PM weighs business viability and constraints. That combination, not any one person's judgment alone, is what produces a solution that is simultaneously valuable, usable, feasible, and viable.

Collaboration breaks in two predictable ways: a PM who has not done their homework has nothing real to bring to the table and the team defaults back to building whatever was requested, or a PM who is arrogant enough to treat their own pre-formed solution as final turns missionaries back into mercenaries. Either failure traces back to the manager's coaching, not a personality clash on the team.

Stakeholder Collaboration

Feature teams treat stakeholders like clients to be managed; empowered teams treat them as partners who bring expertise a solution cannot work without. A legal stakeholder is not a blocker to route around, they are the person who knows exactly which approaches are compliant and which are not, and that knowledge belongs inside the discovery process, not bolted on after a solution is already chosen.

A practical exercise for building the relationship

• 1. List every regular collaborator and input provider, including senior stakeholders.
• 2. Circle the three to five relationships most critical to your success.
• 3. Circle the one or two you most dread dealing with, since that is where the real investment is needed.
• 4. Spend real, non-work time with those people, one on one, building enough rapport that disagreement later stays professional instead of personal.

The agency model is the cautionary parallel here: an outsourced team taking direction from a "client" ends up as capable mercenaries with no path to real ownership, no matter how skilled the individuals are. Anyone joining an empowered team from an agency background usually needs deliberate re-coaching away from that client-service reflex before real stakeholder partnership is even possible.

Imposter Syndrome

Imposter syndrome is not a flaw to push through, it is a warning to listen to. The fear of "looking clueless" in front of a room is, more often than not, an accurate signal that the homework is not done yet, not an irrational feeling to override with confidence alone.

Seeking out honest, expert feedback before something goes public, from someone willing to actually poke holes in it, is the practical answer to that signal. Confidence built on unpreparedness is fragile; confidence built on having already survived a tough pre-review is real.

The manager carries most of the responsibility here, not the individual. When someone shows up underprepared in front of executives, the first question is whether their manager insisted on seeing a draft, arranged a rehearsal, or connected them with someone who could give expert feedback outside the manager's own expertise.

A team's trust with executives is hard to rebuild once an unprepared appearance damages it, and a manager's own reputation is only as strong as the weakest presentation their team has given.

There is no reason to walk into a room as an imposter; the fix is preparation, not bravado, and it is a shared job between the person presenting and the manager who is supposed to have set them up to succeed.

Customer-Centricity

Most leaders claim to care about customers. What they actually do during an outage, or how often they personally sit with real users, is the only reliable measure, not what is in the values deck.

Making it real instead of a slogan

• Protect the word "customer." Only actual paying users or the target audience count. A CEO, an internal stakeholder, or an ad partner is not a customer, and blurring the term quietly erodes where the team's attention actually goes.
• Mandate real exposure: a minimum of three one-hour customer interactions a week, for PM, designer, and engineer alike, discussed explicitly in 1:1s.
• Treat a showstopper customer problem as the real test. Urgency in that moment, not a mission statement, is what customer-centricity actually looks like under pressure.
• Innovate on customers' behalf rather than simply asking what to build; a focus group tells you what people can imagine, not what is possible.

Genuine customer-centricity takes a year or more to build into a person's habits and instincts, and it has to be modeled from the top or it never survives contact with a deadline. If your team cannot produce three concrete customer stories from the last month without scrambling to remember one, the mandate is not real yet, it is aspirational.

Integrity

Integrity for a PM on an empowered team is not abstract, it is the daily foundation everything else, trust with executives, with stakeholders, with the team itself, gets built on. Under constant conflicting pressure (a CEO wanting speed, a team needing more time, a stakeholder feeling ignored), it is also the first thing to erode without deliberate attention.

Three behaviors worth coaching explicitly

• Dependability: commitments are taken seriously, and even well-intentioned overpromising does lasting damage to trust.
• Informed judgment: a commitment is only as good as the discovery work behind it, real input from engineers on feasibility, real assessment of value and viability, not optimism.
• Delivery: for an empowered team, delivery means the solution actually works and solves the problem, not merely that something shipped on the date promised.

Acting in the company's best interest, not just the team's, is the other half of integrity: helping other teams, crediting others publicly, supporting a decision that is right for the business even when it is not optimal for your own team's numbers.

Accountability does not mean nobody survives a miss. It means asking, honestly, what you personally could have done differently, whether that is assessing feasibility risk more carefully or raising a concern earlier, rather than pointing at engineering or the market. A PM's career survives being wrong sometimes; it does not survive being seen as undependable, self-interested, or unwilling to own a mistake.

Decisions

A good decision is not just correct, it is one the team, executives, and stakeholders can understand and support even when they would have chosen differently themselves. That distinction, defensible versus merely correct, is what separates decisions that build trust from decisions that just happen to work out.

Five behaviors that produce defensible decisions

• 1. Right-size the analysis. A reversible, low-stakes call deserves minutes, not weeks; a company-shaping one deserves the opposite. Misjudging this in either direction is one of the most common coaching gaps for a newer PM.
• 2. Decide by expertise, not consensus. Defer to the tech lead on feasibility, the designer on usability, stakeholders on business constraints, rather than voting or waiting for unanimous agreement.
• 3. Resolve disagreement by running a test, not by whoever argues loudest or outranks the room. A cheap prototype settles more debates than another meeting does.
• 4. Be transparent. A quick note explains a minor call; a full written narrative, FAQ section included, explains a major one and heads off assumptions of a hidden agenda.
• 5. Disagree and commit. Passionate debate before a decision is a sign of missionaries, not dysfunction. Undermining the decision afterward, even quietly, is what actually damages trust.

Jim Barksdale's line is worth keeping close for the smaller, faster calls this does not cover: if you see a snake, kill it; do not play with dead snakes; every opportunity starts out looking like a snake. Decision-making is a skill built through repetition and honest coaching, not something a smart new hire arrives already holding.

Effective Meetings

Most meetings are the wrong tool for the job they are being used for. If something can be handled asynchronously, a status update, a document to review on your own time, it should be, because the real cost of a meeting is stopping everyone's independent work at once, not the thirty minutes on the calendar.

Three kinds of meetings actually worth calling

• Communication: information too complex or high-stakes to send in writing (a strategy all-hands, for instance).
• Decisions: a call that exceeds the team's own autonomy, best opened with everyone reading a written narrative in silence so the discussion starts from shared context instead of a live pitch.
• Problem-solving: the answer genuinely is not known yet and needs the right minds in the room together, a postmortem after an outage is the clearest example.

A short framework for running one well

Define the purpose up front (which of the three above), split attendees into essential and optional, prepare accordingly (visuals for communication, a narrative for decisions, data for problem-solving), facilitate toward the stated purpose rather than letting it drift, and close the loop afterward so anyone who was not there knows what was decided.

A team's meeting discipline is visible to executives in a way that is easy to underestimate: a meeting that wastes people's time or fails to reach its stated purpose reads as a signal about the team's competence generally, fairly or not.

Ethics

Product teams weigh four risks by default: value, usability, feasibility, business viability. A fifth deserves the same explicit status: ethical risk, whether a solution should be built at all, not just whether it can be.

It gets skipped constantly because business viability is already a crowded category (sales, legal, finance, compliance) and few companies assign anyone the specific job of asking the ethics question. Airbnb's former Chief Ethics Officer Rob Chesnut argued that a company answering only to shareholders, while ignoring impact on employees, users, and the surrounding community, eventually pays for that blind spot in the business itself, not just in reputation.

Three quick tests worth running on a solution before shipping it

• Would you be comfortable if every internal email and document about this were published?
• How would a regulator react on learning everything about how this was built?
• Would you be proud to have this as part of your own name, publicly attached?

If a genuine ethical concern surfaces, raise it clearly and without accusation, framed as protecting the company's own interest, not as a moral objection from the sidelines, and back it with real understanding of the business context so it lands as informed rather than naive. If a company consistently ignores that kind of concern once raised, that is the point at which staying becomes the harder question to justify, not the concern itself.

Happiness

A manager is not directly responsible for anyone's happiness, but has an outsized ability to cause misery or make real fulfillment possible, which makes this worth treating as a real management responsibility rather than a soft afterthought.

What actually moves the needle

• Meaningful work, usually a bigger factor than compensation, as long as compensation is not actively a problem: people need to hear, repeatedly and specifically, how their work connects to the company's mission and to real customers.
• A genuine personal relationship, built on believing the manager is actually invested in their success, which includes some honest vulnerability from the manager, not one-way scrutiny.
• Personal recognition, beyond formal comp and promotions: something specific and human, not generic praise.
• Sustainable work habits. Long hours chosen out of genuine engagement are different from long hours forced by pressure; a manager who works themselves ragged is implicitly demanding the same from their team, whatever they say out loud.
• Honest career conversations, including, sometimes, helping someone find their way out of a product role entirely if their real passion lies elsewhere.

Bill Campbell, "the Coach of Silicon Valley," measured his own success by how many people he had coached who went on to become great leaders themselves, not by his own title or tenure. That is the standard this chapter is ultimately arguing for: a manager's legacy is the people, not the org chart position.

Leader Profile: Lisa Kavanaugh

Lisa Kavanaugh moved from engineering leadership, eventually CTO at Ask.com, into full-time coaching of technology leaders making the same transition. Her framework names four skills that determine whether a leader can actually make the empowerment shift, not just endorse it.

Four skills for the transition

• Self-awareness: recognizing that the exact behaviors that earned an earlier promotion, close personal execution, tight control, can become the thing blocking the next one.
• Courage: the willingness to trust a team enough to let them make real mistakes, give honest feedback, and be vulnerable in return, not just delegate tasks while still controlling outcomes.
• Rules of engagement: explicit agreements about how much visibility a leader needs to feel safe granting real autonomy, renegotiated as trust grows rather than fixed once.
• Disrupting yourself: deliberately breaking habits that have become part of a leader's identity, expecting regression along the way, and treating that regression as normal rather than as proof the change is not working.

The practical takeaway for anyone reading this as a leader, not just a case study: if you cannot currently name your own rules of engagement with your team, the ones that would let you actually step back, that gap, not a lack of trustworthy people, is very likely what is keeping you in the control seat.

Competence and Character

Two things matter in hiring for an empowered team, and neither is "10x talent" or "culture fit." A 10x contributor who is toxic can cost a team far more in morale and collaboration than their output ever returns; empowered teams win through collective effort, not star output.

"Culture fit" is worse than useless as a hiring filter, it is usually a polite name for "people who look and think like us," which produces homogeneous teams that solve hard problems worse, not better.

What actually predicts trust

Borrowing Stephen Covey's definition, trust is a function of competence and character, nothing else.

• Competence: real skill for the role. A manager who is not competent themselves will struggle to judge anyone else's competence accurately ("A's hire A's, B's hire C's"). Hiring for potential is fine, but only if the manager is committing to real coaching and taking responsibility if it does not pan out.
• Character: the "no assholes rule," borrowed from the All Blacks rugby team's own hiring philosophy. Toxic people often hide it well in interviews but are known by former colleagues, which is exactly why reference checks matter more than interview polish.

Diversity is not a separate initiative bolted onto this, it is the direct consequence of hiring for competence and character instead of fit: a genuinely broad talent pool, filtered only on those two things, produces more varied thinking, not less. Companies that justify keeping a skilled but toxic person, or hire a pleasant but incompetent one, are both quietly undermining the trust empowered teams run on.

Recruiting

Recruiting is the hiring manager's job, not something HR does while the manager waits for resumes to arrive. Strong product companies treat it the way a college coach treats scouting: proactive, continuous, and personal.

Proactive recruiting is also the fastest real lever on diversity, since it lets a manager seek out different educational backgrounds and problem-solving approaches directly, instead of waiting for "culture fit" applicants to self-select in. That means building a real network continuously: industry conferences, meetups, competitors, customer and partner visits, referrals, thought-leadership writing, all treated as an ongoing relationship-building activity, sometimes over years, not a burst of effort when a role opens.

Chris Jones's own early lesson from his manager captures the mindset shift best: told that hiring his next PM was his single most important task and that he needed to spend at least half his time on it, he had to reframe from passively sourcing to actively recruiting, and it changed how he thought about the job of managing permanently.

Outsourcing core product roles, PM, design, engineering, is a different failure mode entirely: it produces "mercenary teams" almost by definition, and while it can look cheaper on paper, the overhead, communication cost, and lost capacity for innovation usually make a smaller internal team of missionaries the better economic bet, not just the better cultural one.

If you are waiting on HR to send you PM candidates instead of building your own pipeline, that is this chapter's diagnosis, not a staffing shortage.

Interviewing

The hiring manager owns the interview process end to end, and the single most common way that process fails is making the interview panel too large in the name of inclusivity, which reliably lowers the bar instead of raising it. A curated panel of people who are themselves both competent and good character, people a strong candidate would be proud to work alongside, beats a large committee every time.

Every interviewer needs to know exactly what they are assessing, and the day should be designed to close out every open question by the end, not leave ambiguity for a later round; it is fine to end early if the answer is already clear. Hiring for potential is legitimate, but only when the hiring manager explicitly flags it to the panel and personally commits to intensive, near-daily coaching afterward, owning the outcome if it does not work.

Prioritizing product skill over domain knowledge is the right default for most roles: a skilled person picks up a new domain faster than a domain expert picks up product skill, and too much domain knowledge can actually be a liability if someone starts assuming they are the customer.

Chris Jones's favorite closing question is worth stealing directly: ask the candidate, late in the interview, to stack-rank four broad attributes, execution, creativity, strategy, growth, from strongest to weakest. There is no right answer, which is exactly why it works: it surfaces real self-awareness, and it doubles as a check on the interviewer's own bias toward hiring people just like themselves.

Hiring

Once you have found the person, speed matters more than most managers treat it: a strong candidate deserves an offer within 24 to 48 hours, and any longer reads as indecision and risks losing them to someone faster.

Reference checks are not a box to delegate, they belong to the hiring manager personally, and the single most useful question to ask a reference is simply "would you hire this person again?" That question surfaces toxic patterns an interview loop can miss entirely.

What actually closes a strong candidate, more than compensation, is usually the hiring manager's personal, specific promise to invest in their coaching and development; for exceptional candidates, a direct call from the CEO or another senior leader can be the differentiator.

On span of control

There is no universal right number of direct reports. It should shrink when a manager carries heavy operational responsibility themselves, shrink further for less experienced reports who need more intensive coaching, and can grow somewhat for an experienced manager who coaches efficiently. A company bragging about a very flat structure and huge spans of control is usually either paying a premium for already-finished talent, or quietly neglecting coaching altogether.

If your own span feels unmanageable, that is worth checking against these factors before assuming it is just a headcount problem.

Remote Employees

Delivery work, coding, QA, generally holds up fine remotely. Product discovery is the part that suffers, because it depends on spontaneous, intense, real-time collaboration that is much harder to replicate over distance.

Three specific ways remote work damages discovery

• Reverting to artifacts. Separated PMs, designers, and tech leads drift back toward formal handoff documents, requirements written by the PM, wireframes handed to engineering, instead of solving problems together in real time around a shared prototype. That is Waterfall wearing a remote-work excuse.
• Eroding psychological safety. Distance strips out the tone and body language that keep written disagreement from reading as cruelty; sensitive conversations need video specifically because trust depends on those signals.
• Fragmented time. Not every home environment supports focused work equally, and a manager who assumes otherwise will unintentionally punish people with real constraints (childcare, shared space) rather than accommodating them.

None of these are unsolvable, they just require active, deliberate effort a co-located team gets for free: insisting on live discussion over written handoffs, moving sensitive topics to video by default, and being genuinely flexible about when deep-work time actually happens for a given person. A remote team that treats these as background risk rather than something to actively manage will quietly lose its discovery capability without anyone noticing until results slip.

Onboarding

The first three months set the tone for someone's entire tenure, and a manager's job is far from done once an offer has been signed. Senior leaders form first impressions fast, and those impressions are hard to walk back later.

Checkpoints worth tracking explicitly

• End of day one: has this person made a friend, and do they understand what is expected of them?
• End of week one: have they personally met every teammate?
• End of month one: do they have a real grasp of the company and their own potential in it?
• Sixty days in: have they landed a visible, public win?

Two things matter more than any checklist: building competence (using the Chapter 8 assessment to shape a real coaching plan from day one, especially deep customer, business, and financial exposure for a PM) and building relationships, including the manager personally introducing the new hire to key stakeholders and vouching for them, then following up to track how that is landing.

For companies with enough scale, an Associate Product Manager program (the model Google pioneered) is worth the investment: taking high-potential people through one to two years of intensive, near-weekly coaching produces both strong PMs and a meaningful diversity gain, since it selects on potential rather than existing pedigree. Cagan is blunt about his own biggest regrets as a manager: the times he under-invested in someone's onboarding, which cost far more in cleanup later than the time saved upfront.

New Employee Bootcamp

Even highly capable people, hired from other successful companies, regularly struggle in a new organization, not from lack of skill but from lack of context: how decisions actually get made here, who to trust, how the org really works. A standard new-hire orientation does not close that gap.

A five-day intensive bootcamp, run for PMs, designers, and tech leads together, closes it faster than months of ambient onboarding. This is SVPG partner Christian Idiodi's contribution to the book. Each day opens with something personal (communication style, career planning) before the day's real content, on the logic that a leader has to put their own oxygen mask on before they can coach anyone else.

The core of each day is company-specific strategic context, customer history, financial model, discovery process, taught by people who actually live it, not generic product theory. A current product person from the company shares real experience after each session, which does more for trust-building than any slide deck could. Afternoons apply the morning's material directly with each person's actual future teammates in the room, so the collaboration muscle and the content land together instead of separately.

The point is not orientation paperwork, it is this: a company does not hire smart product people to be told what to do, it hires them to solve hard problems in ways customers love and the business can sustain, and that only works if they are equipped with real context fast, not eventually.

Performance Reviews

If it were up to Cagan, annual performance reviews would be scrapped entirely. They exist for HR compliance and comp administration, not development, and treating them as the primary feedback mechanism is a category error.

The weekly 1:1 is where real feedback lives, continuous, timely, specific. The single hard rule that follows from this: there should never be a surprise in an annual review. If someone learns about a real performance problem for the first time during a formal review, that is not a reflection on the employee, it is a manager who has "utterly failed" at the most basic part of the job.

The common failure pattern is a conflict-averse manager who avoids hard conversations all year, then gets asked by HR to document issues for a termination or performance plan, blindsiding someone who had no warning. That is treated as a serious performance problem for the manager, not the employee, sometimes requiring their own manager to review 1:1 notes or step in directly.

The willingness to give honest, timely, uncomfortable feedback, made unmistakably clear if softer hints are not landing, is the single most basic skill a manager needs. If your last review contained anything the person had not already heard from you, that is the failure this chapter is naming.

Terminating

A termination decision is not only about the individual, it is about what staying silent signals to everyone else: the rest of the team absorbing the slack, and the message inaction sends about what the organization actually tolerates.

Two genuinely different situations, two different responses

• Lack of competence, despite real coaching. After a sincere three to six months of effort, communicated with rising clarity in weekly 1:1s all along, if it is still not working, that is at least partly a hiring mistake, and the manager owes that person real help finding a better-fit role, internally or externally.
• Toxic behavior. This is different in kind, not degree: real damage to trust and psychological safety, not an occasional bad day. Still worth a genuine three-to-six-month attempt to see if it is temporary or fixable, but if it persists, protecting the rest of the team takes priority, and there is no obligation to help that person land somewhere else.

Removing someone genuinely toxic is, in Cagan's words, "always the right thing to do," whatever short-term disruption it causes. Neither situation is pleasant, but treating both the same, either by tolerating toxicity because the person is skilled, or by abandoning someone who is genuinely trying but under-skilled, undermines the same trust that makes empowerment possible in the first place.

Promoting

Where terminations are the hardest part of staffing, promotions are the best evidence a manager is actually doing the job. Every promotion on your team is a direct, visible measure of your own effectiveness as a coach, not just theirs as a performer.

That starts with actually knowing what someone wants: staying deep as an individual contributor, moving into leadership, or eventually starting their own company, none of which is a wrong answer, but a manager who never asks cannot help with any of them. From there it is mechanical: assess current skill against the next level's real requirements, build a specific gap list, and work it the same way a coaching plan works any other gap.

Once someone is genuinely ready, the manager's job shifts to advocacy, doing everything possible to get that promotion approved and making sure the person is positioned to seize it the moment an opening exists.

Moving from individual contributor to manager deserves special scrutiny: it is a fundamentally different job, not a senior version of the old one, and someone pursuing it for the title or the money alone (which is exactly why dual-track IC ladders matter in tech) is a promotion set up to fail both the person and their future reports.

"People join a company, but leave their manager." Consistent attrition of strong people from a specific team is rarely bad luck, it is usually a signal about that manager, the same way a reputation for genuinely developing people becomes a magnet for talent wanting to join.

Leader Profile: April Underwood

April Underwood's path through Travelocity, Apple, Google, Twitter, and eventually CPO at Slack tracks a real shift in what companies have wanted from a PM over time: business-minded generalists early on, more technical and design-literate PMs as mobile took over, then business-savvy generalist PMs again as innovation moved into operationally complex spaces like rideshare and delivery. Knowing which "flavor" of PM a specific role actually needs, rather than hiring generically, is itself a skill worth being deliberate about.

Her own career, built from repeated moves across marketing, partnerships, and other adjacent functions rather than a straight product-management line, became her biggest asset as a leader, not a detour from one. That functional breadth is what let her hire and develop leaders for roles unlike her own background, build real bridges across departments, and consistently anchor product decisions in the company's broader mission rather than the product's own narrow interests.

The practical implication for anyone building a product career: a "sidestep" into an adjacent function is not a step off the path toward product leadership, it is frequently the fastest way onto it, since the leaders who eventually run whole companies are rarely the ones who only ever did product work.

Creating a Compelling Vision

A product vision is not a mission statement or an inspirational slide, it is a working artifact that does several distinct jobs at once, and treating it as decoration is why most companies' visions do none of them.

What a real vision actually accomplishes

• Keeps the organization customer-focused, told from the customer's perspective (how their life changes), not the business's growth targets.
• Acts as a genuine North Star, so every team, however narrow their current problem, understands how their work ladders up to something bigger.
• Makes the work meaningful enough to sustain motivation for years, not just the next sprint.
• Names the real industry trends and enabling technologies worth building on, while filtering out fads, since customers care about problems solved, not the technology used to solve them.
• Gives engineering enough clarity to make long-term architecture decisions instead of building for whatever is asked this quarter.
• Doubles as the single most effective recruiting tool a company has for attracting people who want meaningful work.

A strong vision is best expressed as a "visiontype," a high-fidelity conceptual prototype of the future experience, built with a real product designer, not a slide deck. Ownership is genuinely collaborative: the CPO drives it, but it has to integrate the Head of Design's and Head of Technology's perspectives, and the CEO needs to feel real ownership of it too, since they are the one who will be selling it thousands of times, internally and externally, for years to come.

A vision that is prescriptive about implementation details has already failed at its job; the details are exactly what product teams exist to discover.

Sharing the Product Vision

A great vision that is not communicated well accomplishes nothing. A PowerPoint deck rarely inspires anyone; the minimum bar is a visiontype, and many companies go further with a scripted video that uses music and emotion the way a film would, showing different kinds of customers actually living inside the future product.

What you can and cannot validate about a vision

You can validate demand: whether customers genuinely have the problem you think they have, and whether it is serious enough that they would want a new solution today. You cannot validate the solution itself, because it does not exist yet; pursuing a vision always requires a real leap of faith that the organization will eventually discover a solution that fulfills it.

Roadmaps and visions get confused constantly, especially under pressure from a direct sales force wanting something concrete to show customers, but they should never be treated the same way. A roadmap of specific features and dates is dangerous to share externally, because most individual features on it will not end up mattering, and walking one back after a customer has already bought based on it invites real legal exposure.

A vision is safe to share broadly, because customers are usually hungry for the long-term direction itself, even without using that word. The right posture is stubborn on vision, flexible on the tactical roadmap underneath it, sharing the former freely and guarding the latter closely.

The vision also quietly shapes engineering architecture decisions years in advance, and shapes team topology (especially for platform teams); a re-platforming effort undertaken without a clear vision behind it tends to rebuild the wrong thing, just on newer infrastructure.

Product Principles and Ethics

A vision tells a team where the company is headed; principles tell a team how to resolve the daily trade-offs that vision does not specify. When ease of use and security pull in opposite directions, or short-term revenue and long-term trust conflict, principles are what let a team decide without escalating every single call.

Cagan's fifth product risk, alongside value, usability, feasibility, and viability, is ethical risk: should we build this at all. It is easy to lose track of, because business viability already covers a lot of ground (legal, financial, compliance) and few companies assign anyone the explicit job of asking the ethics question on its own.

A solution can create real value exactly as intended and still cause serious harm if used maliciously; a good product principle names the team's responsibility for that possibility up front, rather than treating it as someone else's problem after launch.

The practical value of writing ethical considerations into principles, rather than leaving them as an ad hoc judgment call, is that it makes asking the uncomfortable question a normal, expected part of discovery instead of something that requires unusual courage to raise. That matters more, not less, as newer technology, especially anything involving machine learning, makes unintended harms easier to build accidentally and harder to spot in advance.

Leader Profile: Audrey Crane

Audrey Crane's path ran through pure mathematics and theater before design leadership at Netscape and, later, DesignMap, and her clearest management metaphor comes straight from the stage: a leader's job is a director's job, not a performer's.

What a director actually does that a leader should too

• Sets a shared vision that balances artistic, strategic, and practical constraints, then builds it collaboratively rather than dictating it.
• Follows the "no line readings" rule: a director who tells an actor exactly how to deliver a line has either failed to cast well or failed to trust the actor's own interpretation. A leader who tells a report exactly how to do the work has made the same mistake.
• Looks for talent people do not yet recognize in themselves and convinces them of it, since a team where everyone works from their own genuine strength becomes something no single person, including the leader, could have produced alone.
• Gives direct, regular critique, the same way a director gives notes after every rehearsal, treating it as a basic feature of the relationship rather than a rare, difficult event.
• Celebrates deliberately: theater has built-in rituals (opening night, wrap parties) for shared accomplishment that most companies skip entirely, to their own cost.

The PM-relevant thread running through all of it: a leader's highest-leverage move is rarely doing the work better than their team could, it is recognizing and organizing strengths the team does not yet see in itself, then getting out of the way enough to let that talent actually show up.

Optimizing for Empowerment

Most companies let their team topology happen by accident, mirroring whatever the org chart or engineering skill sets already look like, rather than designing it on purpose. That passive default quietly creates dependencies and ambiguity that work directly against empowerment, and it needs to be revisited deliberately, not left to inertia.

Three goals to balance, none of them optional

• Ownership: a team needs a scope substantial enough to feel like real pride of ownership, not a small cog, but not so vast it creates crushing cognitive load either. Ambiguity about who owns what quietly poisons empowerment before a team even starts.
• Autonomy: enough control to actually solve an assigned problem the way the team judges best, which means deliberately minimizing dependencies. Slicing teams strictly along technical subsystems (a database team, a UI team) makes it nearly impossible for any one team to own a full customer experience, no matter how empowered the language around them is.
• Alignment: how well team boundaries track the strategic context around them, both the technical architecture and the business structure. Good alignment produces fewer dependencies and a straighter line from a team's work to a business outcome; legacy technical debt is the most common thing that quietly breaks it.

There is no universally correct topology, only trade-offs, and product, design, and engineering leadership need to land on those trade-offs together rather than each optimizing their own dimension in isolation.

Team Types

Every product team is fundamentally one of two types, and confusing the two produces a topology that looks organized but is not.

Platform teams exist to create leverage or absorb complexity for everyone else: shared authentication, a reusable component library, payments processing, legacy-system integration. Customers never see their work directly, which is exactly why they are often staffed with a company's strongest engineers, since a robust platform is what lets experience teams stop worrying about underlying complexity and focus entirely on the customer problem in front of them.

In large companies, platform teams can be as much as half of all product teams.

Experience teams own how the product is actually experienced, whether by external customers or by internal employees whose tools indirectly shape the external experience (a customer-service agent's system, for instance). They are most empowered when they own as much of an entire user journey end to end as possible, which a strong platform underneath them is what actually makes possible.

Two structural traps undermine both team types regardless of topology otherwise: treating design as a centralized "internal agency" pulls designers out of the room where real decisions happen, and organizing teams strictly by engineering skill set (a "web team," an "iOS team") reliably produces the same fragmented ownership Conway's Law predicts, shipping your org chart instead of a coherent product. Cross-functional membership should follow what the product needs, not what the reporting lines already look like.

Empowering Platform Teams

Platform teams face a real structural disadvantage: their contribution to any given customer outcome is indirect, which makes empowering them look different from empowering an experience team, even though the goal is identical.

Every platform team carries a baseline of "keep the lights on" work, bug fixes, performance issues, compliance, and for platform teams this can consume anywhere from 10 to 50 percent of capacity, which has to be planned for explicitly rather than treated as a rounding error against their real objectives.

Two ways a platform team still moves forward strategically

• Sharing an objective directly with an experience team, either through deep, near-co-located collaboration (a backend storage team and a content-workflow team jointly enabling video support), or through a cleaner API contract where each team works mostly independently and comes together at integration.
• Treating the platform itself as a product, with real objectives around adoption, developer experience, and growth, especially relevant when the platform is externally monetized, but increasingly applied to internal platforms too, judged by how well internal teams actually adopt them.

Either path keeps the platform team anchored to the same strategic "why" the experience teams are working from, rather than reducing platform work to an undifferentiated queue of tickets. A platform team without a real objective, only a backlog, is a platform team that has been quietly demoted back to a feature team wearing different branding.

Empowering Experience Teams

Experience teams reach their fullest empowerment when their ownership boundary lines up naturally with a real customer segment or journey, because that alignment minimizes the translation work between a business outcome ("reduce churn for this customer type") and what the team is actually building day to day.

Common alignment patterns worth recognizing, not reinventing

• By user type or persona (riders versus drivers in a marketplace).
• By market segment (electronics versus fashion in e-commerce).
• By customer journey stage (onboarding versus retention).
• By sales channel (self-service versus direct sales).
• By geography, where regional differences are large enough to justify it.

Media and e-commerce products tend to split cleanly by content category or vertical, sitting on a shared platform of common services. Enterprise products often split by industry vertical or sales channel instead. Marketplace products usually split by side of the marketplace, since buyers and sellers rarely share the same needs. A single company can mix more than one of these dimensions where it genuinely fits; there is no requirement to pick exactly one pattern and force everything into it.

The same two structural traps from Chapter 42 apply here with equal force: centralizing design into a service pool removes designers from real decisions, and letting engineering reporting lines dictate team boundaries reliably reproduces a fragmented product, no matter how the org chart is labeled on a slide.

Topology and Proximity

Physical location is a real design variable for a topology, not an afterthought to be solved purely with better video-call etiquette, especially once talent shortages and remote work made full co-location the exception rather than the default.

Proximity matters differently depending on what it is proximity to. Co-located PM, designer, and tech lead produces markedly better discovery than any distributed arrangement, since the intense, spontaneous collaboration discovery depends on is hardest to fake remotely. Proximity to customers helps most for the PM and designer specifically, and is worth solving for directly when a product serves a distinct region.

Proximity to other interdependent teams and to a manager both matter less than they used to, and both can be substantially compensated for with deliberate extra effort: more frequent calls, real travel, occasional intense "swarming" on a shared hard problem.

The general-purpose rule, when trade-offs conflict: optimize for co-locating the core product team itself, PM, designer, and engineers, even if that means the team ends up remote from its own manager, from customers, or from business partners. If forced to choose between co-locating a PM with customers or with their own engineers, engineers usually win, because the highest-value collaboration a team does is the discovery work happening inside the team, not the occasional customer touchpoint.

Every other proximity gap can be actively managed; the PM, designer, and tech lead gap is the one hardest to substitute for.

Topology Evolution

Even a well-designed topology has a shelf life. It typically starts organically, when engineering first crosses roughly fifteen people, and needs deliberate revisiting whenever the strategic context underneath it genuinely shifts: a new market, a sunsetting product, a major re-platforming effort, or a team needing to roughly double in size.

When change is warranted, prioritize keeping existing teams intact wherever possible; the collaborative trust a team has built together is real capital, and reassigning an intact team to new responsibility usually beats breaking teams apart and reshuffling individuals. Changing topology more than about once a year, outside a genuine strategic shift, is itself a warning sign of deeper organizational instability, not a sign of agility.

Warning signs worth watching for even without an obvious trigger

• Engineers getting shuffled between teams frequently, a tell that ownership was never really clear.
• Managers constantly stepping in to referee cross-team dependency conflicts.
• Teams reporting they cannot ship even simple work without waiting on someone else.
• A team's scope feeling too small to generate any real sense of ownership.
• Engineers dealing with more complexity across more areas than any one team can reasonably hold in their heads.

None of these individually demands an immediate reorg, but together they are a topology quietly working against the empowerment it was supposedly designed to enable, and the fix is a deliberate redesign, not another all-hands reminder to "collaborate better."

Leader Profile: Debby Meredith

Debby Meredith's specialty, built across HP, Netscape, and a long run advising startup engineering organizations, is walking into a company where engineering has lost the organization's trust and rebuilding it fast. Her method centers on four consistent moves regardless of the specific company.

She starts at the top, not with engineers: many founders and CEOs simply misunderstand technology's role and their own influence on engineering's struggles, and that misunderstanding has to be corrected before anything downstream can change.

From there, she forces real focus, since companies drowning in an unprioritized backlog are, almost by definition, damaging even a strong engineering org by spreading it too thin; her arrival is often the forcing function for a company to finally make the hard prioritization calls it had been avoiding.

Rebuilding trust itself she treats as the core deliverable, since a track record of missed delivery erodes trust between engineers and executives in a way that produces real behavioral and morale problems on both sides. The concrete mechanism for rebuilding it is disciplined commitment: replacing guessed estimates with real feasibility work and prototypes that surface true cost, then treating a commitment, once made, as something engineers take seriously enough to actually deliver on.

"Do what you say you're going to do," applied consistently, is what eventually earns an engineering org the reputation of being reliable rather than merely fast.

Focus

Most leaders believe they are already good at focus, mostly because they have said no to plenty of individual ideas. And yet Cagan routinely finds organizations carrying twenty to fifty "critically important" objectives for a single quarter or year, roughly an order of magnitude too many for any of them to actually get real attention.

Pandora is the cautionary case: its own "prioritization process" let stakeholders essentially buy features until their budget ran out, a textbook feature-team pattern dressed up as prioritization. It generated plenty of shipped features and essentially no strategic impact, and contributed directly to the company's decline. That is what a "fair division of engineering capacity" produces when mistaken for strategy.

Why more initiatives does not mean more impact

Generating activity is easy; identifying and committing to the handful of things that will actually move the needle is the hard, unavoidable part of strategy. Cagan's own early lesson from HP's performance-optimization work applies directly: only a few "hot spots" ever produced a perceptible difference for the user, and effort spent everywhere else was simply wasted, however busy it looked.

The same logic underlies work-in-progress limits from Kanban: an organization juggling twenty to fifty "high-priority" initiatives at once overwhelms every team's actual capacity to make progress on any of them, since each initiative carries a real, non-zero cost in management attention regardless of how small it looks on paper.

Richard Rumelt's line is the chapter's real thesis: good strategy works by concentrating resources on one, or a very few, pivotal objectives whose success cascades into other favorable outcomes. If leadership cannot make the hard cuts down to that few, no amount of downstream execution discipline saves the strategy, because there was not really one to begin with.

Insights

There is no formula for generating the insights a real strategy is built on, only real effort: hours spent in the data, with customers, with the enabling technology, with the industry, before anything resembling an "aha" moment shows up. Insights show up from unexpected places too, an offhand customer remark, a salesperson's comment, an academic paper, which is exactly why constant, open attention matters more than any structured process.

Four sources worth returning to deliberately

• Quantitative data: not just dashboards, but live tests run frequently enough to actually confirm or kill a specific theory.
• Qualitative research: both evaluative (did a specific idea work, and why) and generative (entirely new opportunities that surface while testing something else, sometimes bigger than what was originally being tested). Teams that are already oversubscribed as feature factories routinely ignore this second kind entirely, at real cost.
• Technology: new capabilities that make a long-standing problem solvable in a way that simply was not possible before, best surfaced by letting your own engineers explore and prototype rather than outsourcing that exploration.
• Industry: competitors, adjacent markets, credible analysts. Large consulting engagements are a mixed bag here, useful occasionally, but usually too short and too generic to produce real product-level insight; a smaller, long-term trusted advisor tends to outperform a big-name short engagement.

Getting an insight to the right person at the right moment matters as much as generating it in the first place, and that dissemination is a leadership job, not something a Slack message accomplishes on its own; a Head of Product actively aggregating and sharing learnings across teams in a regular forum is what keeps insight from staying trapped in one team.

Occasionally an insight is big enough to justify pivoting the product vision itself, not just the strategy under it, the way it did for Slack, YouTube, and Netflix. The distinction worth holding onto: a pivot belongs to a genuinely bigger opportunity revealed by real insight, not to a plan simply turning out to be harder than expected.

Actions

Even with real strategic insight in hand, there is a fork every organization has to choose at: hand teams a list of features to build, or hand teams a problem to solve and trust them with how. That single choice is what separates a feature factory from an empowered organization in practice, regardless of what either one calls itself.

Problems beat features for reasons that compound. The people closest to a problem are best positioned to find the right solution to it. A team handed a problem can be held accountable for the actual outcome; a team handed a feature that ships but does not move the number has nowhere left to place accountability.

Ownership runs deeper when a team is trusted to find their own answer, and when a first attempt does not work, an empowered team already understands that iterating is their job, not a sign of failure to escalate.

In practice this becomes a team objective, most commonly an OKR: the objective is the qualitative, aspirational problem; the key results are the quantitative, outcome-based measure of whether it actually got solved, never a list of activities or deliverables, since shipping something is not the same as having solved the problem it was meant to address.

The key results' actual numeric targets have to come from the team itself, with leadership setting the level of ambition, not the specific figures; a real back-and-forth negotiation between leader and team here is healthy, not a sign the process is broken.

The formal OKR mechanism is genuinely secondary. What actually matters is simpler and harder: a knowledgeable leader explicitly naming which problem to work on and how success will be measured, then trusting the team to find the solution.

Management

No strategy survives contact with the real world unchanged, and stopping leadership's job at "we have defined the objectives" guarantees disappointment. Empowered teams handle most obstacles themselves, but they will still hit real ones that need a leader's help.

What active management actually looks like week to week

• Clearing dependencies a team discovers on another already-committed team.
• Getting a team access to a technology or piece of knowledge it needs quickly.
• Stepping in on a major customer issue that needs leadership judgment to balance against objective progress.
• Resolving a stakeholder concern serious enough to threaten a key objective.

The weekly 1:1 remains the primary channel this information flows through, but urgent issues should not wait for it; a manager's job in that conversation is often direct coaching on how to handle the issue, and sometimes direct intervention, a call to a stakeholder, pulling in another team's help.

This is not command-and-control wearing a friendlier name. It is servant leadership: responding to what a team surfaces and clearing what is actually in their way, not dictating the solution for them. The line worth remembering: empowered teams do not need less management, they need better management, more engaged, not more hands-off.

Leader Profile: Shan-Lyn Ma

Shan-Lyn Ma founded Zola, an online wedding-registry company, after a formative negative experience at a previous job, being criticized for having engineers who liked working for her "too much," as if warmth and empowerment were somehow in tension with real leadership. That criticism became the thing she and co-founder Nobu Nakaguchi deliberately built against.

Zola's kitchen literally has signs reading "NO ASSHOLES," "NO POINTING FINGERS," and "NO POLITICS, NO GAMES," not as decoration but as an explicit, stated bet that trust and directness produce better products than pressure does. Diversity, across skill, background, gender, and problem-solving style, was an explicit hiring goal from the company's earliest roles, on the theory that a diverse team serves a diverse customer base (engaged couples, in this case) better than a homogeneous one ever could.

The underlying lesson worth taking from Ma's story is not the specific kitchen signage, it is the willingness to bet company outcomes on trust and empowerment even after having been explicitly told, by a previous employer, that this was the wrong way to lead. A founder who has been told empowerment is soft, and builds the opposite anyway, is often the clearest evidence this book's whole thesis actually holds up outside a case study.

Empowerment

A team objective exists to do exactly one thing: hand a team a problem, with enough strategic context to make good calls about it, instead of a pre-decided feature to build. That single shift changes almost everything downstream about how the work gets done and who is accountable for whether it worked.

Objectives should read as qualitative, aspirational problem statements ("reduce the frequency of parcels delivered to the wrong address"), not implementation plans, and teams should feel free to refine or reframe them as they learn more; that back-and-forth with leadership is a sign of genuine engagement, not scope creep.

Key results are where OKRs most often go wrong: the second most common failure, after insufficient focus, is a team listing deliverables as key results instead of actual outcomes. Shipping something is not evidence the underlying problem got solved. A healthy set runs two to four key results, with a primary measure and one or more "guardrail" results that catch unintended damage elsewhere (reducing wrong deliveries while making sure total delivery volume does not also drop).

Critically, the actual numeric targets have to come from the team itself, not from leadership, or the whole exercise quietly reverts to a roadmap with OKR formatting layered on top.

Assignment

Deciding which team works on which problem is genuinely both top-down and bottom-up at once, and treating it as purely one or the other breaks it. Leaders own the final call, since letting teams fully self-select objectives tends to produce gaps in coverage and drift from real strategy. But actively inviting teams to volunteer for problems they are genuinely excited about, and accommodating that where it is reasonable, produces real motivation a pure top-down assignment never gets.

Once an objective lands with a team, defining the actual key results is the team's job, including an honest acknowledgment that a genuinely new problem may need real time just to gather baseline data before committing to a number; leaders should push teams to start rather than stall in analysis paralysis, while giving explicit guidance on how ambitious to be.

If a team's proposed key results clearly will not produce the business result the objective actually requires, the right response is renegotiating scope, fewer objectives, added collaboration, not overriding the team's own numbers.

Multi-quarter goals need to be broken into shorter, leading-indicator key results for each individual quarter: a two-to-three-quarter goal of six referenceable enterprise customers might become, for quarter one, eight prospects signing a non-binding letter of intent, a real, measurable signal of progress without requiring the full outcome to land immediately.

Every team also carries ongoing "keep the lights on" work alongside its objectives, and if that overhead grows large enough to crowd out real progress, that is a leadership problem to solve directly, not something a team should be expected to just absorb silently.

Ambition

Beyond the objective itself, teams need explicit guidance on how ambitious to be, and that is a distinct dial from effort or urgency, which stay constant regardless. Different ambition levels call for genuinely different discovery techniques, not just a harder push on the same plan.

A "roof shot" targets conservative, high-confidence, incremental improvement; a "moon shot" targets a 10x-scale breakthrough, high-risk, high-reward, and deliberately pushes a team past incremental thinking. Leaders are effectively managing a portfolio of bets across a whole set of objectives, some safe, some genuinely long-shots, the same way any real risk portfolio works, rather than expecting every objective to land at the same confidence level.

The critical distinction not to blur: ambition level is not the same thing as a high-integrity commitment (the subject of the next chapter). A moon shot is, by definition, not guaranteed to succeed, and treating it as if it were a promised deliverable sets everyone up for a false sense of failure when the ambitious bet does not pay off.

Communicating the intended ambition level clearly, so nobody mistakes a genuine moon shot for a safe sure thing, is what keeps a portfolio of bets legible to the rest of the organization instead of reading as a string of broken promises.

Commitments

Most team objectives are genuinely aspirational, but real business deadlines exist too, a trade show, a contractual partner obligation, tax season, and pretending otherwise is exactly what pushes leaders back toward command-and-control roadmaps. The empowered model has to be able to produce real, high-confidence dates when the business genuinely needs them, or it will keep losing ground to the old model on this specific point.

A high-integrity commitment is fundamentally different from the "low-integrity dates" of roadmap-era planning: it can only be made after real discovery work, often including a feasibility prototype, has actually established value, usability, feasibility, and viability for that specific item. The same standard applies to critical internal dependencies, a platform team promising a capability an experience team is building on top of, not only external, customer-facing deadlines.

Once made, a high-integrity commitment is binary: it either gets delivered or it does not, with no "ambition" framing to soften a miss, and any sign of trouble needs to be flagged immediately rather than discovered at the deadline. These commitments are tracked with real visibility, sometimes with a senior leader personally signing off given the reputational stakes, precisely because they are how empowered teams earn leadership's trust in the first place.

The warning worth internalizing: if high-integrity commitments start becoming the norm rather than the rare exception, objectives have quietly turned back into a reformatted roadmap, and empowerment is eroding underneath the language that still describes it.

Collaboration

Teams working together on shared problems takes two genuinely different shapes, and conflating them causes real confusion about who owns what.

Shared objectives versus common objectives

Shared objectives: multiple teams literally share the same objective, common for large initiatives that no single team could deliver alone. Sometimes this is close, near-continuous collaboration (a backend team and a content-workflow team jointly enabling a new feature); sometimes it is looser, with an API acting as the contract between teams that otherwise work independently and only reconvene for integration and testing.

A "swarm," temporarily combining people from multiple teams for an unusually hard problem, is the most intense version of this pattern, used sparingly and for a bounded window.

Common objectives: different teams tackle the same problem, but independently, from their own distinct angle, deliberately, as a risk-management strategy for problems where the right approach genuinely is not known in advance (reducing subscriber churn, say).

This raises a real attribution challenge when it is time to credit results: rigorous A/B testing isolates one team's contribution cleanly but needs real traffic to work; simpler "slicing" by channel or source is easier to set up but less precise, since the same customer often touches more than one team's work along the way.

Neither pattern is a failure of autonomy or a sign teams "should" be working in isolation; treating shared and common objectives as normal, even necessary, for the hardest problems is itself part of a mature product strategy, not a compromise on empowerment.

Management

Setting good objectives is only the starting condition; keeping them on track requires the same active, ongoing management strategy needs generally, and that work does not stop once the quarter's OKRs are written down.

What ongoing objective management actually requires

• Watching keep-the-lights-on work closely enough that a spike does not quietly consume the capacity meant for strategic progress.
• Real weekly check-ins, whether a dedicated meeting or folded into standups, so a team can surface upcoming risk before it becomes a miss.
• A PM raising anything genuinely important to their manager immediately, not saving it for the next scheduled 1:1.
• Active tracking of cross-team dependencies, in both directions, so a delay on one team's side does not blindside another team counting on it.

There is also a collaborative obligation that goes beyond any single team's own numbers: in a genuinely empowered organization, the operating assumption is "we either all succeed or none of us do," which sometimes means a team making a call that is clearly better for the customer and the broader business even when it is not optimal for that team's own metrics.

That is servant leadership in practice, not a contradiction of autonomy: supporting and unblocking teams through the inevitable urgencies of running a real business, rather than either dictating to them or abandoning them to figure everything out alone.

Accountability

Empowerment's necessary counterpart is accountability, and what that actually looks like depends heavily on what kind of failure it is. Missing a genuine moon shot is often expected, even a sign the team took the right level of risk. Missing a conservative roof shot, and especially missing a high-integrity commitment, deserves real scrutiny, since those were supposed to be close to certain.

Treating a substantial miss like a postmortem for an outage, rather than something to quietly bury, is what turns failure into genuine learning: the team meets with the peers actually affected, walks through what could and should have gone differently, and manager included, since a manager should also be asking whether warning signs were missed or earlier coaching could have changed the outcome.

The discomfort of that conversation is part of what makes it work, not a reason to skip it.

Attributing credit when multiple teams contribute to the same result runs into the same two techniques from Chapter 57: A/B testing when traffic allows for it, simpler channel-based slicing when it does not, understanding that slicing trades precision for practicality. Multiple teams pursuing the same objective from different angles is a normal, often wise, pattern for the hardest problems, not evidence that ownership boundaries have broken down.

Objectives in Perspective

Ten points worth holding onto as the compressed version of everything Part VII has covered:

• 1. Empower teams by assigning problems, with real strategic context, never pre-decided features.
• 2. Welcome volunteering, but leadership still owns final coverage across the whole organization.
• 3. Leadership assigns the objective; the team, and only the team, defines the key results.
• 4. Real back-and-forth negotiation on key results is healthy, not a sign the process is broken.
• 5. Multiple teams tackling the same problem from different angles (common objectives) is a legitimate risk strategy for hard problems.
• 6. Multiple teams sharing one objective (collaboration) is normal when different skill sets are genuinely required together.
• 7. Ambition needs to be communicated explicitly: moon shot, roof shot, or high-integrity commitment, each with a different implied confidence level.
• 8. Accountability is only fair once a team has genuinely been empowered to find its own solution.
• 9. Keep-the-lights-on work is real, ongoing, and has to be planned for alongside strategic objectives, not treated as free capacity.
• 10. Objectives are typically set or refreshed quarterly; mid-quarter changes should be the rare exception, not routine.

The formal technique, OKRs specifically, matters far less than the conversation underneath it: a knowledgeable leader explaining real strategic context, naming the actual problem, and then genuinely trusting the team to solve it.

Leader Profile: Christina Wodtke

Christina Wodtke's path from art-school photography into design leadership at Yahoo, LinkedIn, MySpace, and Zynga, and eventually into teaching at Stanford, traces back to a specific set of mentors who each shifted how she led.

Irene Au, her first design manager, modeled that empathy and authority were not actually in tension, that you did not have to choose one over the other to lead effectively.

Jeff Weiner pushed her into managing eighty people across nine managers despite her own doubts, and his simple insistence, "I know you can do this job," forced a real shift in her own self-belief and, more importantly, in her job description: from designing products directly to designing the conditions where good design could happen at all, meaning she had to learn to design effective, largely self-managing teams instead.

A specific moment crystallized the change: responding to a manager's problem by asking what he thought they should do, then simply agreeing, rather than supplying her own answer. That single habit, repeated, shifted her from being the answer to being the person who helped a team find its own answer, "from me to we." At a certain scale, trusting the team was not optional, it was the only way she could function at all, let alone sleep at night.

Ken Norton later reshaped how she saw product management itself, from "project managers I had to chase away from my designers" to genuine equal partners built on mutual respect, "we are better together." Her own books, Radical Focus and The Team That Managed Itself, are the direct downstream product of that shift in how she saw the PM and design relationship.

Company Backgrounder

The case study runs through a real, anonymized company: a two-sided jobs marketplace connecting employers with job seekers, roughly five years old, doing about 45 million dollars a year and growing around 30 percent annually, close to profitable but choosing growth over near-term margin.

About 230 people total, with roughly 95 in product and engineering. Some details are deliberately layered in from later periods to make the illustration richer, but the underlying dynamics, growth-stage scale, real technical debt, an early push into enterprise, are genuine and broadly applicable well beyond this one company.

Company Objectives

The board set exactly two objectives for the year, which is itself the point: real focus starts at the board level, not just inside product.

Objective one: keep growing the core business

Grow core revenue at least 25 percent, cut employer churn from 6 percent to 5 percent or lower, raise job-seeker success rate from 23 percent to at least 27 percent. This exists specifically so the company does not "take its eye off the ball" while chasing something new.

Objective two: prove the company can serve enterprise-class customers

A single key result: land at least six enterprise reference employers, backed by real incremental investment (a new product team, plus sales, marketing, and customer-success staff), explicitly framed as an initial bet rather than a full pivot.

Both objectives are stated as business outcomes, tied directly to the company's own scorecard, never as a list of specific projects or features. That is the discipline this whole case study is meant to demonstrate in practice, not just in principle.

Product Vision and Principles

The company's specific vision and principles stay deliberately unstated here, to preserve anonymity, but their presence and real weight matter to the case study regardless.

The company's founding purpose, helping people find good jobs and helping employers find strong candidates, and its principles were demonstrably more than a values poster: the company consistently chose long-term customer benefit over short-term company gain when the two conflicted, and product, engineering, and design leadership kept both vision and principles genuinely in view while pursuing this quarter's objectives, not as background context but as an active reference point for daily decisions.

Team Topology

Sixteen product teams, roughly 95 product and engineering staff (60 engineers, 12 PMs, 10 designers, 2 researchers, 3 data analysts), organized to mirror the company's own two-sided structure: five employer-facing teams, six seeker-facing teams, and five platform teams supporting both sides, about a third of total resources.

Twelve PMs across sixteen teams means some PMs cover more than one smaller team, and some platform teams run PM-less, with a tech lead serving as the primary product partner instead, a real, working example of the trade-offs a topology has to make rather than a theoretical edge case.

The employer side splits into a dashboard and posting team, recruiter tools, premium services, employer communications, and a brand-new enterprise tools team, with an embedded product-marketing person, reflecting how much go-to-market work the enterprise push actually required. The seeker side splits similarly, home and personalization, search, recommendations, applications, communications, and mobile. Platform teams cover shared services, payments and billing, data and reporting, infrastructure (carrying the re-platforming effort), and internal tools.

The structure is a direct, working illustration of Part V's alignment principle: boundaries track the real business shape (employer versus seeker versus shared infrastructure), not an arbitrary technical split.

Product Strategy

Turning two board-level objectives into sixteen teams' worth of actual work followed the same Focus, Insights, Action, Management sequence Part VI laid out, not as theory this time but as a real quarter's work.

Focus and insights, applied for real

Focus came largely pre-set by the board itself: only two real priorities, core growth and an enterprise bet, with several other tempting opportunities (geographic expansion, new employer services) explicitly deferred, and an explicit rule that the enterprise push could not come at the core business's expense.

On the employer side, data revealed that job postings with too many applications (over 25) frustrated hiring managers almost as much as too few (under 8); the real sweet spot was 8 to 25 qualified applications, directly tying employer churn to application-flow quality, not just raw volume.

On the seeker side, the data showed that a seeker who does not submit at least one application within 48 hours of joining rarely comes back, and only 27 percent of registered seekers were converting in that window, with mobile-app users succeeding at more than double the rate of non-app users, 32 percent versus 15 percent, a real lever hiding inside an existing but under-leveraged product surface.

Action converted these insights into team-level work through the standard top-down and bottom-up negotiation: leaders briefed the whole product organization on strategy and insights together, then approached each team with one or two specific problems while leaving room for a team that felt strongly about a particular problem to pursue it.

Management meant actively resolving friction as it appeared, exactly as Part VI predicted it would: rebalancing an overloaded team, negotiating cross-team dependencies directly ("horse trading" between managers), temporarily embedding a specialist (an SEO person) into a team that needed help outside its own skill set, and adjusting the infrastructure team's re-platforming sequence specifically to avoid the new enterprise team having to build twice.

Product Team Objectives

The finished objectives across all sixteen teams show the negotiation from Chapter 66 landing as real, specific commitments, every one framed as a problem with team-owned key results, not a features list.

Several read as common objectives sharing the same underlying problem from different angles (multiple seeker teams all pushing toward the 48-hour first-application rate, several teams inheriting the enterprise product-market-fit objective from their own piece of the puzzle), and most carried genuinely ambitious targets, moon shots rather than roof shots, because leadership judged that conservative targets simply would not move the needle enough to hit the company-level numbers.

A representative sample: Employer Home aimed to raise employer success from 37 to 39 percent through smarter recommendations at posting time. Job Recommendations aimed to raise seeker success to 25 percent and lift recommendation-driven applications to 5 percent by helping seekers find jobs they did not realize they were qualified for.

The brand-new Enterprise Tools team's entire quarter reduced to one focused key result: eight prospective enterprise customers signing a non-binding letter of intent, a genuine product-market-fit signal rather than a vanity metric. Infrastructure carried a high-integrity commitment, not an aspiration, to migrate four more major system components to the new architecture on schedule.

The pattern worth noticing across all sixteen: every objective ties back, traceably, to one of the two board-level objectives from Chapter 63. Nothing on this list exists because it seemed interesting in isolation.

Business Results

The strategy worked, and the specific numbers show how. The "successful posting" rate (jobs landing in that 8-to-25-application sweet spot) climbed from 37 to 41 percent by quarter's end and kept climbing toward 45 percent by year-end, which translated directly into employer churn falling from 6 to 5.1 percent, with the Job Recommendations team's work the single biggest driver, an effect that kept compounding for over two years afterward.

First-application-within-48-hours jumped from 27 to 42 percent, a dramatic swing from one focused insight acted on by multiple teams at once.

The enterprise objective took genuinely longer than planned, two full quarters instead of one to land six reference customers, because moving from an online-sales motion to direct enterprise sales required far more foundational work (security, access control, billing) than anyone initially estimated, a real example of ambition meeting a harder-than-expected reality without becoming a crisis, because the team had been given a problem and the room to actually discover its true scope.

The two-year re-platforming effort finished on its original schedule and was, notably, celebrated internally once done, tangible proof that paying down technical debt deliberately pays off in real velocity later.

Two platform teams (payments and billing, data and reporting) discovered mid-year that their tech leads were overwhelmed by the business complexity alone and needed dedicated platform PMs added, a real-time correction to the topology, exactly the kind of evolution Chapter 46 described as healthy rather than a sign of initial failure.

Key Takeaways

Ten points the case study makes concrete that the rest of the book made abstract:

• 1. Product leaders stay actively involved at every stage, not just at the strategy-setting moment.
• 2. Results only ever match the quality of the underlying strategy; real focus on a few high-impact insights outperformed an unfocused, reactive list every time.
• 3. Objectives need continuous active management, or daily urgency quietly erodes progress regardless of how good the original plan was.
• 4. Genuine innovation came from teams that were actually excited about the specific problem they had been handed, not from process compliance.
• 5. Leaders explicitly planned for not knowing which bet would pay off, rather than pretending certainty they did not have.
• 6. Managing a real portfolio of bets, mixing confidence levels deliberately, is how that uncertainty gets handled responsibly.
• 7. The topology itself directly shaped which insights could even become action, and a different topology would have produced different results from the same insights.
• 8. Real give-and-take between top-down direction and bottom-up team input is what made the objectives land with genuine motivation behind them.
• 9. Sharing broad strategic context, not just the assigned problem, is what let teams make good calls without constant escalation.
• 10. Trusting teams with genuine uncertainty, rather than demanding false certainty upfront, is what let this specific quarter actually work.

No single company's specifics transfer directly, but the underlying discipline, focus, insight, trust, active management, does.

Leader Profile: Judy Gibbons

Judy Gibbons started at HP in the same era and same company as Cagan himself, learning product management and marketing there before seven years at Apple in product development and technology evangelism, then a decade building and running Microsoft's global consumer internet business, MSN.

She now advises startups and sits on, or chairs, several boards helping companies navigate exactly the transformation this book describes, starting deliberately at the top.

Asked directly why so many companies still default to command-and-control leadership over genuine empowerment, her answer is less about deliberate preference than about limited exposure: for many leaders, command-and-control is not a choice they are actively making, it is simply the only leadership model they have ever personally seen modeled for them.

That reframing matters for anyone trying to drive change from inside such an organization: the resistance you are up against is very often not conviction, it is unfamiliarity. A leader who has never seen empowerment actually work has no real reference point for trusting it, which makes concrete, visible proof, exactly what the Chapter 62 through 69 case study exists to provide, more persuasive than argument alone ever will be.

The Role of Product Leaders

Strong product leadership and genuinely empowered teams are necessary conditions for this whole model to work, but they are not sufficient on their own; how the product organization interacts with the rest of company leadership determines whether any of it survives contact with the wider business.

The shift from "technology serves the business" to "technology collaborates with the business" starts with trust, and that trust has a real prerequisite: product leaders need to sit as genuine peers alongside sales, marketing, finance, and legal leadership, not buried underneath a CIO or CTO in a structure that signals, before a single word is said, that technology is subordinate.

Three things product leaders get judged on

• Business results. Ultimately nothing else earns trust the way real outcomes do; strategy and empowerment either produce them or they do not.
• Product strategy, shared openly. Explaining the actual reasoning behind the work, and crediting executives whose insight contributed to it, builds a sense of shared ownership rather than a black box.
• The product teams themselves, especially the PMs, since executives will judge the whole organization by its weakest visible PM interaction.

That is exactly why onboarding and personal introductions to key executives matter so much: a manager who puts an unprepared PM in front of a senior stakeholder is spending down the entire organization's credibility on one avoidable meeting.

Stakeholder Management vs. Collaboration

"Stakeholder management," the language feature teams default to, already concedes the framing: stakeholders as a client to be managed, satisfied, or placated, with the product team dreading demands it cannot fully meet. "Stakeholder collaboration" replaces that with a genuinely different relationship: stakeholders as partners contributing real expertise, especially around viability, that a good solution cannot actually be found without.

A company lawyer flagging a legal constraint is not a blocker to route around, they are the person who can help find a compliant path to something close to the original idea, if the PM engages them as a partner in discovery instead of just receiving a verdict after the fact. That shift only works when the PM has genuinely done their homework first; a partnership built on one side's ignorance collapses back into the old dynamic almost immediately.

The agency-model parallel from Chapter 17 returns here with the same force: an external agency taking direction from a "client" produces exactly the same disempowerment as an internal feature team taking direction from a stakeholder, literal mercenaries either way.

When someone from an agency background joins an empowered team and says something like "now I get to be the client," that is the clearest possible sign they have missed the entire point and need direct, explicit re-coaching, not a passing correction.

Shared Insights and Learning

Discovery generates real insight constantly, and an organization that keeps those insights trapped inside the team that found them is wasting most of their value. An insight that lands in marketing or customer success can be just as useful there as it was to the product team that generated it, and colleagues in other functions often add a perspective the product team would not have found alone.

One distinction worth actively teaching across the company: the difference between "failing" in discovery (fast, cheap, a prototype getting a bad reaction, exactly what discovery exists to surface early) and failing in the market (slow, expensive, a launched product that does not work). Executives who do not understand that difference tend to read every discovery-stage setback as a real failure, which quietly pushes teams toward hiding bad news instead of surfacing it fast, exactly the opposite of what you want.

Inviting business leaders directly into user-testing sessions, and generously crediting them by name when their own insight genuinely shaped a decision (Cagan's teams have gone as far as printing literal "Deputy Product Manager" badges for this), does more to build lasting trust than any status report could. Insight has to flow in both directions, and get real, visible credit in both directions, or the collaboration stays one-sided no matter what the org chart says about partnership.

Keeping the Lights On

Every team carries a baseline of unglamorous, non-negotiable work: urgent bug fixes, compliance changes driven by new regulation, minor reporting tweaks finance needs, analytics instrumentation. None of it requires much discovery, and the PM is generally the one who triages it onto the backlog as it arrives, mostly sourced from other business functions with a real, legitimate need.

The genuine risk here runs in both directions. If a product team cannot absorb reasonable KLO work, business partners hit real friction trying to do their own jobs, and that friction becomes a trust problem fast. But if KLO capacity grows unchecked, or gets used as a backdoor for a stakeholder's "pet feature" mislabeled as essential maintenance, strategic objectives quietly starve, and the organization drifts back toward being feature-team-shaped without ever officially deciding to.

The practical skill this demands of a PM: gently but firmly reminding a business partner of the actual strategy and the cost of chasing every reasonable-sounding new idea simultaneously, without turning that reminder into a blanket refusal to help. New opportunities business leaders bring are not usually bad ideas in isolation; the problem is always how many of them get pursued at once, at the direct expense of the few things focus was supposed to protect.

Evangelism

Internal evangelism is not selling a product, it is persistently persuading the rest of the company, executives, other teams, sales, marketing, customer service, that the vision and strategy actually matter and deserve their active support, not just passive awareness. It never fully finishes; the moment it stops, confidence and motivation both start drifting sideways.

Ten techniques worth having ready, and varying deliberately

• 1. Show a real prototype, even a rough one, rather than pitching from slides.
• 2. Make the customer's pain concrete, real quotes, real footage, real presence at a user-testing session.
• 3. Share the long-term vision, not just this quarter's work, so people understand where things are actually headed.
• 4. Share learnings openly, including failures, since visible learning velocity is itself persuasive.
• 5. Give credit generously and take blame personally, which builds far more goodwill than either withholding.
• 6. Treat a demo as a form of sales, showing value, not walking through every feature mechanically.
• 7. Do the underlying homework thoroughly enough that people trust your expertise on sight.
• 8. Be genuinely excited, since forced enthusiasm reads as exactly that.
• 9. Actually show that excitement, rather than assuming it is obvious.
• 10. Spend real face time with the people doing the work, not just the people reviewing it.

None of this substitutes for real results, but real results without evangelism still lose momentum, because trust and motivation both decay without regular reinforcement, no matter how strong the underlying numbers are.

Leader Profile: Avid Larizadeh Duggan

Avid Larizadeh Duggan's path through eBay, Google Ventures, and Kobalt Music grounds a leadership philosophy built on three connected pieces: trust and psychological safety, real freedom and autonomy, and a clearly communicated purpose.

On trust, her core claim inverts the usual leadership instinct: a leader's job is not having all the answers, it is building an environment safe enough that the right questions actually get asked out loud, where disagreement is comfortable rather than risky and failure reads as part of iterating toward something better, not as a personal mark against whoever raised the idea.

On autonomy, she argues explicitly against traditional departmental hierarchy in fast-moving digital work: bring strong people together, tell them clearly what needs to happen and why, then genuinely let them decide how, with the leader's actual job reduced to clearing obstacles and clarifying chaos rather than directing execution.

Applying any of this inside an already-established company is measurably harder than inside a startup, she notes directly: legacy technology, real complacency from a long-held market position, and a persistent tendency to overestimate how fast the organization is actually moving all work against it simultaneously.

Acquiring innovative teams does not sidestep this either; an acquisition that is not paired with real transformation in the parent company's own leadership and culture tends to watch the acquired team's innovative edge quietly erode within the old structure, which means organic transformation, hard as it is, usually beats trying to buy your way around doing it.

Meaningful Transformation

Real transformation from a feature-team company to a genuinely empowered one has exactly one non-negotiable prerequisite: senior leadership, starting with the CEO, has to actually understand technology as the core enabler of the business, not a cost to be managed down. Without that belief in place first, nothing that follows will stick.

Three sequential steps, in order

• 1. Get strong product leaders in place first. Without them, nothing else, recruiting, coaching, real strategy, earning other executives' trust, is even possible to build on top of.
• 2. Recruit and develop the staff an empowered team actually needs, usually meaning the bar for product managers has to rise first, sometimes design and engineering too. This does not require upgrading every team simultaneously; it requires that a given team is genuinely ready before it is handed real empowerment.
• 3. Redefine the relationship with the rest of the business, from subservient to genuinely collaborative, which asks business leaders to take a real leap of faith on trusting product teams with more autonomy than they are used to granting.

Here is the counterintuitive part: empowered teams are usually cheaper to run than the feature-team alternative, not more expensive. The waste Cagan sees most often lives in large outsourced "mercenary" engineering contracts, thousands of external engineers on multi-million-dollar deals, that a smaller internal team of real missionaries routinely outperforms, at lower total cost even when each individual is paid more.

The direct challenge worth putting to a skeptical CFO: run the actual comparison, cost and results side by side, in one specific area of the business, rather than assuming the outsourced model is cheaper because the invoice looks smaller.

Transformation in Action

The Guardian's 2007 crisis, collapsing print advertising, digital rivals eating its lunch, forced a genuinely risky strategic bet: stay free online rather than following competitors behind a paywall, on the belief that its journalism needed maximum reach more than it needed near-term subscription revenue, reach first, revenue later, even at the cost of a shorter financial runway.

Jon Moore joined as Head of Mobile as a wave of technologists arrived at a traditional newsroom, creating real friction with veteran editorial staff uncertain what these new colleagues were actually there to do. His first iPhone app, prioritizing intuitive design and offline content access when that was genuinely novel in 2007, earned real Apple showcase placement and proved, concretely, that a newspaper could produce world-class software, not just world-class journalism.

The iPad launch tested the model harder. Given seven weeks and Apple's invitation to be featured at launch, Moore judged the original app's full quality unreplicable in that window and made a deliberate call: build something narrower instead of something worse.

Drawing on existing data showing photography content resonated strongly, his small team (PM, designer, three engineers) thin-sliced to a single daily curated photo experience, "Guardian Eyewitness," prototyped on cardboard and borrowed laptop screens because no real iPad hardware existed yet.

He deliberately kept senior stakeholders out of the earliest work, betting on speed and planning to "seek apology later," then won board approval partly on Judy Gibbons's own endorsement once the prototype could actually be shown. Steve Jobs featured the app at the iPad launch itself, driving millions of downloads and, more importantly, proving something bigger than the app: that the Guardian could lead digitally, not only editorially, a proof point that helped carry the paper toward sustained profitability afterward.

TRANSFORMED

Most transformation efforts fail for a specific, recognizable reason: they focus narrowly on how product gets built (adopting Agile ceremonies, say) rather than broadly on how the company actually delivers value to customers, and they isolate the effort inside a dedicated "digital transformation" group instead of changing the whole organization. This chapter is an excerpt from SVPG partner Lea Hickman's upcoming book, TRANSFORMED, drawing on her own experience including Adobe's transformation.

The single most important predictor of success, ahead of any specific tactic, is whether the executive team is genuinely bought into a real product operating model, not just tolerant of one running somewhere downstream from them.

The deeper shift transformation actually requires is repositioning product itself: from a cost-center slice of the technology or IT organization to the company's primary value driver, which is a change in how the business understands where value comes from, not a change in reporting lines or headcount.

Executives need real fluency in the language of a product operating model to engage with it meaningfully; without that fluency, even a genuinely committed executive cannot actually participate in the conversations that would move things forward.

The honest, hard-to-hear feedback Cagan gave early in Hickman's career, credited here as foundational to Adobe's real transformation, captures the whole chapter's underlying claim: transformation succeeds on the willingness to hear and act on uncomfortable truths about the current state, not on adopting a new framework's vocabulary while leaving the underlying truths unexamined.

The Most Important Thing

If there is a single idea worth taking from the entire book, it is this: the empowered engineer is the single most important ingredient in a genuinely innovative company, echoing Bill Campbell's own words almost exactly.

Engineers sit closer to what is technologically "just now possible" than anyone else in the organization, on a daily basis, which makes them the best available source of real innovation, not merely its executors.

Empowerment for an engineer means something specific and narrower than it sounds: not simply deciding how to code a given solution, and not merely owning architecture decisions either, but being handed the actual problem and its strategic context, then trusted to bring technology to bear on finding the best solution to it, alongside the PM and designer, not downstream of them.

The litmus test worth applying to your own team

If engineers first encounter a product idea at sprint planning, that is the clear signature of a feature team and disempowered engineers, whatever the team calls itself. "My engineers only care about coding" is, almost always, either an overzealous PM keeping engineers out of discovery deliberately or by default, or engineers who have simply never been given real exposure to a customer, not a fixed trait of the people themselves.

A team without at least one true tech lead whose real job includes discovery is not missing a nice-to-have, it is missing a structural requirement for innovation to happen at all, and that gap traces back to an engineering leader's hiring bar, not to individual engineers' preferences.

The Destination

The transformed state this whole book has been building toward, contrasted against where most companies start: technology understood as the core enabler of the business, not a cost line; a real coaching culture where every person has a manager genuinely invested in their potential; hiring managers who personally own recruiting rather than waiting on HR.

An inspiring, shared product vision uniting every team's daily work; a topology deliberately optimized for ownership and autonomy rather than inherited by accident; a focused strategy built on real insight rather than a sprawling wish list.

Team objectives that hand teams problems, with discovery and delivery genuinely in the team's own hands; a relationship with the rest of the business built on mutual respect rather than client-service; and, at the center of all of it, teams genuinely empowered to find their own best solutions and genuinely accountable for the results.

Cagan closes hoping the book gives leaders who never received real coaching themselves a way to raise their own game, and through that, their people's game too; that the next generation of leaders understands what it actually takes to lead the people and the companies they deserve; and, simply, that readers put their talents to use for good.

A transformed company still has to compete, still faces real threats, but it is positioned to do more than merely survive them: to grow by continuously innovating on behalf of the customers it actually serves.

The Entire Book in One Framework

Every part of this book is a link in one causal chain, not a set of independent best practices you can pick and choose from. Trust is built from competence and character, which means staffing has to be deliberate, not passive. Competence gets built through real coaching, an honest assessment, a specific plan, weekly 1:1s, not an annual review.

A coached, trusted team still cannot make good calls without real context: a vision worth believing in, principles that resolve trade-offs, and a strategy that names the few problems that actually matter. None of that lands without a topology that gives a team genuine ownership and autonomy over something real. And none of it turns into results without objectives that hand teams problems, not features, and active, ongoing management that clears what a team cannot clear alone.

Remove any one link and the rest degrades: coaching without staffing discipline just develops the wrong people faster; vision without topology inspires teams that structurally cannot act on it; objectives without active management drift into whatever is urgent this week. Empowerment is not a switch you flip by announcing it, it is the compounding result of every one of these links being real at once.

Empowerment is not the absence of management. It is coaching, staffing, vision, and structure done well enough that a team can be handed a real problem, trusted to solve it, and held to account for whether they did.

10 Most Important Takeaways

• Empowered teams get problems to solve and are judged on outcomes; feature teams get solutions to build and are judged on output. That single distinction determines almost everything else in this book.
• Coaching, not delegating and inspecting, is a manager's highest-leverage job. Run a real assessment, a specific plan, and a genuine weekly 1:1, do not wing it and call it management.
• Hire for competence and character, never "10x talent" or culture fit; a toxic high performer costs a team more than their output ever returns.
• The written narrative, the "six-pager," is the single best tool for developing rigorous thinking and persuading a skeptical room; use it before a big decision, not to justify one after the fact.
• You can validate demand for a product vision, never the eventual solution; share the vision widely and guard the tactical roadmap closely, not the other way around.
• Team topology, how ownership and work actually get divided, is a leadership decision with real consequences. Revisit it deliberately; do not let it happen by accident.
• Product strategy is Focus, then Insights, then Action, then ongoing Management, in that order. Most organizations fail at focus first, long before they fail at insight.
• Key results have to come from the team, never imposed from above; a target handed down from leadership quietly kills the ownership OKRs exist to create.
• Empowerment requires more active management, not less oversight: "you don't need less management, you need better management."
• The empowered engineer, not the empowered PM, is the real center of gravity. If engineers first hear a product idea at sprint planning, the team is not actually empowered, whatever it is called.

Ordinary people build extraordinary products when a company has invested enough in trust, coaching, and context that it no longer needs to control them directly. Empowerment is not a policy you announce, it is the accumulated result of every hiring decision, every coaching conversation, and every problem handed down instead of a feature.