21,99 €
Mehr erfahren.
- Herausgeber: John Wiley & Sons
- Kategorie: Fachliteratur
- Serie: Silicon Valley Product Group
- Sprache: Englisch
What is it about the top tech product companies such as Amazon, Apple, Google, Netflix and Tesla that enables their record of consistent innovation?
Most people think it’s because these companies are somehow able to find and attract a level of talent that makes this innovation possible. But the real advantage these companies have is not so much who they hire, but rather how they enable their people to work together to solve hard problems and create extraordinary products.
As legendary Silicon Valley coach--and coach to the founders of several of today’s leading tech companies--Bill Campbell said, “Leadership is about recognizing that there's a greatness in everyone, and your job is to create an environment where that greatness can emerge.”
The goal of EMPOWERED is to provide you, as a leader of product management, product design, or engineering, with everything you’ll need to create just such an environment.
As partners at The Silicon Valley Product Group, Marty Cagan and Chris Jones have long worked to reveal the best practices of the most consistently innovative companies in the world. A natural companion to the bestseller INSPIRED, EMPOWERED tackles head-on the reason why most companies fail to truly leverage the potential of their people to innovate: product leadership.
The book covers:
- what it means to be an empowered product team, and how this is different from the “feature teams” used by most companies to build technology products
- recruiting and coaching the members of product teams, first to competence, and then to reach their potential
- creating an inspiring product vision along with an insights-driven product strategy
- translating that strategy into action by empowering teams with specific objectives—problems to solve—rather than features to build
- redefining the relationship of the product teams to the rest of the company
- detailing the changes necessary to effectively and successfully transform your organization to truly empowered product teams
EMPOWERED puts decades of lessons learned from the best leaders of the top technology companies in your hand as a guide. It shows you how to become the leader your team and company needs to not only survive but thrive.
Das E-Book können Sie in Legimi-Apps oder einer beliebigen App lesen, die das folgende Format unterstützen:
Seitenzahl: 537
Veröffentlichungsjahr: 2020
Ähnliche
Table of Contents
Cover
Title Page
Copyright
Dedication
PART I: Lessons from Top Tech Companies
Note
CHAPTER 1: Behind Every Great Company
The Role of Technology
Strong Product Leadership
Empowered Product Teams
Notes
CHAPTER 2: The Role of Technology
Notes
CHAPTER 3: Strong Product Leadership
The Role of Leadership—Inspiration
The Role of Management—Execution
Note
CHAPTER 4: Empowered Product Teams
CHAPTER 5: Leadership in Action
CHAPTER 6: A Guide to
EMPOWERED
Who This Book Is For
How This Book Is Organized
PART II: Coaching
CHAPTER 7: The Coaching Mindset
Developing People Is Job #1
Empowering People Produces the Best Results
Beware Your Own Insecurities
Cultivate Diverse Points of View
Seek Out Teaching Moments
Continually Earn the Trust of Your Team
Have the Courage to Correct Mistakes
CHAPTER 8: The Assessment
People, Process, and Product
The Gap Analysis
The Coaching Plan
CHAPTER 9: The Coaching Plan
Product Knowledge
Process Skills and Techniques
People Skills and Responsibilities
Notes
CHAPTER 10: The One‐on‐One
Keys to Effective One‐on‐Ones
Anti‐Patterns
Summary
CHAPTER 11: The Written Narrative
Note
CHAPTER 12: Strategic Context
Company Mission
Company Scorecard
Company Objectives
Product Vision and Principles
Team Topology
Product Strategy
CHAPTER 13: Sense of Ownership
Notes
CHAPTER 14: Managing Time
CHAPTER 15: Thinking
CHAPTER 16: Team Collaboration
Note
CHAPTER 17: Stakeholder Collaboration
CHAPTER 18: Imposter Syndrome
CHAPTER 19: Customer‐Centricity
Notes
CHAPTER 20: Integrity
Dependability
The Company's Best Interests
Accountability
CHAPTER 21: Decisions
Right‐Size Decision Analysis
Collaboration‐Based Decision Making
Resolving Disagreements
Transparency
Disagree and Commit
Note
CHAPTER 22: Effective Meetings
Communication
Decisions
Problem Solving
Organizing Effective Meetings
CHAPTER 23: Ethics
Note
CHAPTER 24: Happiness
Meaningful Work
Personal Relationship
Personal Recognition
Work Habits
Modeling Good Behaviors
Career Planning
Note
CHAPTER 25: Leader Profile:
Lisa Kavanaugh
Path to Leadership
Leadership in Action
PART III: Staffing
Note
CHAPTER 26: Competence and Character
Competence
Character
Notes
CHAPTER 27: Recruiting
Note
CHAPTER 28: Interviewing
Note
CHAPTER 29: Hiring
Note
CHAPTER 30: Remote Employees
Artifacts
Trust
Time
Note
CHAPTER 31: Onboarding
CHAPTER 32: New Employee Bootcamp
CHAPTER 33: Performance Reviews
CHAPTER 34: Terminating
CHAPTER 35: Promoting
CHAPTER 36: Leader Profile:
April Underwood
Path to Leadership
Leadership in Action
PART IV: Product Vision and Principles
Note
CHAPTER 37: Creating a Compelling Vision
Customer‐Centric
North Star
Scope and Timeframe
Leveraging Industry Trends
CHAPTER 38: Sharing the Product Vision
Communicating the Product Vision
Validating the Product Vision
Product Vision as a Recruiting Tool
Product Vision as an Evangelism Tool
CHAPTER 39: Product Principles and Ethics
Note
CHAPTER 40: Leader Profile:
Audrey Crane
Path to Leadership
Leadership in Action
Note
PART V: Team Topology
Note
CHAPTER 41: Optimizing for Empowerment
Ownership
Autonomy
Alignment
CHAPTER 42: Team Types
Platform Teams
Experience Teams
CHAPTER 43: Empowering Platform Teams
Shared Team Objectives
Platform‐as‐a‐Product Objectives
Note
CHAPTER 44: Empowering Experience Teams
Media Product
E‐Commerce Product
Enterprise Product
Marketplace Product
Customer‐Enabling Product
CHAPTER 45: Topology and Proximity
Optimizing for the Product Team
CHAPTER 46: Topology Evolution
Evolving a Topology
Topology Warning Signs
CHAPTER 47: Leader Profile:
Debby Meredith
Path to Leadership
Leadership in Action
PART VI: Product Strategy
Notes
CHAPTER 48: Focus
Notes
CHAPTER 49: Insights
Quantitative Insights
Qualitative Insights
Technology Insights
Industry Insights
Shared Learnings
Note
CHAPTER 50: Actions
CHAPTER 51: Management
CHAPTER 52: Leader Profile:
Shan‐Lyn Ma
Path to Leadership
Leadership in Action
PART VII: Team Objectives
CHAPTER 53: Empowerment
Assigning Problems to Solve, Rather Than Features to Build
Sharing Strategic Context
CHAPTER 54: Assignment
Assigning Objectives to Product Teams
Determining Key Results
Alignment
Keep‐the‐Lights‐On Work
Note
CHAPTER 55: Ambition
CHAPTER 56: Commitments
High‐Integrity Commitments
Deliverables
Tracking High‐Integrity Commitments
CHAPTER 57: Collaboration
Shared Team Objectives
Common Objectives
Note
CHAPTER 58: Management
Keep‐the‐Lights‐On Work
Weekly Tracking
Staying on Track
Helping Our Colleagues
CHAPTER 59: Accountability
Note
CHAPTER 60: Objectives in Perspective
CHAPTER 61: Leader Profile:
Christina Wodtke
Path to Leadership
Leadership in Action
Note
PART VIII: Case Study
CHAPTER 62: Company Backgrounder
Note
CHAPTER 63: Company Objectives
Note
CHAPTER 64: Product Vision and Principles
CHAPTER 65: Team Topology
Team Topology Overview
Notes
CHAPTER 66: Product Strategy
Focus
Insights
Action
Management
Notes
CHAPTER 67: Product Team Objectives
Company Dashboard
Notes
CHAPTER 68: Business Results
CHAPTER 69: Key Takeaways
CHAPTER 70: Leader Profile:
Judy Gibbons
Path to Leadership
Leadership in Action
PART IX: Business Collaboration
CHAPTER 71: The Role of Product Leaders
Business Results
Product Strategy
Product Teams
CHAPTER 72: Stakeholder Management vs. Collaboration
CHAPTER 73: Shared Insights and Learning
CHAPTER 74: Keeping the Lights On
CHAPTER 75: Evangelism
CHAPTER 76: Leader Profile:
Avid Larizadeh Duggan
Path to Leadership
Leadership in Action
PART X: Inspired, Empowered, and Transformed
CHAPTER 77: Meaningful Transformation
CHAPTER 78: Transformation in Action
CHAPTER 79:
TRANSFORMED
CHAPTER 80: The Most Important Thing
CHAPTER 81: The Destination
Final Thoughts
Acknowledgments
About the Authors
Learning More
Index
End User License Agreement
Guide
Cover Page
Table of Contents
Begin Reading
Pages
i
ii
iii
vi
vii
viii
ix
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
Praise for EMPOWERED
“I recommend INSPIRED to every entrepreneur and burgeoning product person I talk to as the must read. That must‐read list just doubled with EMPOWERED. It's destined to become a classic.”
Shawn Boyer, Founder, GoHappy and Snagajob
“EMPOWERED dives deep into the tough organizational and cultural issues that get in the way of most companies I work with today. This is the experience and advice I've been waiting for in one book.”
Jeff Patton, Product Process and Design Coach
“I've known Chris for well over a decade. He is one of the finest product leaders I know. The product managers who worked for him went on to become great product leaders themselves, in some of the best tech companies around. If you want to learn from the best, this book captures those lessons.”
Doug Camplejohn, EVP and GM, Sales Cloud, Salesforce
“Once again, Marty's wisdom and unique perspective have synthesized best‐in‐class companies, cultures, and leaders into a thesis and set of principles that are transformational. Easy to consume and apply, EMPOWERED is a must read for product leaders and all leaders who are convinced there must be a better way.”
Chuck Geiger, former CTO Chegg, IAC, PayPal, eBay, Wine.com, Travelocity
"If you're leading product people or even the whole product organization of your company, this book is for you. It's the first book to outline the underlying philosophy behind stellar product organizations from a leader's perspective, and its many examples make it easy to understand these concepts and apply them in your company's environment."
Petra Wille, Product Leadership Coach
“As one of the most respected leaders on product globally, Marty takes us for a fascinating ride that will help you become a better product leader so you can do what you do best—create satisfying, engaging experiences for your users and customers.”
Simon Zhang, CEO, GrowingIO
“To thrive in this age of constant disruption, companies must accelerate innovation and continuously deliver products customers love. A higher level of consistent innovation can only come from truly empowered teams. Over the past several years, Marty's insights, practical advice, and wisdom have been immensely valuable during our transformation to a highly empowered product organization. In this book, Marty provides an essential blueprint for building empowered teams. If you are serious about achieving extraordinary business results and developing a product innovation culture you can be truly proud of, this is a must‐read!”
Shamim Mohammad, SVP, Chief Information and Technology Officer, CarMax
"I've had the good fortune to work with Marty for many years, and yet, every time he comes out with a new book or article, I'm filled with both excitement and fear. What new product techniques are our competitors using that we are missing? EMPOWERED hits the mark dead on, and provides a recipe for creating great products. Marty has a knack for making difficult product techniques seem both necessary and tangible. Read the book and rejuvenate your company!”
Jeff Trom, CTO, Workiva
“The core challenge of all tech companies today is to be a truly product‐led organization, with continuous product innovation resulting in sustainable competitive advantage. EMPOWERED gives executives and leaders the key to understand how they need to change their companies in order to survive and thrive.”
Frerk‐Malte Feller, COO, Afterpay
“If you are wondering what will ensure your company survives, or why your products are failing, read this book. This is the ‘how to’ manual for building great product companies that last."
Amanda Richardson, CEO, CoderPad
"I included INSPIRED as mandatory reading for anyone joining my product development teams. Now I'll add EMPOWERED to the list of mandatory reading."
Joca Torres, CPO, Gympass
"INSPIRED has been a manual for our team to build better products. EMPOWERED is now a manual to build a stronger team. Everything I've read from SVPG is spot on, and often feels like I can use it the same day."
Ian Cairns, Head of Product for Twitter Developer Platform
"EMPOWERED is first and foremost about permission. Companies have to give themselves the permission to orient around a culture of product centricity. Everything from org structure, to technology, to culture and coaching derives from this. And nothing embodies this idea more than Marty's writings."
Punit Soni, founder, CEO, Suki
The Silicon Valley Product Group Series
INSPIRED: How to Create Tech Products Customers Love, 2nd Edition (Marty Cagan, 2017)
EMPOWERED: Ordinary People, Extraordinary Products (Marty Cagan with Chris Jones, 2021)
TRANSFORMED: Becoming a Product‐Driven Company (Lea Hickman, 2021)
LOVED: How to Market Tech Products Customers Adore (Martina Lauchengco, 2021)
MARTY CAGAN WITH CHRIS JONES
Silicon Valley Product Group
EMPOWERED
ORDINARY PEOPLE, EXTRAORDINARY PRODUCTS
Copyright © 2021 by John Wiley & Sons, Inc. All rights reserved.
Published by John Wiley & Sons, Inc., Hoboken, New Jersey.
Published simultaneously in Canada.
No part of this publication may be reproduced, stored in a retrieval system, or transmitted in any form or by any means, electronic, mechanical, photocopying, recording, scanning, or otherwise, except as permitted under Section 107 or 108 of the 1976 United States Copyright Act, without either the prior written permission of the Publisher, or authorization through payment of the appropriate per‐copy fee to the Copyright Clearance Center, Inc., 222 Rosewood Drive, Danvers, MA 01923, (978) 750‐8400, fax (978) 646‐8600, or on the Web at www.copyright.com. Requests to the Publisher for permission should be addressed to the Permissions Department, John Wiley & Sons, Inc., 111 River Street, Hoboken, NJ 07030, (201) 748‐6011, fax (201) 748‐6008, or online at http://www.wiley.com/go/permissions.
Limit of Liability/Disclaimer of Warranty: While the publisher and author have used their best efforts in preparing this book, they make no representations or warranties with respect to the accuracy or completeness of the contents of this book and specifically disclaim any implied warranties of merchantability or fitness for a particular purpose. No warranty may be created or extended by sales representatives or written sales materials. The advice and strategies contained herein may not be suitable for your situation. You should consult with a professional where appropriate. Neither the publisher nor author shall be liable for any loss of profit or any other commercial damages, including but not limited to special, incidental, consequential, or other damages.
For general information on our other products and services or for technical support, please contact our Customer Care Department within the United States at (800) 762‐2974, outside the United States at (317) 572‐3993 or fax (317) 572‐4002.
Wiley publishes in a variety of print and electronic formats and by print‐on‐demand. Some material included with standard print versions of this book may not be included in e‐books or in print‐on‐demand. If this book refers to media such as a CD or DVD that is not included in the version you purchased, you may download this material at http://booksupport.wiley.com. For more information about Wiley products, visit www.wiley.com.
Library of Congress Cataloging‐in‐Publication Data is Available.
ISBN 9781119691297 (Hardcover)
ISBN 9781119691259 (ePDF)
ISBN 9781119691327 (ePub)
COVER DESIGN: PAUL MCCARTHY
This book is dedicated to Bill Campbell (1940–2016), known with affection as the Coach of Silicon Valley.
While I had met Bill a few times over the years, I was never fortunate enough to be coached by him. However, I count myself very lucky to have been managed and coached by several leaders who were coached by Bill.
Increasingly, I realize how many of the important lessons I've learned about leadership, empowerment, teams, and strong product companies can be traced back to Bill.
I hope he would approve of this book, and that he would be proud to see his teachings living on.
PART ILessons from Top Tech Companies
My first book, INSPIRED, discussed how strong product teams at the best product companies use the modern techniques of product discovery to solve hard problems in ways their customers love, yet work for their business.
INSPIRED brought me and my SVPG Partners into many more organizations, well beyond Silicon Valley.
The most striking thing we learned was that in so many companies—even companies trying to do true, technology‐powered products and services—product teams were too often not allowed to work the way they needed to.
We realized that it's not just the techniques that strong product teams use to discover successful products, but that the differences between how great product companies work and the rest run much deeper.
What we found in these companies was not pretty.
The Role of Technology
So many companies still have the old IT mindset when it comes to technology. It's viewed as a necessary cost rather than the core business enabler it needs to be. The people who work on the technology teams are literally there “to serve the business,” and the technology managers and leaders are there to facilitate serving the business. Or it's shoved off to the side in some “digital” business unit. The technology teams are disconnected from the real customers—in fact, they're encouraged to think of their stakeholders as their customers.
Coaching
There is little if any active coaching of the people on the technology teams. And even if they wanted to coach, the managers often don't have the experience themselves. So the problems perpetuate.
Staffing
Most of these companies recognize that they don't have the staff they need, but they have very misguided ideas about how to correct that, and what to look for in product staff. So again, the problems perpetuate.
Product Vision
These companies rarely have an inspiring, compelling product vision. They may have had one during the early years of their company, but after the founders left, the vision faded. The people on the technology teams feel like they're just working in feature factories.
Team Topology
The technology people are divided up into teams where they feel like they aren't responsible for anything meaningful, they can't do much without depending on changes from several other teams, and that they're just a small cog in a giant wheel.
Product Strategy
It wouldn't be fair to say that most of these companies have a weak product strategy, because in truth, most have literally no strategy at all. They are just trying to please as many stakeholders as they can with the people and time and skills they have.
Team Objectives
Most of these companies have heard that Google and others use the OKR (Objectives and Key Results) technique to manage their work, and the CEO watched a video or read a book and thought it sounded easy. So they adopted the technique—layering it on top of their existing product roadmaps and culture—and every quarter there's a planning exercise that consumes a few weeks and is then largely ignored for the rest of the quarter. Most of the people on the teams say they get little if any value out of this technique.
Relationship to Business
The relationship between the technology teams and the rest of the business is not good. The stakeholders and executives have little or no trust in the technology teams. And the people on the technology teams feel like unappreciated mercenaries, subservient to the business.
Empowered Teams
Worst of all, the teams are not empowered to solve problems in ways customers love, yet work for the business. And as such, the teams can't be held accountable to results.
The product manager is really a project manager, shepherding the backlog items through the process. The designers and engineers are there just to design and code the features on the roadmap.
Motivation is low, sense of ownership is minimal, and innovation is rare.
It is easy to see why so many of these companies are ripe for disruption. And nothing at all like how product is done at strong product companies.1
What is especially shocking to me is that it is really no secret how the best companies work, and how financially successful they are. Which raises the question, why is this the case?
In my experience, it's not that these companies don't want to transform, it's that transforming is hard, and they just don't know how. Or even what it really means to transform.
What they need is to move to empowered product teams.
Now, you may not be using that term, and you may not even realize there are different types of technology teams.
But if what I described is similar to your organization, I need to share with you a few very hard truths:
First, you have very little chance of getting meaningful business results, let alone actually innovating, from your way of working
Second, your customers are big, ripe targets for a competitor that does not operate this way (e.g., Amazon), and knows how to provide products customers love, yet work for their business
Third, you are largely wasting the talents and capabilities of the people you have hired, and your best people—the ones you desperately need to survive and thrive—will likely leave
Finally, if you think that by moving to Agile you've already done some form of digital transformation, I am sorry to tell you, but you haven't even gotten started
I'm hoping that the reason you're reading this book is because you are convinced there must be a better way.
And there is.
Note
1
To be very clear, we have found exceptionally strong companies well beyond Silicon Valley, including in Shanghai, Melbourne, Tel Aviv, London, Berlin, Bangalore, and beyond, just as we have found very weak companies in the heart of San Francisco. It is the
difference
between the best and the rest that we focus on in this book.
CHAPTER 1Behind Every Great Company
In this book, I want to share and highlight the differences between how the best companies create technology‐powered products and how most companies create products.
The differences are both fundamental and striking.
The differences certainly include what many people think of as “product culture,” but strong product companies often have very different cultures from one another, so it clearly goes beyond that.
For example, consider Amazon, Google, Apple, and Netflix. I would argue all four are very strong product companies, having consistently innovated for many years, yet they each have very different cultures.
I still believe culture is extremely important, but there is something about great product companies that is more fundamental.
It comes down to the views they have on the role of technology, the purpose of the people who work on the technology, and how they expect these people to work together to solve problems.
Moreover, I don't think it's an accident that, despite their different cultures, these four companies have the most important elements in common.
What I will try to do in this book is untangle the parts of the cultures of these companies that are more a reflection of their founders' personalities from those that are essential to consistent innovation.
I want to share the important lessons I've learned regarding what separates the best from the rest.
One surprising common thread among many of the best product companies is the legendary coach, Bill Campbell. During their formative years, Bill literally provided executive coaching to the founders of Apple, Amazon, and Google, as well as several others.
To get a sense of Bill's views and values, here is one of my favorite quotes about the role of leadership in a strong product company:
Leadership is about recognizing that there's a greatness in everyone, and your job is to create an environment where that greatness can emerge.
This book is all about identifying what makes such an environment, and I want to encourage you to consider adopting these important practices and behaviors.
Please note that I am not arguing that these strong product companies are models of virtue. All of them have been justifiably criticized about some of their policies and practices.1
But when it comes to the ability to consistently innovate, all four of these companies have demonstrated their skills, and I believe there is much to be learned from them.
At the core, I see three critically important differences between the strongest product companies and the rest:
The first is how the company views the role of technology.
The second is the role their product leaders play.
The third is how the company views the purpose of the product teams—the product managers, product designers, and engineers.
Let's take a closer look at each of these.
The Role of Technology
There is a fundamental difference between how strong companies view the role and purpose of technology as compared to most other companies.
At its most basic level, the vast majority of companies view technology as a necessary expense. They know it's important, but they think of it more as a cost of doing business. If they can outsource the labor, even better. Fundamentally, they don't really consider themselves in the technology business. Instead, they think of themselves as in the insurance business, or the banking business, or the transportation business, or whatever. Certainly, they need some technology to operate, but it's viewed as a subservient role to “the business.”
Because of that, in most companies, technology teams exist to serve the business. That is very often the exact phrase you will hear. But even if they aren't explicit about it, the different parts of “the business” end up driving what is actually built by the product teams.
In contrast, in strong product companies, technology is not an expense, it is the business. Technology enables and powers the products and services we provide to our customers. Technology allows us to solve problems for our customers in ways that are just now possible.
Whether the product or service is an insurance policy, a bank account, or an overnight parcel delivery, that product now has enabling technology at its core.
As such, in strong product companies, the purpose of the product team is to serve customers by creating products customers love, yet work for the business.
That is a profound difference, which impacts nearly everything about the company and how it works, and results in much higher motivation and morale. And most important, it results in a much higher level of innovation and value for customers and the business.
Strong Product Leadership
In most product companies, the role of true product leadership is largely missing in action.
Instead, they are mainly there as facilitators, responsible for staffing the in‐house (or even worse, outsourced) feature factory, and keeping the trains running on time.
In most companies, there is no product strategy. Notice I didn't say a bad product strategy—I mean literally no product strategy. The feature teams are simply there “to serve the business.”
The business certainly has reasons for what they request or put on the roadmaps, but they very rarely have a product strategy, or even the skills or data required to create one.
The stakeholders end up providing product teams with a prioritized list of features and projects that they need completed this quarter or this year. So, the “product strategy,” if you could even call it that, is really about trying to please as much of the business as possible.
When technology product companies moved to Agile methods over the past 10–20 years, many managers and leaders questioned whether they were still necessary, since team members would be expected to take a much more active role in how they work.
I realize this is counterintuitive to many people, but while moving to truly empowered teams does require moving away from the old command‐and‐control model of management, it does not mean you need fewer leaders and managers. It means you need better leaders and managers.
It's actually easier for a manager to manage (often micromanage) in the old command‐and‐control style. It's not hard to assign a team a list of activities, or a list of features to build, and just tell them to do the work as fast as they can.
While this command‐and‐control style may be easier for the manager, it creates teams of mercenaries with no empowerment in any meaningful sense.
In contrast, in strong product companies, the product leaders are among the most impactful leaders in the company.
They are responsible for staffing and coaching the product teams; they are responsible for the product strategy and converting the strategy into action; and they're responsible for managing to results.
Empowered product teams depend on skilled product managers, product designers, and engineers, and it is the leaders and managers who are responsible for recruiting, hiring, and coaching these people.
Further, a focused and compelling product strategy—based on quantitative and qualitative insights—is among the most important contributions of product leadership.
Empowered Product Teams
In most companies, the technology teams are not empowered product teams, they are what I call here feature teams.
Feature teams look superficially like a product team. They are cross‐functional, with a product manager, a product designer, and some number of engineers. The difference is that they are all about implementing features and projects (output), and as such are not empowered or held accountable to results.
The feature teams get to work first designing the features on the roadmap, maybe doing a little usability testing, and then proceeding to building, QA testing, and deploying the features (known as delivery).
These feature teams sometimes claim they're doing some product discovery, but they rarely are. They've already been told what the solution should be; they're not empowered to go figure out the solution themselves. They're just there to design and then code.
In these feature teams, there is usually a person with the product manager title, but they are mainly doing project management. They are there to ensure the features get designed and delivered. Necessary perhaps, but this is not product management.
Because the teams are provided, or are pressed to provide, roadmaps of features and projects, the focus of the team is delivery—delivery of these features. And features are output. Even if someone were to complain of lack of business results, who would you hold accountable?
In contrast, in strong product companies, teams are instead given problems to solve, rather than features to build, and most important, they are empowered to solve those problems in the best way they see fit. And they are then held accountable to the results.
In the empowered product team model, the product manager has a clear responsibility, which is to ensure that the solutions are valuable (our customers will buy the product and/or choose to use it), and viable (it will meet the needs of the business). Together with a product designer who is responsible for ensuring the solution is usable, and a tech lead who is responsible for ensuring the solution is feasible, the team is able to collaborate to address this full range of risks (value, viability, usability, and feasibility). Together, they own the problem and are responsible and accountable for the results.2
So, to summarize feature teams vs. empowered product teams:
Feature teams are cross‐functional (a product manager doing mainly project management, a product designer, plus some engineers), and assigned features and projects to build rather than problems to solve, and as such they are all about output and not business results.
Empowered product teams are also cross‐functional (a product manager, a product designer, and engineers), but in contrast to feature teams, they are assigned problems to solve, and are then empowered to come up with solutions that work—measured by outcome—and held accountable to results.3
Product Discovery
If you have not yet read INSPIRED, then you might be wondering: What is so wrong with the business owners and stakeholders deciding what goes on the roadmap, and therefore what the engineers should build?
This is considered the first and most important principle of product discovery: our customers, and our stakeholders, aren't able to tell us what to build.
It's not because our customers or stakeholders aren't smart or knowledgeable.
There are two fundamental reasons why our customers and stakeholders aren't able to tell us what to build:
First, the customers and stakeholders don't know what is just now possible—they are not experts in the enabling technologies, so they can't be expected to know the best way to solve the problems we're focused on, or even if the problem is possible to solve. It's often the case that innovations solve problems in ways that customers and stakeholders had no idea was possible.
Second, with technology products, it's very hard to predict in advance what solutions will work. There are many reasons why product ideas don't deliver the results we hoped. All too often we are excited about some idea, but our customers are not, so they don't buy what we thought they would. Or, we discover the idea has major privacy or security issues. Or we find out the idea will take much longer to build than anyone expected.
Empowered product teams understand these inherent issues, and product discovery is about discovering a solution that our customers love, yet works for our business.
We refer to this as product discovery to acknowledge that we understand what we can't know in advance, and to emphasize that our task is to discover a solution that is valuable, usable, feasible, and viable.
Notes
1
For an unflinching critique of these companies when it comes to their policies, see the writings of Professor Scott Galloway (
www.profgalloway.com
).
2
To be clear, the designer and tech lead contribute much more than simply ensuring usability and feasibility respectively; what I'm referring to here is who we hold responsible and accountable for each risk.
3
There is actually a third type of technology team, which is referred to as a
delivery team
(or “Scrum team” or “dev team”). A delivery team doesn't even pretend to be a true product team. They are not cross‐functional, and they are not empowered. There is a product
owner
(responsible for administering the product backlog) and some number of engineers. They are purely about output (code and ship). If you're running a process like SAFe, then this is unfortunately you, and truthfully, I have no idea why you would want to read this book, since what I describe here is the polar opposite both philosophically and practically.
CHAPTER 2The Role of Technology
I promise that this book is very practical, and you'll be able to directly apply everything we discuss. But in this one chapter, if you'll bear with me, we need to get just a little philosophical.
It is plain to see the difference between feature teams and empowered product teams.
It is plain to see when companies view teams as there to serve the business, versus when they're there to serve customers in ways that work for the business.
It is plain to see when a company is just trying to please as many stakeholders as possible, versus when they have a clear and intentional product strategy.
But while these differences might be plain to see, that does not explain why these differences exist.
If we hope to close the gap between the best and the rest, we need to look at the root cause of this gap.
Roughly a decade ago, Marc Andreessen published what I consider one of the most important essays of our time, “Why Software Is Eating the World.”1 He described why he believed that technology was about to cause major disruption across virtually every industry. He gave voice to what I had been seeing in my own work—primarily with the disruptors, but occasionally with those under threat of disruption.
Ten years later, it's clear he was remarkably prescient.
That said, most companies seem to have not really understood his warnings.
Yes, they're all spending more on software now.
Yes, they've (mostly) moved to Agile methods.
But most have not transformed in any meaningful sense, and in particular most have not embraced technology as the business enabler it is.
The examples of this are unfortunately everywhere.
One of the clearest and most egregious recent examples has to be the absolute ineptitude of the leadership at Boeing with the software at the heart of the aircraft manufacturer's shocking 737 MAX crisis.2
Boeing's fundamental mistake was to consider this technology as just a necessary cost, rather than the core competency that enables them to provide the safest, most fuel‐efficient, and most cost‐effective airplanes available.
Rather than staffing an empowered product team—continuously working to provide the safest, most fuel‐efficient, mission‐critical control software—they decided to outsource this technology, thinking they could maybe save a few dollars.
It's not just the aerospace industry. The automotive industry has suffered from this mindset for decades,3 until Tesla came along and proved what is truly possible when technology is at the core of the car, rather than treated as just a necessary cost. Going far beyond navigation and entertainment systems, using technology at its core and over‐the‐air updates, a Tesla actually improves over time rather than simply depreciating. Consider that for a moment.
Pixar has shown the film industry what is truly possible when technology is at the core of an animated feature film, rather than just a necessary cost. Pixar uses technology in ways far beyond traditional film‐making, and the technology teams are as valued as the creative teams.
As you may know, Pixar is now part of Disney, and look at how Disney has embraced technology to completely reimagine so many of their existing businesses. This includes everything from their legacy theme parks to what they've recently done with the Disney+ video streaming service.
The same story is playing out in the insurance, banking, health care, telecommunications, education, agriculture, transportation, and defense industries. I could keep going.
Often, when I am having dinner with one of the CEOs from a company that doesn't get this, they'll tell me how they're not a technology company—they're an insurance company, or a health care company, or an agricultural company. I'll say, “Let me tell you what I would do if I was a product leader at Amazon or Apple, and we've decided to go after your market because we believe it is large and underserved, and that technology is available that enables dramatically better solutions for your customers.”
After describing how we would set up our teams around the enabling technology to optimize for true innovation, I also point out that, competitively, we would be betting on them not being able to respond because they would be too busy trying to protect their old business.
It's not that these CEOs don't admire what companies like Amazon and Netflix and others have done—they generally do. It's that they don't see how these lessons apply to them. They don't understand what Marc was trying to warn them about.
Of course, there are many possible reasons why the CEOs of these companies have been so slow to grok this. Sometimes, they have worked in the old world of business so long that they need more time to wrap their head around the changes. Sometimes, I can't help but feel like they are fearful of technology. Sometimes, they just seem to be resisting change. But, ultimately, these are all just excuses. The board is supposed to be there to ensure the CEO is able to effectively lead the company.
What is especially ironic is that these companies are almost always spending far more on technology than they need to. In fact, I've never seen more wasted technology investment than I find in these companies that don't understand the true role of technology.
Rather than outsourcing hundreds or even thousands of mercenary engineers—and providing them roadmaps of features from their stakeholders which rarely generate the necessary business results—I explain to them that they will receive a much greater return from a significantly smaller number of the right employees. Employees who are given business and customer problems to solve and are held accountable to the results.
One way or another, becoming one of the best companies today requires senior leaders who understand the true and essential role of technology.
The Technology Leader
One very common manifestation of how a company views the role of technology is whether the engineers building the company's products report up to a CIO (chief information officer)/head of IT, or whether they report up to a CTO (chief technology officer)/head of engineering.
This may seem like a minor issue, but I've come to realize it's a much more significant impediment to transformation than most companies realize.
With the big caveat that each individual CIO is a unique person, I share this not as an absolute, but as something to seriously and honestly consider. Also, it is important to realize that the core CIO job (managing the IT function) is both important and difficult.
But here's the problem: the CIO truly is there to serve the business.
The very traits that make for a strong CIO can easily end up undermining the company's attempts to transform.
That's my theory for why I've found it very difficult to get CIOs—even strong CIOs—to appreciate, much less adopt, the mindset, methods, and practices of product engineering organizations.
What's especially problematic is that product engineers—the type the future of your company depends on—are rarely willing to work for a CIO because they know this difference in mindset is extremely important.
Engineers in a CIO's organization play a very different role than engineers in a CTO's organization. It's the difference between feature teams and empowered product teams.
In some cases, I've encouraged the CIO to retitle as CTO (because I believed the person was up to the challenges of this much larger role), and in other cases I've strongly encouraged the CEO to hire a true CTO to lead product engineering.
Notes
1
https://a16z.com/2011/08/20/why-software-is-eating-the-world/
.
2
https://www.bloomberg.com/news/articles/2019-06-28/boeing-s-737-max-software-outsourced-to-9-an-hour-engineers
.
3
Bob Lutz,
Car Guys vs. Bean Counters: The Battle for the Soul of American Business
(New York: Portfolio/Penguin, 2013).
CHAPTER 3Strong Product Leadership
The heart of this book is the importance of strong product leadership.
To be clear, by “product leadership” I mean the leaders and managers of product management, the leaders and managers of product design,1 and the leaders and managers of engineering.
For this discussion, I will distinguish between leaders and managers. Certainly, many leaders are also managers, and many managers are also leaders, but even if both roles are covered by the same person, there are different responsibilities.
Overall, we look to leadership for inspiration and we look to management for execution.
The Role of Leadership—Inspiration
The subject of strong leadership, is of course, a major topic, but it is a clear and visible difference between strong product companies and most companies.
The purpose of strong leadership is to inspire and motivate the organization.
If product teams are to be empowered to make good decisions, they need to have the strategic context necessary to make those decisions.
Part of the strategic context comes from the senior leaders of the company, such as the purpose of the business (the mission) and critical business objectives, but the product leadership has four major explicit responsibilities:
Product Vision and Principles
The product vision describes the future we are trying to create and, most important, how it improves the lives of our customers.
It is usually between 3 and 10 years out. The product vision serves as the shared goal for the product organization.
There may be any number of cross‐functional, empowered product teams—ranging from a few in a startup, to hundreds in a large enterprise—but they all need to head in the same direction and contribute in their own way to solving the larger problem.
Some companies refer to the product vision as their “North Star”—in the sense that no matter what product team you're on, and whatever specific problem you're trying to solve, you can all see and follow the North Star. You always know how your piece contributes to the more meaningful whole.
More generally, the product vision is what keeps us inspired and excited to come to work each day—month after month, year after year.
It is worth noting that the product vision is typically the single most powerful recruiting tool for strong product people.
Product principles complement the product vision by speaking to the nature of the products that your organization believes it needs to produce. The principles reflect the values of the organization, and also some strategic decisions that help the teams make the right decisions when faced with difficult trade‐offs.
Team Topology
The “team topology” refers to how we break up the work among different product teams to best enable them to do great work. This includes the structure and scope of teams, and their relationship to one another.
Product Strategy
The product strategy describes how we plan to accomplish the product vision, while meeting the needs of the business as we go. The strategy derives from focus, then leverages insights, converts these insights into action, and finally manages the work through to completion.
Product Evangelism
Another critical role of leaders is communicating the product vision, principles, and product strategy—both to the internal product organization, and also across the company more broadly.
John Doerr, the famous venture capitalist, likes to explain that “We need teams of missionaries, not teams of mercenaries.”
If we want teams of missionaries, it's essential that every person in the organization understands and is convinced—they need to be true believers.
This requires an ongoing crusade of evangelizing—in recruiting, onboarding, weekly 1:1 coaching, all‐hands meetings, team lunches, and everything in between.
The larger the organization, the more essential it is to be very good at evangelism, and it's important for the leaders to understand that evangelism is something that is never “done.” It needs to be a constant.
We want to ensure that every member of the product organization has joined because they sincerely believe in the larger purpose.
Normally, it is the product vision that describes what people are signing up for, but one way or another, we need to ensure the people on the team are true believers.
For example, if your vision is to deliver mass‐market electric cars, then we need people that are willing to take the leap of faith that this is both possible and worthy. Note that it is not a problem if the person you hire has different views on what might work to get us to mass‐market electric cars, but it is not helpful, for example, to hire a passionate advocate for internal combustion engines.
The Role of Management—Execution
There are of course many types of “managers” in a company. I'm most interested here in those people responsible for hiring and developing the actual members of the cross‐functional product teams.
Normally, this includes the director of product management, the director of product design, and the managers and directors of engineering. I'm not focused here on more senior‐level managers (managers of managers), or non‐people managers (such as product managers or product marketing managers).
If you want to have truly empowered product teams, then your success depends very directly on these first‐level people managers.
If you are wondering why there are so many weak product companies in the world, this would be the primary culprit. And until and unless this is corrected, there's little hope for transformation.
It is important that these managers understand—and can effectively communicate—the product vision, principles, and product strategy from the senior leaders. Beyond that, these managers have three critically important responsibilities:
Staffing
These are the people we hold responsible for staffing the product teams. This means sourcing, recruiting, interviewing, onboarding, evaluating, promoting, and when necessary, replacing the members of the teams.
If you have an HR function at your company, they are there to support managers with these activities, but they are in no way a substitute for the manager in these responsibilities.
Coaching
Probably the single most important, yet most often overlooked, element to capable management is coaching. At the very minimum, this involves a weekly 1:1 with the people who report to you as their people manager.
It is the most important responsibility of every people manager to develop the skills of their people. This most definitely does not mean micromanaging them. It does mean understanding their weaknesses and helping them to improve, providing guidance on lessons learned, removing obstacles, and what is loosely referred to as “connecting the dots.”
For example, let's say you are the manager of product design, and you meet each week for an hour or so with each of the six product designers from six different product teams that work for you.
These six product designers are each first‐class members of their cross‐functional product teams (because design is a first‐class activity, and as such it needs to partner closely with the product manager and engineers as they tackle and solve hard problems). But even if that designer is exceptionally skilled, how can she be expected to keep track of what is going on with all the other product teams? What if the design she is working on right now for her situation is in some way inconsistent or incompatible with solutions underway with other teams? The design manager is expected to flag these conflicts and get the relevant designers together to consider the bigger picture and the impact of the different solutions on the user.
More generally, every member of a product team deserves to have someone who is committed to helping them get better at their craft. This is why, in the vast majority of strong tech product organizations, the engineers report to experienced engineering managers; the designers report to experienced design managers; and the product managers report to proven managers of product management.
Team Objectives
The third responsibility of the people managers is to ensure that each product team has one or two clear objectives they have been assigned (typically quarterly) which spell out the problems they are being asked to solve.
These objectives derive directly from the product strategy—it's where insights are turned into actions.
This is also where empowerment becomes real and not just a buzzword. The team is given a small number of significant problems to solve (the team objectives).
The team considers the problems and proposes clear measures of success (the key results), which they then discuss with their managers. The managers may need to iterate with their teams and others to try and get as much coverage as possible of the broader organization's objectives.
The litmus test for empowerment is that the team is able to decide the best way to solve the problems they have been assigned (the objectives).
It takes strong managers to be self‐confident and secure enough to truly empower the people that work for them, and to stand back and let the team take credit for their successes.
Note
1
In this book I refer to the role of product design, and the title product designer. Many companies use the terms user experience design or customer experience design. What's important is that I am including service design, interaction design, visual design, and, for devices, industrial design.
CHAPTER 4Empowered Product Teams
What is most surprising to me is that the virtues of truly empowered product teams are not a secret. In fact, there are plenty of books and articles out there that describe why these types of teams are so much more effective at innovation and in solving hard problems.
While quite a few these books are inspiring and well worth reading, most companies have not been convinced to empower their teams in any meaningful sense. Why is that?
When I ask this question of CEOs and other key leaders of these organizations, the answer typically boils down to one word: trust.
The leaders don't trust the teams. Specifically, they don't believe they have the level of people on their teams they need to truly empower them. So, along with the other key business leaders from across the company, they believe they need to very explicitly direct the teams themselves. This is also known as the “command‐and‐control” model of management.
When I ask these leaders why they don't put people in place that they do trust, they usually argue that they either can't find, can't afford, or can't attract the level of people that Google, Amazon, Apple, and Netflix hire.
I then point out to them the many people I know who have moved from companies like theirs to one of these leading companies, and how their performance dramatically improved in the process.
And further, having worked with many people at each of these companies, I point out how ordinary the vast majority of the people on these teams actually are. Maybe the important difference lies elsewhere?
Maybe these strong companies have different views on how to leverage their talent in order to help their ordinary people reach their true potential and create, together, extraordinary products.
CHAPTER 5Leadership in Action
This book argues that the key to building strong product companies is having strong product leaders.
After all, these are the people responsible for staffing and coaching the members of the product teams, and they are responsible for the product vision, principles, and especially the product strategy, which determines the specific problems we need product teams to solve.
So, what do these strong product leaders look like? And what are they like to work for?
In INSPIRED, I profiled six product managers who were all responsible for iconic products, yet were largely unknown, and I told their stories—including the challenges they faced and how they overcame them.
In EMPOWERED, I want to do the same, but this time with product leaders. I profile here eight product leaders. Each has had an exceptional career at iconic product companies. Yet again, most of them are largely unknown.
I highlight two leaders of product management, two leaders of product design, two leaders of engineering, and two leaders of companies.
I'm not trying to provide full biographies here, but rather, I asked them each to share, in their own words, their journeys to leadership. My hope is that their words will give you a good sense of their approach to leadership, and most of all, what it is like to work with and for a strong and experienced product leader.
CHAPTER 6A Guide to EMPOWERED
Who This Book Is For
This book is intended for anyone interested in creating a strong product organization—from a startup founder to the CEO of a major technology‐powered company.
Specifically, the book is aimed at product leaders and aspiring product leaders. Especially the leaders of product managers, product designers, and engineers.
When you see a reference to “product person,” that is normally anyone in product management, product design, or engineering. The person might be an individual contributor or a manager.
While there are many other roles you may find within a given product team—delivery manager, user researcher, data analyst, data scientist, and product marketing manager being the main ones—this book focuses on the three core roles of product manager (PM), product designer (designer), and engineering tech lead (tech lead).
When you see a reference to a “product leader,” that is normally a manager/director/VP/CPO of product management, manager/director/VP/CDO of product design, or a manager/director/VP/CTO of engineering.
Unless stated otherwise, the advice in the book is aimed at product leaders.
If some advice is aimed at a specific role, such as a product manager, product designer, tech lead, or data scientist, then this will be called out explicitly.
While there is some role‐specific information for product designers and their leaders, and engineers and their leaders, there is more information for product managers and their leaders. This is because, when moving to empowered product teams, the product manager role and the product management leadership role are usually furthest from where they need to be.
Who Is Speaking?
Unless otherwise noted, the author's voice is either Marty Cagan or Chris Jones. Both of us are partners at the Silicon Valley Product Group.
We don't call out which person wrote each chapter because we both agree with everything written here, and both of us were involved in the many iterations required to get from the first draft of each chapter to the resulting book.
Further, the lessons shared in this book are drawn from the broader set of SVPG partners. Between all of us, we have well over 100 years of experience leading product organizations at many of the top tech companies.
