2020 EmpoweredOrdinaryPeopleExtraord

• (Cagan & Jones, 2020) ⇒ Marty Cagan, and Chris Jones. (2020). “Empowered: Ordinary People, Extraordinary Products.” ISBN: 9781119691259

Subject Headings: Product Vision.

Cited By

• http://scholar.google.com/scholar?q=%222020%22+Empowered%3A+Ordinary+People%2C+Extraordinary+Products

Quotes

TABLE OF CONTENTS

Part I Lessons From Top Tech Companies 1
Chapter 1 Behind Every Great Company 5
Chapter 2 The Role of Technology 12
Chapter 3 Strong Product Leadership 17
Chapter 4 Empowered Product Teams 23
Chapter 5 Leadership in Action 25
Chapter 6 A Guide to EMPOWERED 27

Part II Coaching 31
Chapter 7 The Coaching Mindset 33
Chapter 8 The Assessment 40
Chapter 9 The Coaching Plan 47
Chapter 10 The One-on-One 65
Chapter 11 The Written Narrative 73
Chapter 12 Strategic Context 76
Chapter 13 Sense of Ownership 81
Chapter 14 Managing Time 87
Chapter 15 Thinking 90
Chapter 16 Team Collaboration 93
Chapter 17 Stakeholder Collaboration 98
Chapter 18 Imposter Syndrome 102
Chapter 19 Customer-Centricity 105
Chapter 20 Integrity 109
Chapter 21 Decisions 114
Chapter 22 Effective Meetings 120
Chapter 23 Ethics 124
Chapter 24 Happiness 128
Chapter 25 Leader Profile: Lisa Kavanaugh 134

Part III Staffing 139
Chapter 26 Competence and Character 142
Chapter 27 Recruiting 146
Chapter 28 Interviewing 151
Chapter 29 Hiring 155
Chapter 30 Remote Employees 159
Chapter 31 Onboarding 164
Chapter 32 New Employee Bootcamp 170
Chapter 33 Performance Reviews 174
Chapter 34 Terminating 176
Chapter 35 Promoting 179
Chapter 36 Leader Profile: April Underwood 182

Part IV Product Vision and Principles 187
Chapter 37 Creating a Compelling Vision 190
Chapter 38 Sharing the Product Vision 195
Chapter 39 Product Principles and Ethics 201
Chapter 40 Leader Profile: Audrey Crane 203

Part V Team Topology 209
Chapter 41 Optimizing for Empowerment 212
Chapter 42 Team Types 216
Chapter 43 Empowering Platform Teams 220
Chapter 44 Empowering Experience Teams 224
Chapter 45 Topology and Proximity 229
Chapter 46 Topology Evolution 233
Chapter 47 Leader Profile: Debby Meredith 236

Part VI Product Strategy 241
Chapter 48 Focus 246
Chapter 49 Insights 251
Chapter 50 Actions 258
Chapter 51 Management 261
Chapter 52 Leader Profile: Shan-Lyn Ma 264

Part VII Team Objectives 269
Chapter 53 Empowerment 274
Chapter 54 Assignment 280
Chapter 55 Ambition 285
Chapter 56 Commitments 288
Chapter 57 Collaboration 292
Chapter 58 Management 295
Chapter 59 Accountability 298
Chapter 60 Objectives in Perspective 301
Chapter 61 Leader Profile: Christina Wodtke 304

Part VIII Case Study 309
Chapter 62 Company Backgrounder 312
Chapter 63 Company Objectives 314
Chapter 64 Product Vision and Principles 317
Chapter 65 Team Topology 319
Chapter 66  Product Strategy 325
Chapter 67 Product Team Objectives 334
Chapter 68 Business Results 343
Chapter 69 Key Takeaways 346
Chapter 70 Leader Profile: Judy Gibbons 349

Part IX Business Collaboration 355
Chapter 71 The Role of Product Leaders 357
Chapter 72 Stakeholder Management vs. Collaboration 360
Chapter 73 Shared Insights and Learning 363
Chapter 74 Keeping the Lights On  365
Chapter 75 Evangelism 367
Chapter 76 Leader Profile: Avid Larizadeh Duggan 370

Part X Inspired, Empowered, And Transformed 375
Chapter 77 Meaningful Transformation 377
Chapter 78 Transformation in Action 380
Chapter 79 TRANSFORMED 386
Chapter 80 The Most Important Thing 389
Chapter 81 The Destination 392

---

---

References

Chapter 6 A 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.

...

As product leaders, you need to decide which are trends and which are fads and, most important, which trends have the opportunity to substantially help you deliver innovative solutions for your customers.

Most of the time, our product vision leverages one or more major industry trends.

Examples of major technology trends as of this writing include mobile, cloud computing, big data, machine learning, augmented reality, internet of things, edge computing, and consumerization of the enterprise.

Note that industry trends are not limited to technology trends. There are other trends that are critically important, such as changing behaviors of groups of users, and changing buying patterns.

I can only guess at what the major trends will be in 5 or 10 years, but I'm certain there will be several additions to this list.

Interestingly, I am also quite confident that most if not all of this list of current trends will still be relevant in 5 or 10 years. The real trends are not fleeting.

...

Product Vision and Architecture

So much derives from the product vision.

The engineering organization needs the product vision so that they can ensure that the architectural decisions they make will serve the needs of that product vision.

Note that it's not necessary, or even usually desirable, for the engineers to build out in one major effort the full architecture that is necessary for the product vision. But it is essential that the engineers know what the endgame is so they can make good choices along the way and avoid having to reengineer, possibly even multiple times.

For example, the product vision may imply that the product eventually needs to be able to make highly accurate predictions about how to personalize a user's experience. Even though machine-learning capabilities may not be an immediate need, simply knowing this is coming will have real implications for how the engineering team architects the product.

Similarly, the team topology (described in Part V) is heavily impacted by the product vision and the architecture, especially for platform teams that encapsulate the underlying services. A product architecture informed by vision becomes especially critical in organizations suffering from serious technical debt. Few things frustrate me more than an ...

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.

...

Communicating the Product Vision It's worth investing some real time and effort into the best way to communicate the product vision. Remember that the vision's purpose is to inspire. PowerPoint presentations rarely inspire anyone. The minimum is typically to create a visiontype, and we often produce a video of this visiontype. A visiontype is a conceptual prototype—a high‐fidelity user prototype (realistic looking, but completely smoke and mirrors—and because of that, it is very easy to create, and most important, not constrained by what we know how to build). The difference between a high‐fidelity user prototype used as a visiontype, and a high‐fidelity user prototype used in product discovery, is the scope of what's covered by the prototype. The visiontype describes the world once the vision is a reality—that may be 3 years or 10 years in the future. The product discovery prototype describes the new feature or experience for something we will likely build in the coming weeks. Once you have this visiontype, you can show it (demo it) to anyone you like. But many companies today are taking a little extra time and effort and producing a scripted video designed to show off the visiontype in the best light possible. This may mean showing how different types of users would experience the product, and leveraging the emotional power of music and a thoughtful script to help increase the impact. Another effective way to communicate a product vision is with storyboarding, much like what is done to create and share an outline of a movie. As with a video showing off a visiontype, a storyboard focuses on the emotion and the customer experience and not on the details. Because this is about communicating a product vision, and because the product vision is meant to be told from the users' perspective, your product designers will need to play a key role—both in crafting the experience and in determining the best way to communicate that experience. Validating the Product Vision

...

Part II Coaching

...

Chapter 7 The Coaching Mindset

...

Chapter 8 The Assessment

...

People, Process, and Product

As readers of INSPIRED know, the taxonomy I like to use when talking about product is the three pillars: people, process, and product.

For purposes of the assessment tool, I like to cover product first because product knowledge is the foundation for everything else. Without competence in product knowledge, the rest doesn't really matter.

Product Knowledge

Process Skills and Techniques

People Skills and Responsibilities

...

=== Chapter 9 The Coaching Plan 47

...

Chapter 53 Empowerment

...

Objectives

The specific objectives will, of course, be a function of the type of product and the responsibilities of the particular product team, but typical examples of good objectives are:

• Reduce the frequency of parcels delivered to the wrong address • 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
• Increase the percentage of new customers that successfully create an account
• Reduce the time for a user to produce their first monthly report •Reduce the time required to deploy a new or updated service to production
• Improve the site availability

Remember not to get too attached to the specific wording of the objective. Often, once a product team understands the strategic c and has had a chance to investigate the objective, they find that it may make more sense to rephrase, or change the emphasis, or generalize the objective. This back and forth between the leader and the product team is both normal and healthy. context

What's most important about all of these examples is that they are problems to solve and not features to build.

Some are customer problems, and some are business problems, but in each case, there are any number of potential solutions. The point is that the product solution. team is best suited to determine the most appropriate

Notice also the example objectives are all qualitative. The quan titative dimension will be discussed in the key results. It's also important to acknowledge here that many of the most important objectives will require the product team to either collabor ire with other product teams or, in many cases, to collaborate with different parts of the organization to achieve the goal.

That is not only okay, but very much intended, although in prac tice this depends on having a product manager on the product team who has a deep understanding of the business.

Key Results

While the objective is the problem to solve, the key results tell us how we define success.

And it's essential that we define success by business results (aka out come) and not simply activity or output.

The second most common reason that teams go wrong with team objectives is that they end up listing activities or deliverables as their miss the point. But, just in case it's not, the reason this is so much of key results. Hopefully, at this point it is clear to you that output a problem is that it is very easy to ship a deliverable yet not solve the underlying problem. In which case, we're back to the same old problem we have with product roadmaps. would for each objective. The first key result is normally the primary measure. Then we have one or more key results as a measure of between two and quality-sometimes called guardrail or backstop key results-to ensure that the primary key result is not something else. inadvertently achieved by hurting something else.

For example, suppose we consider the objective of:

• Reduce the frequency of parcels delivered to the wrong address

Now, the primary key result would likely be the actual percentage of incorrect deliveries. But if we were to achieve that by burdening the ...

...

Chapter 56 Commitments

...

Tracking High‐Integrity Commitments

High‐integrity commitments are given special treatment. We do not talk in terms of how ambitious the team needs to be. These are binary. The team either delivers what they promised or not. And a team that makes a high‐integrity commitment is absolutely expected to deliver, or at the first sign of trouble, they need to raise the flag early and ask for help.

Further, we normally track these high‐integrity commitments explicitly. In some companies, the CTO must personally agree to each high‐integrity commitment because it is her reputation on the line.

As I've said many times in this book, empowered product teams are predicated on trust, and high‐integrity commitments are one of the important ways that product teams build trust with leadership. So when you are asked to come up with a high‐integrity commitment date, it is essential that you and your team be sure you can and will deliver on this commitment.

One final note of warning: high‐integrity commitments and deliverables should be the exception and not the rule. Otherwise, it is a slippery slope and pretty soon your objectives become nothing more than a list of deliverables and dates, which is little more than a reformatted roadmap.

Chapter 61 Leader Profile: Christina Wodtke

...

Chapter 65 Team Topology

...

Team Topology Overview

They have two types of experience teams — those focused on employers and those focused on job seekers — designed to align with the two main types of customers. They also have about a third of their resources devoted to an internal platform that the experience teams are all built upon.

...

Chapter 70 Leader Profile: Judy Gibbons

...

Chapter 80 The Most Important Thing

...

Chapter 81 The Destination

...

The Role of Technology

Your company understands the critical and essential role that technology plays in enabling your business, and the experience you provide to your customers. When new technologies emerge that you believe have the potential to be relevant, you immediately designate some engineers to learn that technology and to consider how it may be able to help solve problems for your customers in ways that are just now possible. This goes far beyond using technology for operational efficiencies. You understand that technology allows you to reconsider what's possible and reimagine every aspect of your existing business. You view your product managers, product designers, engineers, and data scientists as absolutely core to your business. You would no sooner consider outsourcing them than you would outsource your executives.

Coaching

...

...

References

;

	Author	volume	Date Value	title	type	journal	titleUrl	doi	note	year
2020 EmpoweredOrdinaryPeopleExtraord	Chris Jones Marty Cagan			Empowered: Ordinary People, Extraordinary Products						2020