Empowered: Ordinary People, Extraordinary Products

by Marty Cagan

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...

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.

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 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.

innovations solve problems in ways that customers and stakeholders had no idea was possible.

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.

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.

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.

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.”

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.

One way or another, becoming one of the best companies today requires senior leaders who understand the true and essential role of technology.

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.

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.

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:

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.”

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 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.

If a product team is not effective, we need to look hard at the people on that team and see where we can help them improve as individuals, and especially as a team.

More than anything, good coaching is an ongoing dialog, with the goal of helping the employee to reach her potential.

Developing People Is Job #1 It's amazing and distressing how few managers actually subscribe to this principle—that developing people is job #1.

If you are a manager, you should be spending most of your time and energy on coaching your team. This means expending real effort on things such as assessing your team, creating coaching plans, and actively helping them improve and develop. You should measure your own job performance on the successes of your team members, even more than the success of your products.

Empowering means creating an environment where your people can own outcomes and not just tasks.

we need teams of missionaries, not teams of mercenaries.

Insecure managers have a particularly hard time empowering people.

Cultivate Diverse Points of View An insecure manager may suppress opinions that are different from her own.

Nurturing a team that allows for diverse points of view begins with the hiring process where you consider your team as a portfolio of strengths and backgrounds.

As a coach, you are always looking for opportunities that encourage your people to stretch beyond their comfort zone.

Continually Earn the Trust of Your Team None of your coaching efforts will be effective without trust.

I have found that you can help establish personal rapport and trust by sharing some of your own personal challenges.

Product Knowledge User and customer knowledge—Is the product manager an acknowledged expert on her target users/customers? Data knowledge—Is the product manager skilled with the various data tools and considered by her product team and her stakeholders as an acknowledged expert in how the product is actually used by users? Industry and domain knowledge—Is the product manager knowledgeable about the industry and domain? Does she understand the competitive landscape and the relevant industry trends? Business and company knowledge—Does the product manager understand the various dimensions of your company's business, including marketing, sales, finance (both revenue and costs), services, legal, compliance, privacy, and so on? And do the stakeholders believe that the product manager understands their concerns and constraints? Product operational knowledge—Is the product manager considered an acknowledged expert on how her product actually works? Would she be able to effectively demo to a prospective customer, train a new customer on how to successfully use it, and handle live customer support inquiries? Product knowledge really is table stakes. A new product manager typically requires two to three months to ramp up to speed on product knowledge, assuming she dives in aggressively

The Gap Analysis Now that we have the skills taxonomy, the core of this technique is a gap analysis. The way this works is that the manager should review the set of criteria above and assign two ratings to each skill. Expectations vs. Current Capability The first rating is an assessment of where the employee needs to be in this skill (i.e., expectations rating), and the second rating is an assessment of where the employee currently performs on this scale (i.e., her capability). I typically rate these on a 1–10 scale, with 10 being a skill that is absolutely essential to the job.

The level of expectations is always set by the manager, if not the organization as a whole. Most of our effort is in determining the capability rating. Normally, the assessment of the product manager's capability level is done by the manager. However, there is no reason why the product manager can't also do a self‐assessment, and in fact I encourage that. But be aware that it is not at all uncommon for the self‐assessment to expose some significant differences with how the product manager assesses her own capabilities. A manager that only relies on the self‐assessment because she is uncomfortable confronting these differences in perception is, in my view, abdicating her responsibility as a manager.

I usually recommend that the new PM take a CSPO (Certified Scrum Product Owner) course if she has not already done so. That simple and short course will explain her responsibilities as the product owner for the team. Most companies have also standardized on a tool for managing the product backlog, so the new PM will need to learn this tool as well.

the difference between being just a competent PM, and a truly effective PM, is often their skills with people.

you can significantly improve and develop their people skills. But they do have to want to improve.

Modern product management is all about true collaboration between product, design, and engineering. This begins with ensuring the product manager is knowledgeable about the real contribution of product design and engineering. The PM does not need to be personally skilled in either design or engineering (most aren't, although many PMs believe they're great designers), but they do need to understand and appreciate their contributions to the point where they understand that what design and engineering bring to the table is just as essential as what the PM brings. Next, the PM needs to establish the relationships necessary for true collaboration, which is built on trust and respect.

once they've learned the basics we've discussed above, most of the coaching I do has to do with collaboration.

Again, that's just the nature of product today. But during these sessions, I am witness to countless interactions. And afterward, if I've observed something, I often pull the PM aside and try to point out how her interactions during that meeting either helped or hurt her efforts to build trust.

A one‐hour meeting discussing a problem or objective will usually yield many good examples I can use as a coaching opportunity for the PM. How engaged is the rest of the team? Are they acting like they are empowered to solve the problem, or are they acting like order takers? Is the designer and engineer bringing potential solutions to the table or just pointing out issues with whatever the PM proposed? Are they spending too much time talking (e.g., planning) and not enough time trying (e.g., prototyping)? How are they resolving differences of opinion?

Many of the points regarding team collaboration skills also apply to stakeholder collaboration skills, but it's actually easier to build trust and relationships with your own teammates (e.g., your designer and engineers) because you interact with them every day—focused on solving the same problem.

The key to successful working relationships with stakeholders is establishing mutual trust. For the PM, that starts with putting in the time and effort to understand what each of the stakeholder's constraints are. We discussed this under Business and Company Knowledge above.

Especially in medium to large‐sized companies, so much of product involves persuasion. This involves convincing your team and your stakeholders that you understand what you need to do, and you've got a solid plan to deliver.

My favorite technique for developing a strong and compelling argument is the written narrative, which is discussed in Chapter 11, The Written Narrative.

for the PM, leadership must be earned. It does not come with the title.

I absolutely love coaching tech leads. More often than not, these are the people behind the world's most impressive innovations. A tech lead is essentially a senior‐level engineer who has taken on the additional responsibility of participating in the ongoing product discovery work. The tech lead is the key partner to the product manager and product designer. They are asked to care not just about building and delivering reliable products, but also to care about what gets built. Tech leads bring deep knowledge of the enabling technologies, and when that knowledge is combined with a direct understanding of the customer's pain and problems, magic can result.