Empowered, by Marty Cagan, with Chris Jones
Empowered, by Marty Cagan, with Chris Jones
My detailed notes on Cagan's perspective on how to run a truly effective product organization.
This latest from Marty Cagan and the Silicon Valley Product Group is destined to be one of the top reads for any product leader seeking to make a difference. Where Inspired focuses on the individual product team, Empowered is aimed at the entire product organization and answers essential questions, like:
How do you coach a product team to success? (Part 2)
How do you make sure you hire the right people into your product teams? (Part 3)
How do you keep them focused on the most important problems to solve? (Parts 6 & 7)
… and so much more in between.
This summary was designed to be a companion to the full book. I’ve omitted the refreshing leadership profiles from the end of each major section, and the details from the case study in Part VIII do a lot to pull together all of the concepts in a clear and concise way.
If you currently (or aspire to) work as a leader within a product organization, do yourself a big favor and make sure you and every other leader has a copy of this full book. Buy it from either Amazon, Bookshop, or wherever you prefer to get your books.
PART I: LESSONS FROM TOP TECH COMPANIES
Chapter 1: Behind Every Great Company
... lies a product culture designed to elicit the greatness that resides in everyone. [Chapters 2-4 capture the three commonalities of these cultures.)
Chapter 2: The Role of Technology
... must be seen to play a critical role in the success of the business and is not seen as only a cost of doing business. Adopting agile is not enough for technology to become the enabler that it truly is (which was communicated clearly within Marc Andreessen's prescient post, "Why Software Is Eating the World). Importantly, the right tech leader is almost never a CIO (head of IT); it must be a CTO.
Chapter 3: Strong Product Leadership
... must be responsible for crafting (and evangelizing) a focused and compelling product strategy and vision. They must carefully design the team topology and actively manage their teams to execute successfully on the vision, strategy, and principles. "If you want to have truly empowered product teams, then your success depends very directly on these first‐level people managers" who are responsible for a) top-down and bottom-up communication; b) making sure product teams have clear objectives; and c) staffing and coaching the teams to deliver results.
Chapter 4: Empowered Product Teams
... are those trusted to deliver on the results and outcomes that matter, in the best way they see fit. Empowered teams are assigned problems to solve, not projects to build (also known as feature teams with the PM acting mainly as project manager).
Chapter 5: Leadership in Action
This book will profile eight product leaders to show these principles in action.
Chapter 6: A Guide to EMPOWERED
"This book is aimed at product leaders and aspiring product leaders." [INSPIRED is likely the more appropriate book for product teams.]
PART II: COACHING
"Coaching is what turns ordinary people into extraordinary product teams." This section addresses how to develop your people.
Chapter 7: The Coaching Mindset
Hone your own mindset first, otherwise you may undermine your effectiveness as a coach.
Take responsibility for helping others get better without taking credit for their accomplishments.
Focus more on the success of your people, than the success of your products. (Your people are not just a means to an end.)
Understand and mitigate your own insecurities or risk undermining your team.
See your team as a "portfolio of strengths and [different] backgrounds."
Seek out teaching moments where you can help people stretch beyond their comfort zone.
Have the courage to correct mistakes or fire people if needed.
Don’t shy away from the details, and continually earn the trust of your team.
Chapter 8: The Assessment
Periodically conduct a gap assessment to find where to focus your coaching efforts. Understand the difference between your expectation for their role and relative seniority (on a scale of 1-10) and someone’s current performance across the main factors relevant to product, process, and people skills. The factors include:
Product Knowledge: table stakes factors specific to the problem you’re solving.
User and customer knowledge — Are they an acknowledged expert on their target users/customers?
Data knowledge — Have they mastered: a) user analytics (how people actually use the product); b) sales cycle information (sales analytics); and c) how data is changing over time (data warehouse analytics)?
Industry and domain knowledge —Do they understand relevant industry trends and the competitive landscape? (Tip: analyze the top 3-5 competitors, identifying opportunities.)
Business and company knowledge — Do they clearly understand all relevant dimensions of the company's business? (Tip: iterate through a business model canvas until it’s correct.)
Product operational knowledge — Could they provide a masterful demo of the product (and answer technical questions) at a moment's notice?
Process Skills and Techniques: transferable skills to be honed over time.
Product discovery techniques — Do they have a bias toward outcomes and a strong understanding of how to seek out and address the four classes of product risk (value, usability, feasibility, viability)?
Product optimization techniques — Do they know how to rapidly improve and refine a product that is live and in production? (Tip: master A/B testing techniques.)
Product delivery techniques — Do they understand their responsibilities to engineering and product marketing for the purpose of delivering the solutions to production?
Product development process — Do they know the overall product development process and understand common techniques (Scrum, Kanban, XP, etc.)?
People Skills and Responsibilities: Amplifiers to effectiveness, also to be honed over time.
Team collaboration skills — Do they work collaboratively and leverage the skills and minds of each team member? (Tip: have the manager sit in on a team meeting to find coaching opportunities.)
Stakeholder collaboration skills — Are they good at establishing mutual respect and trust with stakeholders? Do they leverage the skills of others effectively?
Evangelism skills — Are they great at getting others engaged and motivated about the product vision and strategy?
Leadership skills — Are they great at influencing and inspiring others? Do others look to them in stressful situations?
Chapter 9: The Coaching Plan
Use the results of your gap assessment to guide the plans for them to improve. Bonus: "Every single minute you invest in coaching a tech lead on either customers or business context will be among the best possible uses of your time."
Chapter 10: The One-on-One
... is the foundation of good coaching. Advice: a) focus on helping your report think like a strong product person (don't just discuss status updates, find ways to improve how they work); b) minimum 30 minutes once a week (don't skip); c) provide your holistic "connect the dots" point of view; d) expect them to "do their homework" and come prepared; e) provide honest, constructive, and timely feedback (a.k.a. radical candor). The most common anti-patterns are when the manager a) doesn't care; b) reverts to micromanaging; c) talks more than listens; or d) avoids giving difficult feedback.
Chapter 11: The Written Narrative
... is the most reliable way to force clear thinking and become an exceptional product person. Narratives should be persuasive pieces, explaining an argument and recommendation and not a spec describing the details of what you might build. The aim should be for people who read it to be inspired and convinced. This is the secret behind Amazon's success; it takes discipline to fully embrace this approach. As a manager, you can be a forcing function to develop that discipline within your team.
Chapter 12: Strategic Context
... must be provided by the manager so their teams can make effective decisions. [See image]. This includes: a) company mission (the purpose of the company); b) company scorecard (the KPIs that tell us how the business is performing overall); c) company objectives (the outcomes we are seeking to accomplish over the next year, with the corresponding key results); d) product vision and principles (see Part IV); e) team topology (see Part V); and f) product strategy (see Part VI).
Chapter 13: Sense of Ownership
... is important to cultivate in your empowered PMs. Someone who thinks like an owner "feels a real obligation and responsibility to their customers, product team, stakeholders, and company investors." This motivates us to do our homework, share strategic context for our recommendations, focus on outcomes, commit to getting beyond any obstacles, and build the relationships that matter to protect and grow the value we've worked so hard to create. (It also helps to reward people with equity - actual ownership - where they have legitimate long-term incentives and feel like they'd be "leaving behind substantial compensation if they exit before they are fully vested.")
Chapter 14: Managing Time
Aim for empowered PMs to spend 4 hours per day on product discovery. This ensures what the team is working on is worth building, and that everyone is collaborating to address the four areas of risk (that the product will be valuable, usable, feasible, and viable). Coach them to handle or delegate other responsibilities accordingly to maintain the discovery time critical for delivering results.
Chapter 15: Thinking
Use the 1:1 and written narratives to help your PMs develop the quality thinking necessary to reach their full potential. Many people are intelligent yet "waste their minds because they don't know how to (or are unwilling to) actually solve hard problems by thinking." This means applying knowledge in service of problem solving, not just acquiring knowledge. (Designers and engineers tend to be good problem solvers because their disciplines require it.) Expect them to do their homework.
Chapter 16: Team Collaboration
... around solving problems is one of the pillars of strong product teams (along with tackling risks early and being accountable to results). Collaboration is: a) not consensus (we rely on the expertise of each team member); b) not about artifacts (they sometimes get in the way of collaboration, especially when "requirements" are shared prematurely); and c) not about compromise (which leads to mediocre products). Prototypes & story maps are two kinds of artifacts that facilitate true collaboration, which is about solving for the risks and challenges we face. Failure modes: a) when the PM hasn't done their homework; or b) when members are arrogant and believe their solution is right.
Chapter 17: Stakeholder Collaboration
... is not to "gather requirements" but rather as a partnership to ensure what you build will meet the needs of each part of the business. It is critical for the PM to have done their homework, especially with executives who care deeply about everything. An empowered PM will build trust before they need it, particularly with the 3-5 people most important to their product having a successful outcome, and the 1-2 people they most dread having to deal with.
Chapter 18: Imposter Syndrome
... should be harnessed productively as motivation to do your homework (thinking, rehearsing, seeking feedback) so you are actually prepared. Managers must place sufficient expectations of excellence that their people feel a need to deliver excellent work. Remember: "A manager or product leader is only as strong as their weakest employee."
Chapter 19: Customer-Centricity
... is often given lip-service, but is truly reflected in how you "handle a situation such as an outage, or when a product change causes customer confusion or frustration, or the infrequency that [you] actually sit down with real users and customers." Be specific and protective over who you call your "customer" so its meaning isn't diluted. Aim for at least three one-hour long customer interactions each week. (Ask your empowered PMs about these interactions during the weekly 1:1). Act with a sense of urgency around any commitment made to customers or bugs a customer may be experiencing.
Chapter 20: Integrity
... is the cornerstone of earning and maintaining trust required to remain an empowered product team. Keep your integrity intact by focusing on: a) dependability (following through on commitments to others); b) consistently acting in the company's (and not the team’s) best interests; and c) accountability for results and willingness to take responsibility for mistakes. [Example: when it takes the engineers longer than expected to deliver something, ask whether the PM fully appreciated the feasibility risk, elicited and/or listened to engineers’ concerns, or argued for a feasibility prototype during discovery.]
Chapter 21: Decisions
... are best when founded on integrity and aligned with the desired outcomes. Useful behaviors: a) calibrate information gathering to the level of risk and related level of consequence of a mistake; b) depend on (and usually defer to) the expertise of your team in decisions relating to their field; c) resolve disagreements through tests which collect evidence (if possible); and d) make sure your rationale is transparent. Ultimately, make sure each is willing to disagree and commit without undermining the team). Some quotes:
"Good decisions, especially in risky, consequential situations, begin by creating a plan of attack."
"It's normal for a novice product manager to either seriously underestimate or overestimate risk. She ends up spending too much time in discovery on items that don't really matter, and then doesn't have time for the risks that do."
[Three rules of decisions, from Jim Barksdale, former CEO of Netscape, where a “snake” refers to an important decision that has to be made.] 1) If you see a snake, kill it. 2) Don't play with dead snakes. 3) All opportunities start out looking like snakes.
Chapter 22: Effective Meetings
... are the ones that absolutely cannot be resolved with asynchronous communication. They have a clear purpose, whether to communicate something vital (make sure you're clear on the content), make a decision (bring a non-draft written narrative), or to solve a difficult problem where we don't know the best course of action (make sure you can explain the situation or context). Limit attendees to only the individuals for whom you'd postpone the meeting if they had a last minute conflict. Facilitate the meeting toward your desired conclusion, and follow-up after to close the loop.
Chapter 23: Ethics
... are related to business viability, but can be seen as their own class of risk. There is rarely a stakeholder responsible for ethics, and it usually doesn't get the attention it deserves. Consider strongly, "Should we build it?" Red flags: a) if the product would have a negative impact on the environment, community, or end-users in some way; or b) if you'd be embarrassed if the internal documents about the product were to leak to the press. [Further reading: Intentional Integrity: How Smart Companies Can Lead an Ethical Revolution, by Rob Chesnut.]
Chapter 24: Happiness
... within work is different for everyone, and important to consider as you coach your team. Some near-universal truths of what leads to happiness: a) knowing your work is meaningful; b) having a personal relationship with your manager; c) receiving personal recognition (not necessarily public recognition; instead, you could send them a nice gift); d) avoiding burnout through sustainable work habits (ideally the manager will model good habits); and e) support with career planning (even if that means leaving product management). [Further reading: Trillion Dollar Coach: The Leadership Playbook of Silicon Valley's Legendary Bill Campbell, by Eric Schmidt, Jonathan Rosenberg, and Alan Eagle.]
Chapter 25: Leader Profile: Lisa Kavanaugh
[Omitted from this summary; provides a fresh perspective as a recap on this section.]
PART III: STAFFING
This section addresses how to find your people. It's a misconception to assume you need to hire exceptional people from the outset. "The best product companies hire competent people of character, and then coach and develop them into members of extraordinary teams." Staffing is far more than just hiring, and must be the responsibility of the hiring manager. Skill here is critical for success.
Chapter 26: Competence and Character
... are the two qualities you should hire for. Beware of "culture fit" which typically leads you to hire people who resemble you. Competence is table stakes; the hiring manager must be accomplished enough with their job to be able to both assess for and then coach someone to competence (especially when hiring based on potential). For character, one approach is to keep the field wide and weed out the assholes; this increases your chance of finding someone who thinks differently from you. As Stephen Covey explains: "Trust is a function of two things: competence and character. Competence includes your capabilities, your skills, and your track record. Character includes your integrity, your motive, and your intent with people. Both are vital."
Chapter 27: Recruiting
Strong managers identify what they want for any open role and then go out and recruit the talent. Plan to spend up to 50% of your time recruiting when you have an open role; your goal is to craft your product team with people of different backgrounds. Make this a proactive and consistent activity, and plan to build relationships with promising talent over time. When you care about developing people, it will compound over time as promising people are referred to you, building a healthy network and funnel of strong candidates. Be creative, and don’t outsource this talent, keep it in house.
Chapter 28: Interviewing
The hiring manager "must take responsibility for the interview effectiveness of the interview team, and the interview experience for the candidate." Every (non-junior) hire should raise the average. Makes sure the team shares any unresolved questions with each other so that all can be addressed by the end of the interview day. (If it's clear the candidate is not a good fit, feel free to end the day earlier). Communicate to the interview team if you're willing to hire for potential; if you are, then make sure you're "personally [willing to] commit to invest the necessary time and energy to coach that person to competence." Hire for skills more than domain knowledge (the latter is easier to acquire). [Further reading: Who: The A Method for Hiring by Geoff Smart and Randy Street.]
Bonus: Cagan’s favorite interview question is to have the candidate stack rank themselves across the following four attributes, and discuss their answer (each quoted):
Execution — how well do you get things done, do the right thing without being asked, and track lots of simultaneous targets?
Creativity — how often are you the person in the room with the most or the best ideas?
Strategy — how well do you get up above what you're working on and put it into a broader market or vision context and then make this clear to others?
Growth — how good are you at figuring out ways to multiply effort through smart use of process, team management, and so on?
Chapter 29: Hiring
Be decisive; move quickly to produce an offer to a strong candidate. Do the reference checks yourself, and ask if they'd hire the person again (especially to reveal whether the candidate has exhibited toxic behavior in the past, which can be hidden during interviews). Along with the offer, communicate your willingness to coach them to reach their potential. If especially good, have the CEO or another leader reach out to offer to talk.
Chapter 30: Remote Employees
It's hard to deny the value of the product team being co-located. Bezos: "Creativity comes from people's interactions; inspiration comes from intensive concentration. Just like a start‐up, the team huddles together in a garage, experimenting, iterating, discussing, debating, trying and retrying, again and again." This is particularly true for discovery. When remote, watch out for three problems that get in the way of innovation: a) emphasis on producing artifacts for each other instead of talking about how to solve the latest problem (focus instead on prototypes); b) challenges establishing and maintaining psychological safety when normal filters fade without social cues to work off of; and c) difficulties for some to find blocks of uninterrupted quality time when working from home, with interruptions from kids or other situations (try to be flexible, acknowledge and coach around the risks).
Chapter 31: Onboarding
For any new hire to be successful, you must invest in their first three months. Everyone, no matter how experienced, will need time to get up to speed. Useful checkpoints: a) end of first day (they know what is expected & have met a future friend); b) end of first week (they're getting to know the team members personally); c) end of first month (they've assessed the company and their potential within it); and d) end of first 60 days (they've scored a public "win"). More tips:
People often reassess their decision after receiving their first paycheck. (Useful checkpoint).
Figure out how open they are to being coached. Some interpret this as an indication of being deficient or at risk. Build trust and work through it.
Focus on establishing competence and building relationships (see earlier chapters), especially meeting with customers.
Check-in regularly with the key leaders they'll work with "to track how their experiences with the new employee are going, and [know about] any areas they'd like to see further developed."
Note on APM (Associate Product Manager) programs: the most successful of these (at Google, etc.) involve recruiting high potential individuals and then coaching them intensively for 2 years to develop the skills needed to be successful. Don't confuse this with 'entry-level, junior product manager.' "You can only do this program if you have very strong and proven product leaders who are both willing and able to spend intense time coaching;"
Chapter 32: New Employee Bootcamp
... can be a really effective method to get new product people quickly up to speed. This goes beyond basic orientation and gives them what they need to be successful. Every day has a) personal growth (career planning, communication exercises, personality tests); b) strategic context (understanding the customer in light of the company vision); and c) a hands-on workshop with your team to work through an issue. Dive into details, and involve other product team members to share relevant stories (which also show how things get done in your company). 5 days of this gives a new PM a lot of context.
Chapter 33: Performance Reviews
... are not a primary feedback tool. That's the purpose of the 1:1. Whenever an employee is surprised by a performance review, it should be treated as a performance problem of the manager, not the employee. Make sure any negative feedback is unmistakably clear to the employee. (No opportunities for the employee to not "take the hint.")
Chapter 34: Terminating
When you know someone is not working out (hopefully after extensive coaching and timely feedback), act responsibly and promptly, in consideration of the rest of the product team who are carrying the burden. The skill of handling terminations is "truly essential if you're serious about creating a strong product organization." Usually someone fails to perform within the first 3-6 months of being hired (despite serious coaching and clearly communicating the lack of progress with increasing urgency during weekly 1:1s). This reflects a mistake of the hiring manager to accurately judge their ability to perform the job, and it’s reasonable to help the person find a new job. When the individual is damaging relationships due to being toxic, then it's okay to just fire them.
Chapter 35: Promoting
... "begins with understanding the career aspirations of your employees." This can either be within their job class (up the various stages of IC or management track) or across job classes (from IC to manager, or vice versa). The more skilled a person becomes, the more valuable they are to the company (which is why it absolutely makes sense to advocate for a promotion after they demonstrate they are qualified for the new role). Remember: "if the people you really don't want to lose are consistently leaving, this is a real sign of a potential problem in management."
Chapter 36: Leader Profile: April Underwood
[Omitted from this summary; provides a fresh perspective as a recap on this section.]
PART IV: PRODUCT VISION AND PRINCIPLES
This section addresses how to craft the highest leverage product artifact - the product vision. Importantly, the vision must be a persuasive artifact, not to be confused with a specification. [This will address the vision from the point of view of the whole company; the book Inspired addresses the product vision as it relates to the individual product team.]
Chapter 37: Creating a Compelling Vision
… is the responsibility of the head of product, closely collaborating with the head of design, head of technology, and the CEO or head of the business unit. A strong and compelling product vision:
Focuses everyone on creating compelling value for the customer, not just on delivering business objectives.
Provides a north star for the product organization so everyone knows how their work contributes to the whole, including technical architecture decisions.
Describes "the future you are trying to create" without being a list of features. Desired time frame is 3-10 years out, depending on the complexity of your product.
Leverages (important) industry trends, typically enabled by new technology (e.g. mobile, cloud computing, machine learning, edge computing, consumerization of the enterprise).
Most important: a vision promises something great. After that, "our job as the broader product organization then is to figure out how to deliver on the promise of the vision. This requires an intentional product strategy, and years of continuous discovery and delivery."
Chapter 38: Sharing the Product Vision
... requires real time and effort to do well. At minimum, create a visiontype - a high-fidelity conceptual prototype not constrained by what we know how to build - to communicate the vision of compelling customer value. (Create a storyboard and consider the emotional dimension of how people will respond to what you share.) When presenting to others, focus on validating the demand for the vision rather than the specific solutions you present within it. It's also useful as a) a recruitment tool; b) a fundraising tool; and c) a way to guide alignment with engineering regarding product architecture. Be careful about the vision being interpreted as a "high integrity commitment" roadmap with customers.
Chapter 39: Product Principles and Ethics
... are designed to complement the product vision by guiding future product decisions or tradeoffs which will need to be made. [Example: prioritizing ease of use versus security when the two are at odds.] Principles are often cited by product teams as "the part of the strategic context that they use most often in their daily discovery work."
Chapter 40: Leader Profile: Audrey Crane
[Omitted from this summary; provides a fresh perspective as a recap on this section.]
PART V: TEAM TOPOLOGY
This section addresses how to structure your product teams to divide up the work. This informs your staffing & coaching decisions for each of the teams. [Further reading: Team Topologies: Organizing Business and Technology Teams for Fast Flow, by Matthew Skelton and Manuel Pais.]
Chapter 41: Optimizing for Empowerment
... is the most important factor to consider. Balancing three goals: a) ownership (each team is responsible for some meaningful, motivating, and appropriately sized part of the whole); b) autonomy (each team can operate with minimal, not nonexistent, dependencies on other teams); and c) alignment (each team is contributing toward the same north star). Some tips:
Avoid the common failure mode of letting the teams develop organically via the path of least resistance instead of thoughtful design.
Empowerment is undermined when a) scope is too broad (complexity makes innovation difficult); or b) ownership is unclear (your topology "should resolve more ownership questions than it raises").
Don't worry about having reporting relationships aligned with team topology; that's an unnecessary (and often risky) constraint.
Chapter 42: Team Types
... have two fundamental flavors:
Platform teams create leverage (for other teams) by building and maintaining shared services, especially those which "encapsulate particularly difficult or specialized areas of the product."
Experience teams are responsible for how customers experience the product (via apps, UIs, etc.)
Chapter 43: Empowering Platform Teams
... happens when they’re encouraged to go beyond "keep the lights on" work. Options include: a) pairing their goals with an experience team (so they work closely to achieve the goal); or b) building out their platform as a product, whether open to external developers or just for their internal teams.
Chapter 44: Empowering Experience Teams
... happens when they’re given as much responsibility for the end-to-end customer experience as possible. Within larger teams accomplish this by "creating a topology that is aligned by customer" (e.g. by user type or persona, market segment, customer journey, sales channel, business KPI, or geography). [Given the core competency of a PM is understanding the customer, it is logical for PMs to differentiate based on differences within customers.] It’s best when designers are embedded in these teams.
Chapter 45: Topology and Proximity
Being remote requires extra work to sustain clear and effective communication [see also Chapter 30]. General rule: optimize for the product team to be successful above other considerations, and mitigate the disadvantages you face. Consider the relative proximity of: a) team members (co-location supports the intense collaboration needed for innovative product discovery, not all teams require this); b) customers (hard to support customers in India without being close); c) business partners; d) managers (harder to coach people when they're not local); e) other product teams; or f) senior executives. Recognize the additional costs of working at a distance (in communication, travel, proactively reaching out for information, checking-in, etc.).
Chapter 46: Topology Evolution
Anticipate your team topology to change over time. Don’t change the topology too frequently (red flag if it changes more than once per year), and when you do, try to keep product teams intact so they can keep their relationships. Signs you may need to review your topology: developers frequently moving between teams; high incidence of dependencies resulting in delay or conflict; teams having limited scope of ownership and/or low motivation; sunsetting a major product; pursuing a major refactor of the architecture. "Topology determines who people work with on a daily basis, what they are working on, and the nature of your interactions. When it changes, it can be extremely disruptive."
Chapter 47 Leader Profile: Debby Meredith
[Omitted from this summary; provides a fresh perspective as a recap on this section.]
PART VI: PRODUCT STRATEGY
This section addresses how to select the most important problems to solve in order to "make the product vision a reality while meeting the needs of the company as we go." While this is critical to reduce the risk of wasted effort, most product organizations avoid the hard work of crafting a good strategy, usually because they are unwilling or unable to choose between competing alternatives. Red flag: having goals and tactics articulated, but no strategy to tie them together coherently. [Further reading: Good Strategy/Bad Strategy by Richard Rumelt.]
Chapter 48: Focus
Pick the few things (as in, only 2-3) that can truly make an impact. Feature teams get stuck prioritizing between different features but not focusing on the most important problems to solve. [E.g. it is easy to come up with ideas to improve the codebase, but most of those improvements will never matter. The goal is to give concentrated attention to the few areas that could matter.] Minimize work in progress (WIP), otherwise throughput suffers and items are left half-finished.
Chapter 49: Insights
Develop a strong foundation of insights to support your strategy. This requires hard work and preparation. Find ways to collect learnings from across the team (e.g. via 1:1s), dig for transformative insights, and leverage what you learn into meaningful action. Tip: have the head of product aggregate, summarize, and share the most important learnings from the different teams with the broader organization. Focus on each of the different types:
Quantitative Insights … come from observing how customers use your product, and may include A/B tests for specific hypotheses. The trick is to know enough to be able to identify when you learn something truly important from your product data.
Qualitative Insights ... are either a) evaluative (of some specific product idea, which most product discovery is focused on); or b) generative (of new opportunities we didn't know about)
Technology Insights ... are when new technologies "allow us to solve long-standing problems in new, just-now-possible ways." Empower your engineers to build prototypes and learn new technologies quickly if they are important to your success.
Industry Insights ... encompass what you can learn from competitors, major industry trends, adjacent industries, and similar markets in other regions of the world. Don’t be blind.
Chapter 50: Actions
Take action (on your chosen focus and insights) by giving your team problems to solve instead of features to build, with “as many degrees of freedom in coming up with an effective solution as possible.” [See Part VII: Team Objectives.]
Chapter 51: Management
Actively help your teams resolve obstacles, dependencies, barriers, and important customer issues which arise and risk slowing their progress on their objectives. Leverage 1:1s to identify these issues proactively (though coach them to not wait for the 1:1). The key is better management, not less management: focus on removing impediments, NOT taking control and telling teams what to do. You cannot "just leave the teams alone and hope for the best."
Chapter 52: Leader Profile: Shan-Lyn Ma
[Omitted from this summary; provides a fresh perspective as a recap on this section.]
PART VII: TEAM OBJECTIVES
This section addresses how to set team-level OKRs. The OKR approach (objectives & key results) is valuable only as a complement to empowered product teams. When the OKR approach fails, it is typically because: a) teams are being given a list of features to build rather than problems to solve; or b) leadership is missing in action and not helping teams tie their OKRs together into a coherent whole. OKRs should be set only at the appropriate levels:
Company level: great for strategic context.
Manager / Functional team level: avoid! Creates conflicts within cross-functional teams when cascaded down
Team level: great for empowerment and effective collaboration.
Individual level: avoid! Creates unnecessary complexity and dilution of focus.
Chapter 53: Empowerment
OKRs must be written such that the product team has room "to come up with solutions to hard and important problems." Make sure the accountable team plays a role in setting the KRs in particular so they feel ownership. [See the appendix for examples of well-framed OKRs.] Some tips:
Don't fret over the wording of the objective, just make sure there are many potential solutions.
The most important objectives will likely require collaboration across teams (don’t focus too hard on teams being fully autonomous).
Avoid listing activities or deliverables as key results. Use business results instead, with one or more guardrail or backstop key results "to ensure the primary key result is not inadvertently achieved by hurting something else."
"The higher‐order point here is that the best team objective will come from a back‐and‐forth dialog between the leader and the team. As teams investigate and consider, they often find new and better approaches that may suggest different key results, or even a modified objective. Moreover, it's the leader's job to ensure that this back and forth is happening."
Chapter 54: Assignment
Leadership is responsible for assigning objectives (problems to solve) and ensuring alignment with the rest of the organization, otherwise it leads to lack of direction. Teams should be responsible for setting their own key results, otherwise it leads to a lack of ownership. Further tips:
Expect back & forth negotiation between teams and leadership during assignment.
Teams may need to first gather context before committing to their key results. Encourage them to jump in to establish a baseline and not get stuck spinning their wheels.
Remember that teams are not only responsible for their objectives; each has keep-the-lights-on work to "fix critical problems, respond to customer issues," etc. This cannot be ignored, and must be managed so it doesn't overwhelm the team.
Objectives can be long term. Key results should be relevant only for their time period, even if only a leading indicator of meaningful progress (e.g. getting customers to sign a non-binding letter of intent to buy).
Chapter 55: Ambition
Leaders must clarify how ambitious or conservative teams should be prior to setting appropriate key results. Consider all teams as a risk-balanced portfolio of bets. Something truly important (like an unsustainably high churn rate) may benefit from having some teams pursue low-risk quick-wins (roof shots) while others pursue more ambitious but higher-risk approaches (moon shots).
Chapter 56: Commitments
We must sometimes make high integrity commitments, which are distinct from aspirational objectives or bets. When necessary, teams must be able to provide "dates the leaders can count on," though too many date-driven commitments is a bad sign (and risks your OKRs becoming a list of deliverables). Tips:
Any commitment should have a thorough risk assessment ahead of time.
Track the committed deliverable independently of the key results.
Tip: consider having the CTO "personally agree to each high‐integrity commitment because it is her reputation on the line."
Chapter 57: Collaboration
Even with organizations optimized for autonomy and empowerment, we still have a) shared team objectives (especially when one team has a dependency on another to achieve an objective); and b) common objectives (when multiple teams are asked to pursue the same problem, each in their own way). Some tips:
Opportunity Solution Trees (see Continuous Discovery Habits, by Teresa Torres) are a good way to manage approaches to common objectives.
"Companies that avoid shared or common objectives in the name of autonomy or communication often limit their ability to solve the toughest and most important problems."
Chapter 58: Management
Product teams must track and manage their progress on their objectives at least weekly, in balance with the keep-the-lights-on work. Issues, challenges, and dependencies must be identified and addressed proactively (and managers must seek to identify the coaching each member needs to succeed on their objective-related work). Cultivate a culture where teams help each other.
Chapter 59: Accountability
... is an important companion to empowerment, and must be tied to the level of ambition expected. Treat failures similar to an outage: use a post-mortem to discuss "the root cause of their failure [and to] explore what they believe they could - and should - have done differently." Managers must also reflect on what actions they could have taken to have enabled success. When accountability is difficult (due to unclear product attribution), use A/B tests or slicing (focused on specific channels) if possible.
Chapter 60: Objectives in Perspective
[Summary of Part VII.] Having team objectives to change during the quarter should be an exception.
Bottom line: "Product teams can only be accountable to the results if they are empowered to figure out a solution that works and if they are the ones to come up with the key results."
Chapter 61: Leader Profile: Christina Wodtke
[Omitted from this summary; provides a fresh perspective as a recap on this section.]
PART VIII: CASE STUDY
[This section provides a detailed example of a jobs marketplace company at a particular moment in time. Particular detail is given to the team topology, product strategy, and team objectives. This is useful only in context of the full detail, so I will provide a brief overview only.]
Chapter 62: Company Backgrounder
[Useful context; the company is a marketplace serving SMB employers and job seekers.]
Chapter 63: Company Objectives
[Two company-level objectives: 1) grow and improve the core business; and b) begin pursuing large enterprises.]
Chapter 64: Product Vision and Principles
[Committed to helping job seekers find the best job for their capabilities. They consistently decided in the long-term interest of job seekers over the short-term interest of the company.]
Chapter 65: Team Topology
[The book goes into detail on the mandate of each of the company’s 16 product teams. It is surprisingly useful to know how another company does this, in detail.]
Chapter 66: Product Strategy
[Detailed examination of the insights which informed their product strategy, their collaborative approach to assigning objectives, and some example obstacles which required active management.]
Chapter 67: Product Team Objectives
[Excellent collection of thoughtful product-team level objectives and key results, with meaningful linked business metrics. The book provides the full OKRs for each of the 16 product teams.]
Chapter 68: Business Results
[Summary of challenges faced and what they learned; too specific to be relevant here.]
Chapter 69: Key Takeaways
[The book provides 10 main takeaways; most restate earlier points of the book] New tips:
Anticipate not knowing in advance which ideas will or will not bear fruit. Spread your bets.
A different team topology would have led to a different strategy and different outcomes. (Hard to say whether it would have been better, worse, or the same.)
Chapter 70: Leader Profile: Judy Gibbons
[Omitted from this summary; provides a fresh perspective as a recap on this section.]
PART IX: BUSINESS COLLABORATION
This section addresses how product leaders can cultivate healthy collaboration between their empowered product teams and the broader organization.
Chapter 71: The Role of Product Leaders
... is first and foremost to establish and maintain trust between the product leaders and the other leaders of the business. This requires a “strong head of product who inspires confidence and is trusted” to ensure solutions will work for various aspects of the business. Ultimately, product leaders are judged on: a) business results; b) product strategy; and c) their product teams’ ability to solve hard problems and really understand their respective part of the business. It’s important that the head of product is the peer of other executives.
Chapter 72: Stakeholder Management vs. Collaboration
With empowered teams, stakeholders are collaborators who help provide insights, particularly around viability risk and the relevant constraints of the business. This is a different mindset from feature teams, where stakeholders are people who need to be managed.
Chapter 73: Shared Insights and Learning
Insights learned through discovery must be shared with other business leaders because: a) the insights may be useful to their own work; b) they may provide additional insights while interpreting the information from their perspective; and c) they may help product teams figure out how to leverage the insights. Make sure the broader company can appreciate the "difference between a prototype getting a bad response during discovery [which isn't failing, it's learning] and a product failing in the market." Insights must be "acknowledged and shared in both directions."
Chapter 74: Keeping the Lights On
This work often originates as requests from business partners, and must be considered holistically, in light of the broader objectives, the underlying intent of the ask, the product strategy, etc. Product leaders must continuously evangelize the product strategy and the importance of focus.
Chapter 75: Evangelism
... is one of the most critical responsibilities of strong product leaders, and never really stops. Top techniques include: a) using prototypes (high fidelity is the best persuasive tool); b) making the customer pain resonate with others; c) mastering the demo as a form of sales; d) and actually showing excitement and enthusiasm (stay close so they can see and experience your enthusiasm).
Chapter 76: Leader Profile: Avid Larizadeh Duggan
[Omitted from this summary; provides a fresh perspective as a recap on this section.]
PART X: INSPIRED, EMPOWERED, AND TRANSFORMED
This section wraps up the main ideas of the book.
Chapter 77: Meaningful Transformation
Transforming to empowered product teams requires: a) understanding the role of technology; b) finding strong product leaders; c) enabling them to staff empowered product teams; and d) redefining the product teams' relationship with the business.
Chapter 78: Transformation in Action
[Story of the Guardian and how they transformed from a newspaper into a digital organization.]
Chapter 79: TRANSFORMED
[Section from Lea Hickman, author of the upcoming book, TRANSFORMED , to tackle the topic of digital transformation.] A successful digital transformation requires: a) thinking differently about product (not as an IT expense but as the primary value driver of the organization); and b) the entire executive team on board regarding its importance. [For more, look for the upcoming book.]
Chapter 80: The Most Important Thing
... is ultimately to cultivate empowered engineers on your product teams. They are closest to the enabling technology and are the best single source of innovation. Everything the product team does is geared toward attracting (with the product vision), focusing (with the product strategy), informing (with shared insights, designs, and relevant constraints), and generally unleashing the creative potential of software engineering. You would never outsource your CEO, so don't outsource your engineers.
Chapter 81: The Destination
[Summary of the main sections framed as the end state of mastering each of the sections.] "The state I'm describing here is still not easy—you will always have strong competitors that covet your customers—but now you are equipped to not just fight back, but to grow and thrive by continuously innovating on behalf of your customers."
APPENDIX: Example Well-Framed OKRs
Examples of well-framed objectives (quoted from Chapter 53):
Increase the percentage of shipments delivered with next‐day delivery
Reduce the percentage of images flagged as inappropriate
Reduce the subscriber churn rate
Demonstrate product/market fit for an existing product in a new market
Decrease the time it takes a job seeker to find a new job
Reduce the operational costs of fulfillment
Reduce the cost to acquire a new customer
Increase the lifetime value of the customer
Reduce the percentage of customers that require customer service assistance
Reduce the average time spent handling a customer service call
Example Key Results (for the objective, "Reduce the frequency of parcels delivered to the wrong address" ...
Reduce percentage of incorrect deliveries (primary)
While ensuring that total deliveries continue to grow (guardrail)
While ensuring the cost of delivery does not grow (guardrail)