Empowered: Ordinary People, Extraordinary Products

by Marty Cagan

Leadership is about recognizing that there's a greatness in everyone, and your job is to create an environment where that greatness can emerge.

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.

in strong product companies, the purpose of the product team is to serve customers by creating products customers love, yet work for the business.

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.

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.

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.

More generally, the product vision is what keeps us inspired and excited to come to work each day—month after month, year after year.

the product vision is typically the single most powerful recruiting tool for strong product people.

The strategy derives from focus, then leverages insights, converts these insights into action, and finally manages the work through to completion.

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.

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.

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

I typically recommend at least 15 customer visits as part of new PM onboarding.

I wish Weave had this in place.

With every interaction, at the very least, you're looking to learn: Are the customers who you think they are? Do they have the problems you think they have? How do they solve that problem today? What would it take to get them to switch?

When I coach product managers on competitive analysis, I like to ask the PM to evaluate the top three to five players in the space and to write up a narrative comparing and contrasting the strengths and weaknesses of each player—highlighting opportunities.

Seems like a good exercise.

But this is first and foremost about helping the person to first reach competence, and then to reach her potential.

Order matters: Competence then potential. Not sure how Heath is going to do this.

For new PMs in the onboarding period who are not yet competent, it may be two to three times per week, or even daily.

1:1 frequency variable depending on competence (newness to the org)

What does homework really mean? For a product manager, it means learning the product inside and out. Learning about the users and customers. Learning the data. Learning the capabilities of the enabling technologies. Learning the industry. Learning the various dimensions of the business, especially financial, sales, go‐to‐market, service, and legal.

What does it mean to think like a product person? It means focusing on outcome. Considering all of the risks—value, usability, feasibility, and business viability. Thinking holistically about all dimensions of the business and the product. Anticipating ethical considerations or impacts. Creative problem solving. Persistence in the face of obstacles. Leveraging engineering and the art of the possible. Leveraging design and the power of user experience. Leveraging data to learn and to make a compelling argument. What does it mean to act like a product person? Listening. Collaborating. Shared learning. Evangelizing. Inspiring. Giving credit and accepting blame. Taking responsibility. Knowing what you can't know and admitting what you don't know. Demonstrating humility. Building relationships across the company. Getting to know customers on a personal level. Leading.

Love this.

The structure is to write the narrative itself in a few pages and then follow this with an FAQ. The idea is to anticipate the different concerns and objections that might come from key executives and stakeholders, take the time to consider and write up clear answers to these objections, and then review these responses with the people that have these concerns. When the executive later reads this narrative, she can see that you anticipated the issues and considered the response, and she knows that you have done your homework.

Hopefully everyone understands that these company objectives must be outcomes (business results), and not output (such as delivering on specific projects).

The strategic context provided by the company mission, company scorecard, company objectives, product vision and principles, and product strategy is meant to apply to all product teams in the company.

I (Marty) still remember how this concept was first explained to me when I was considering expanding from a tech lead to take on the product manager responsibilities, along with the rationale I was given to my inevitable questions of “Why?”

This back and forth of why? is really good.

If I had to boil it all down, I'd say that thinking like an owner versus thinking like an employee is primarily about taking responsibility for the outcome rather than just the activities.

I often try to convince exceptional designers and engineers to consider moving to product management. And while I've had some good success with that, the single most common objection I hear is an unwillingness to take responsibility for outcomes (and the pressure that implies).

True. PMs are the fall men. A little bit of spider man in this quote "with great power comes great responsibility." We are telling the business how to spend their resources.

I have always found it immensely powerful to be able to point out that the employee is a part owner in the company just as I am. We need to be thinking about creating value for the company over the long term and not just focusing on our specific daily issues.

If the person is a product designer or tech lead and is not able to spend most of the day doing actually creative work, then you have a larger problem.

Well...I guess we have a larger problem.

in the vast majority of cases, I find that the product manager is spending most of her day doing project management work, rather than product management work.

Partly because the work does need to be done—especially when it's urgent—and the product manager may not believe there is anyone else available or able to do it. Partly because a lot of product managers have never been trained or coached on what product management is really all about, and they think that's what the job is. And partly because I think many people are actually more comfortable with the project management tasks, as they are tangible and much more straightforward, and it can feel productive to check lots of things off the list every day.

Good reasons why project management is what is mostly done.

Your highest‐order contribution and responsibility as product manager is to make sure that what the engineers are asked to build will be worth building. That it will deliver the necessary results. This means working with designers and engineers to come up with solutions that are valuable, usable, feasible, and viable. That is product discovery, and that is what takes on the order of four solid hours a day.

Good product companies try to determine how well the candidate can think and solve problems during the interview process. The issue is not whether the candidate actually knows the answer to a question. The issue is what does she do when she doesn't know the answer?

collaboration is not about artifacts. Many product managers think their job is to produce some form of document capturing “requirements,” or, at the least, they are there to write user stories. It is true that sometimes we need to create artifacts (especially when team members are remote), but that is certainly not how we collaborate. In fact, these artifacts more often get in the way of actual collaboration.

We need to find a solution that works. By that we mean that it is valuable (valuable enough that target customers will actually buy it or choose to use it), it is usable (so users can actually experience that value), it is feasible (so we can actually deliver that value), and it is viable for our business (so the rest of our company can effectively market, sell, and support the solution).

I love this, so I am highlighting it again.

If I had to pick the one thing I love most about the feeling of true collaboration on an empowered product team, it is the form of magic that happens when you have people who are a) motivated and b) skilled in their respective discipline—product management, product design and engineering—and they sit around a prototype or watch a user interact with a prototype. The engineer points out new possibilities, the designer points out different potential experiences, and the product manager weighs in with the sales‐ or financial‐ or privacy‐related implications, and after exploring a bunch of approaches, they find one that actually works. It's valuable, it's usable, it's feasible, and it's viable.

Collaboration means product managers, product designers, and engineers working together with customers and stakeholders and executives to come up with a solution that solves for all of our constraints and risks. This is what we mean by solutions that our customers love, yet work for our business.

the purpose of the product team is “to serve the customers in ways customers love, yet work for the business.”

The first thing I like to emphasize is to be very specific and protective over the term “customer.” It is an all‐too‐common problem where a product person thinks she has many different “customers.” In addition to the actual paying customers, she views each stakeholder as a customer, and she views the customer service team as her customer, and she views the CEO as one of her customers too.

We may have a lot of users, but customers are sacred.

When I coach product people on integrity, there are three essential behaviors I focus on: dependability, the company's best interests, and accountability.

with an empowered product team, it's not sufficient just to ship something when promised. What you ship must actually work—it must solve the problem for the customer and/or the business. This is much more difficult.

You may have heard the old saying, “If a product team succeeds, it's because everyone on the team did what they needed to do, but if a product team fails, it's the product manager.” Some people think this saying is facetious, but not really.

Yet it's also important to explain that integrity does not mean perfection. Mistakes will happen. But the product manager's career will survive these mistakes if she is on the whole dependable in her commitments, always works toward the company's best interests, and takes responsibility for her mistakes.

As an example, it's normal for a novice product manager to either seriously underestimate or overestimate risk. She ends up spending too much time in discovery on items that don't really matter, and then doesn't have time for the risks that do.

Let me be clear on this: the best product companies hire competent people of character, and then coach and develop them into members of extraordinary teams.

Stephen Covey explained that: Trust is a function of two things: competence and character. Competence includes your capabilities, your skills, and your track record. Character includes your integrity, your motive, and your intent with people. Both are vital.

Just make sure they are competent and not assholes.

innovation thrives in a team where each person thinks differently

I'm speaking here about outsourcing as it pertains to the core roles in a tech product organization: product managers, product designers, engineers, data analysts and data scientists, user researchers, and the managers of these people. Your products are the lifeblood of your company, and these skills must be core competencies. Your customers depend on these products and services. Outsourcing these things will almost certainly kill any chance you have of teams of missionaries. Just the opposite, you literally have created teams of mercenaries.

Quite the warning.

This setup should be disarming. The candidate must understand that there is no correct answer to the question, hopefully setting up an honest conversation. Now for the four attributes, in no particular order. I (Chris) usually describe them this way: Execution — how well do you get things done, do the right thing without being asked, and track lots of simultaneous targets? Creativity — how often are you the person in the room with the most or the best ideas? Strategy — how well do you get up above what you're working on and put it into a broader market or vision context and then make this clear to others? Growth — how good are you at figuring out ways to multiply effort through smart use of process, team management, and so on?

During discovery, the main artifact should be prototypes.