Empowered: Ordinary People, Extraordinary Products

by Marty Cagan

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.

People on feature teams dread the topic of stakeholders, especially product managers and product designers. They view these people as at worst dictatorial, or at best as obstacles to deal with.

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

the more senior in the organization, the more the executives care about everything—customers, brand, revenue, compliance—and the more important it is for the product manager to have done her homework.

In modern product organizations, a PM's effectiveness depends on her ability to effectively navigate a range of personalities. She needs to understand the multiple agendas of others while simultaneously advancing her own.

Congratulations! You've identified the list of relationships in which this PM needs to invest. So how does she do this? Have her start by simply getting to know these people one on one.

With mutual trust, interactions go more smoothly. It's easier to disagree professionally without either party taking it personally. Everyone's job becomes more enjoyable when they're working with people they care about.

I interpret this signal very differently. It is my mind warning me of the consequences if I don't do my homework and truly prepare. The fear of looking clueless is what keeps me up late preparing, studying, thinking, writing, rehearsing, and iterating.

the fear of looking clueless is also what pushes me to try out my article/talk/presentation beforehand on some people that I highly respect and I know will tell me honestly if I am not solid in my thinking or my delivery.

Whenever I see some product person deliver an underwhelming presentation to an executive team or a conference, my frustration is centered not on the product person, but rather on that person's manager.

Empowered product teams are predicated on trust—especially the product manager having earned the trust of the executives. When a product manager appears unprepared or naive in front of the executives, that trust is diminished, and it will take a long time to regain it.

this is why I tell managers and leaders of product that they are only as strong as their weakest employee.

if your leaders don't demonstrate this sincere care for your customers, then it will be very hard to develop this in your product people or anyone else.

I am a big fan of using storytelling to drive home what caring for customers really means in practice.

I also recommend a minimum of three, one‐hour customer interactions each week, ongoing, and during the weekly 1:1, I love to ask about these customer interactions and see what the product person has learned.

I also encourage the product person to share with me stories of what they experienced during these visits, and then to share these stories widely around the company. I explain that my purpose is to establish the reputation of this product person as someone who has a deep and personal knowledge of the company's users and customers.

One of the behaviors I love in companies that are truly customer‐centric is that leaders will usually proactively reach out to the product team and offer to help in any way they can. This sends a very clear message to the team as to their importance without resorting to micromanaging them.

They might be very supportive of the concept of empowered teams, but if you make them choose between empowered teams and taking care of customers, you probably won't like what they decide.

while I need to make certain the product person genuinely likes and respects her customers, I don't want her to think her job is to ask her customers what to build.

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

if she gives her word on something—to a customer, stakeholder, executive, partner, or her own team—she needs to first be sure she is basing her commitment on informed judgment.

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.

this is a major reason why equity‐based incentive and compensation plans are so effective—none of us wins unless the company wins.)

It's not unusual for a new product manager to wonder how she can demonstrate this understanding of the company's best interests when she's the product manager of just a single team. But there are many opportunities: helping out another product team on one of their critical objectives, going above and beyond for a customer or a stakeholder, or publicly giving credit to others. And most common of all, making or supporting a decision that is not necessarily optimal for her product team, but is clearly better for the customer or the business.

Accountability for a product manager of an empowered product team means a willingness to take responsibility for mistakes.

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.

here are the five key behaviors that I coach product teams on when it comes to decision making.

Depending on the level of risk and consequence, you may feel there is critical information you absolutely need to collect before you can make a decision, and in other cases you may feel comfortable making the decision based on the imperfect information you have today.

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.

Almost every product person I've ever coached has struggled with the question of what decisions she “owns” and what decisions others “own.” And I have to work hard to try to change this mindset.

since we often have imperfect information to make decisions, opinion and judgment play a necessary role.

Keeping in mind our goal of bringing our team and our leaders along with us in understanding the rationale for our decisions, it's important that we be transparent in making them. We don't want anyone to think we are making uninformed decisions, or ignoring important concerns, or pursuing our own agendas.

For minor decisions, it is often sufficient just to explain clearly and simply in a note why a decision was made. For major decisions, I am a very big fan of the written narrative we discussed earlier. Especially with the FAQ section where each anticipated objection or concern is spelled out and addressed.

Meetings are a very easy way for other executives to form judgments about the people on the product team, especially the product manager.

While there are, of course, an infinite number of possible reasons for a meeting, in practice, in product organizations, there are generally three types: communication, decisions, and problem solving.

In this case, we have some nontrivial information that the organizer believes is too important or too complex to be sent via an asynchronous means such as an email. An example might be an all‐hands or a session where the leaders explain the product strategy.

The second type of meeting requires a decision, usually because it's beyond what the product team can decide on its own. This is usually because the impact reaches into other parts of the company or there is substantial risk. In this case, I am a very big advocate of the written narrative. We start the meeting with each member reading the narrative, and then we discuss and make an informed decision.

The third type of meeting is fundamentally for problem solving. We don't know what the best course of action is (otherwise we probably would have written that up in a narrative and presented it for a decision). But we believe that, if we can get the right minds in the room, that together we may be able to solve an especially difficult problem. An example might be a postmortem after an outage, where we consider what we could do differently going forward to avoid this type of problem in the future.

Here's how I coach product teams on meetings.

Assuming you've prepared, your job as the organizer is to facilitate an effective meeting. The nature of the facilitation will be different depending on the type of meeting. You are not there to police the meeting—you are there to ensure you get to the necessary decision or solution.

Once the meeting has reached a conclusion, there is usually some follow‐up that needs to be done. This may involve notifying interested parties of the decision or next steps, but it's important to close the loop.

the four big risks that every product team needs to consider are: Will the customer buy it, or choose to use it? (Value risk) Can the user figure out how to use it? (Usability risk) Can we build it? (Feasibility risk) Can the stakeholders support this solution? (Business viability risk)

unlike the other areas of business viability, there is rarely a stakeholder explicitly responsible for ethics.

have been advocating for explicitly considering ethical implications by adding a fifth risk: Should we build it? (Ethical risk)

“Leaders need to recognize that there's a sea change in the world, where companies and their leaders are increasingly going to be held accountable for ethical failures.”

Good product teams need to understand the implications of the solutions they're designing—not just on revenues, but on that broader stakeholder community. Signals to watch for: Will the product solution be good for the end‐customer? Does it have a negative impact on the environment in some way, or third parties in the community? Is it something that, if all of the emails and documents and discussions around the product were published online, you'd be embarrassed? How would government regulators react if they knew everything? Will the product be something that you will be proud of as part of your personal brand?

I rarely encourage people to leave their company; however, when it comes to those companies that are clearly ignoring the ethical implications of their work, I have and will continue to encourage people to leave.

If you're not proud of where you work, not proud of how your company is impacting the world, or believe that leadership really doesn't care about integrity, it's probably time to start looking for another job.

Most people in the product world want their work to be meaningful. In fact, unless the manager is bad—in which case that dominates—in my experience this is usually the largest factor in happiness, even more than compensation.

Lots of people tell me they don't need recognition, but I rarely believe them. What I believe they're telling me is that they might not feel comfortable with certain forms of public recognition. But in my experience, pretty much everyone wants to feel valued. Especially by people they respect.