Empowered: Ordinary People, Extraordinary Products

by Marty Cagan

One challenge when moving to empowered product teams is that most product managers and engineers coming from feature teams have never worked with a professional product designer, so they don't even know yet what they are missing. As a result, design leaders often need to raise the bar and educate product managers and tech leads about what strong product design is and how product designers contribute to successful products.

the product person needs to understand that for you both to succeed, you'll need to be able to trust and depend on each other, and most important, to be able to speak honestly and frankly.

There's simply no substitute for the product person doing her homework. It is the foundation for competence, and it's the main activity during the onboarding period. You can guide the product person to the right resources, and answer questions about the material, but it's on the person to spend the time and effort to do her homework and gain this knowledge.

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.

The best product leaders measure their success in how many people they've helped earn promotions, or have moved on to serve on increasingly impactful products, or to become leaders of the company, or even to start their own companies.

Manager Spends Time Talking and Not Listening While there's nothing wrong with preparing for the session by jotting down some notes of items to discuss, it's critical to keep in mind that this session is primarily for the product person and not for you. It's all too easy for you to talk for 30 minutes straight, and then you're out of time. Moreover, it's important to recognize that people learn in different ways, and you'll learn that by listening not talking.

sometimes we have a manager that has been working sincerely, tirelessly, and capably for several months to coach the person, yet she can't seem to get the product person to competence. It's important to realize that not everyone is cut out to be a product person. When I find this to be the case, it's usually because the person was simply reassigned from a different role at the company—maybe because this person used to be a customer and knew the product or the domain, or knew the CEO, or whatever—but she simply doesn't have the core foundation to succeed in the role.

Someone who needs to be told what to do every day is not cut out for the product person role. And this is also not scalable. You need people that can be developed into capable and competent product people—that can be given an objective and then counted on to find a way to get it done.

The technique I'm talking about is writing out a narrative explaining your argument and recommendation.

I'm talking about a roughly six‐page document that describes in narrative form the problem you're trying to solve, why this will be valuable for your customers and for your business, and your strategy for solving the problem. If this narrative is done well, the reader will be both inspired and convinced.

What the written narrative does is make this obvious. We've all seen product people stand up and bluster, and pretend to know what they're talking about. But with the written narrative, there is no faking

most product people I know would do nearly anything to avoid having to write out this type of narrative analysis and recommendation. Yet, it's one of the most valuable things they could do to both move faster and make better decisions.

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.

while it's common that everyone knows the purpose of the company, many people may not know how they personally are able to contribute to that mission.

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

Normally, the product vision is somewhere between 3 years and 10 years out and describes the future we are trying to create, and why that future will improve the lives of our customers. The mission may provide the purpose, but it's the vision that begins to make this tangible. It's worth noting that the product vision is also our single best tool for recruiting strong product people.

each product manager, needs to understand this strategic context, and she needs to demonstrate in her statements, actions, and decisions how her team is contributing to the common goals.

A strong product person is not just competent in terms of knowledge and skills, she also has an effective product mindset and consistently demonstrates good judgment in her decisions and her interactions.

“There will always be many good reasons not to ship, and it's your responsibility to figure out a way over, around, or through each obstacle.”

in a company, especially a large company, there are many people there to ensure that the assets are protected—the sales force, the revenue, the customers, the reputation—and getting things done in a company means understanding and respecting these constraints by coming up with solutions that work for the business.

executives of companies with the empowered team model learn that the product manager is the canary in the coal mine.

innovation depends on true collaboration with design and engineering, which is a peer relationship and not a reporting relationship

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

if CEOs want their key people to think and behave like owners, they should compensate them like owners.

An evergreen strategy with equity means that your best people will always feel like they would be leaving behind substantial compensation if they exit before they are fully vested.

to get the critically important work of a product manager done, you need on the order of four solid hours a day.

I'm not talking about email or Slack or meetings. I mean quality time working on coming up with solutions to the difficult problems we're trying to solve—otherwise known as product discovery.

manager that spends her time rushing from meeting to meeting, constantly complaining about not having any time to do “real product work.” So, it's no surprise that one of the most common, and most important, coaching topics is helping a new product manager learn to manage her time.

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.

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.

I encourage product managers to block off this time for the week, and protect that time, and then you still have half a day for other stuff.

the project management work doesn't go away. Which is why my favorite answer to this problem is for the product manager to team up with a delivery manager who can take on the project management, ...

if you can't manage to clear four hours a day during your workday, then I only know of two possibilities: either you extend your workday, or you fail to deliver results and so you fail at your job.

I meet countless people who are clearly intelligent, yet waste their minds because they don't know how to (or are unwilling to) actually solve hard problems by thinking.

we also need to recognize that acquiring knowledge and applying knowledge are two different things.

product managers must be problem solvers as well. They are not trying to design the user experience, or architect a scalable, fault‐tolerant solution. Rather, they solve for constraints aligned around their customer's business, their industry, and especially their own business.

It's not hard to spot when a product person is weak when it comes to thinking. While I am a big believer in encouraging questions, this presumes the person has done their homework and put in the intellectual effort to actually consider the issue first. All too often, it is obvious they have not.

I talk about the three critical characteristics of strong product teams, no matter what processes they use: the first is tackling risks early; the second is solving problems collaboratively; and the third is being accountable to results.

collaboration is not about consensus. While we like it when the product team agrees on the best course of action, we do not expect or insist on this. Rather, we depend on the expertise of each member of the product team.

if the tech lead feels a specific architecture is called for, we defer to the tech lead. If the designer feels a specific user experience is called for, we defer to the designer. Occasionally there will be conflicts and judgment calls, and normally we'll run a test to resolve them.

once the product manager has declared something is a “requirement,” it pretty much ends the conversation and moves the discussion into implementation. At this point, the designer feels like she's there to ensure that the design conforms to the company style guide, the engineers feel like they are there just to code, and we're back to Waterfall.

collaboration is also not about compromise. If you end up with a mediocre user experience, slow performance and limited scalability, and dubious value for customers, as a team you lose.

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

we need to know what we can't know, admit what we don't know, and focus on discovering a solution that works.

The very act of creating and discussing prototypes and story maps facilitates true collaboration. And if you are diligent about keeping your prototype or story map up to date, then they can also serve as an artifact—capturing the learning and decisions from the discovery work.

It's not really the prototype that's critical here, as much as the nature of the collaboration that it facilitates.

in a healthy and competent team, each member of the team is counting on the others to have done their homework and bring the necessary skills to the table.

The first is that the product manager has not done her homework and she doesn't know the various aspects and constraints of the business—sales, marketing, finance, legal, privacy, and so on—so the product team really doesn't have the information it needs to solve the problems it has been assigned (which usually means they're back to implementing features on a roadmap).

The second situation is arrogance. If the product manager believes the solution she already has in mind is clearly the best, even if she is right, collaboration is stifled, and she probably now has a team of mercenaries rather than missionaries.