Empowered: Ordinary People, Extraordinary Products

by Marty Cagan

One of the reasons that I love working with designers and engineers so much (and also why I love to recruit designers and engineers into product management) is that thinking is at the very core of what they do.

Similarly, 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. Is this something their customers need? Is it substantially better than the alternatives? Is it something the company can effectively market and sell, that they can afford to build, that they can service and support, and that complies with legal and regulatory constraints?

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? Which is why critical thinking and problem‐solving skills are so important.

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.

The Book in a nutshell -one of the key insights

First, 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. Generally speaking, 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.

True collaboration is linked to accountability

Second, 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. Why is that? Because 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.

Third, 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 (so the rest of our company can effectively market, sell, and support the solution). In order to do...

My favorite way to actually do this is to sit around a prototype (usually created by the designer) so as a team you can consider and discuss the proposed solution on the table. The designer can consider different approaches to the experience, the engineers can consider implications of different approaches and the potential of different enabling technologies, and the product manager can consider the impacts and consequences of each potential direction (e.g., would there be privacy violations, or would this be something that would work with our sales channel?).

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.

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). That's why we discussed early in this part on coaching that, as a manager, your first priority is to assess the product manager and create a plan to get her to competence.

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.

It is natural for the prospect to try to dictate requirements for features, but your job is to work to understand their underlying issues and constraints, and then work collaboratively with your prospective customers to determine if there's a general solution that will meet their needs. This form of collaboration is at the heart of the customer discovery program technique.1

Or with stakeholders

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.

Getting good at true collaboration is at the heart of how strong product teams work. It's a combination of skills and mindset, and it often takes active coaching by the manager to...

The product manager is not there to “gather requirements” from stakeholders, but the product manager is also not there to dictate solutions to stakeholders. Rather, the strong product manager understands that each stakeholder is responsible for some key aspect of the business, and they are a key partner in helping to come up with a solution that works.

Again, a constructive, collaborative relationship with stakeholders is predicated on the product manager having done her homework so she can be that effective partner with the stakeholder, and not just some form of facilitator or project manager.

Collaborating with stakeholders and executives involves listening carefully to try to understand the constraints, and thinking hard about solutions that would work for our customers and our business.

This begins by the manager coaching her product people on the role of each stakeholder, and why they are there, what they are concerned about and why, and what they need to succeed at their jobs.

Try this exercise: Have the PM write down the list of people with whom she regularly collaborates. Add to the list any stakeholders whose input she regularly needs. Next, circle the three to five names that are most important to her having a successful outcome in her work. Finally, circle the names of the one or two people she most dreads having to deal with. Congratulations! You've identified the list of relationships in which this PM needs to invest.

Important Exercise!!!!!!!

Encourage her to get to know their interests outside of work, and if it's comfortable, to share her own. This is a time to be genuine. It's about creating a foundation for trust.

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.

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.

An experienced manager can coach a product person through these many types of situations and make all the difference to the career of a new product person: identifying and avoiding the landmines, understanding the priorities and the larger context, and navigating the personalities.

The feature team product/project manager role is still difficult, and integrity is still important, but in this case the product manager is fundamentally a messenger. She passes along requirements, constraints, and dates to the product team, and passes back concerns, status, or bad news up to management.

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

This means not making a commitment unless and until her product team has had the opportunity to do sufficient product discovery to reasonably consider the risks of value, usability, feasibility, and viability. And just to be explicit, that means leaning on the expertise and experience of the designer and engineers. Moreover, 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.

(As an important side note, 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.

While project managers often resort to imposing deadlines, if you hope to have an empowered team of missionaries, the product manager needs to instead share the overall purpose of the work.

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

Consider the case where the engineers take much longer to deliver something than expected. Well, did the product manager fully appreciate the feasibility risk here? Did she elicit and then listen to the engineers' concerns? A quick feasibility prototype very likely would have uncovered the true cost during product discovery.

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.

If the decision is primarily about enabling technology, if at all possible, we defer to our tech lead. If the decision is primarily about the user or customer experience, if at all possible, we defer to our product designer. And if the decision is primarily about business viability, we will depend on the product manager collaborating with the relevant stakeholders.

Suppose, for example, the tech lead and the designer disagree on an approach because the tech lead considers the design unnecessarily difficult to implement, yet the designer considers this design necessary to the experience. This is where it's critically important for the product team to know when and how to run a test.

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.

Organizing Effective Meetings Here's how I coach product teams on meetings.

the bottom line for meetings is (a) make sure that if you call a meeting it is truly necessary and warrants the time of all the attendees, and (b) prepare for the meeting to make sure it is efficient, effective, and accomplishes its purpose.

This is what bad managers don't do

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)

Speak up in a thoughtful way, raise your concerns, but not in a holier than thou nor accusatory way. Try to explain in a way that makes it clear that you care about protecting the best interests of the company.

This is the tone I should keep in mind when writing and pointing out issues in large enterprises

strongly encourage you to read Rob Chesnut's excellent book, Intentional Integrity: How Smart Companies Can Lead an Ethical Revolution (New York: St. Martin's Press, 2020).

That old saying about people joining a company but leaving a manager is unfortunately demonstrated every day.

emphasize how important it is that the manager focus at least weekly on whether each of her product people feels she is doing meaningful work, progressing in her career, and building the necessary relationships with her team and with the execs that enable her to effectively and successfully lead an empowered product team.

I want them to like me for very specific reasons. I want them to believe that I am committed to helping them succeed professionally and personally. I want them to trust me so that I can be honest with them and give them the feedback that's so essential to their growth. I want them to be able to look back on their time working with me as among their favorite in their career.

A nice bottle of wine A book I think she would enjoy A ticket to an industry conference or event A gift certificate for a nice local restaurant A weekend getaway for two

Bill would say that he had a different way of measuring his impact, his own kind of yardstick. I look at all the people who've worked for me or who I've helped in some way, he would say, and I count up how many are great leaders now. That's how I measure success.

Here's a remarkably common example of that. I often meet technology executives that have built a reputation for absolutely dependable execution. They have consistently put in the effort and delivered what they had promised. In many cases, they have had to move mountains to deliver, but they did. They are known for their reliable execution and that is a large part of their identity. But now the leader has been promoted to the level where her personal effort can't scale, and her teams feel like they are being micromanaged. The self‐awareness that is needed here is to realize that the skills that got her to this level won't get her to the next level.

It takes courage to make space for teams to learn and make mistakes. It takes courage to give meaningful and honest feedback. It takes courage to take this leap of faith that trusting your team will have better results than just trusting in yourself. It takes courage to leave your tactical skills behind and move into the world of strategy. It takes courage to be vulnerable.

Rules of engagement are simply an agreement with the teams on what type of visibility the leader needs in order to give the teams the space they need to work. What information does the leader need in order to trust? What context does the team need to understand to be successful? What does the team need to feel safe in surfacing risks and problems early or asking for help?

This would be helpful for tribe leads and division leads

Every leader's journey is different, but I have found over the years that if a leader truly wants to improve, and has the courage to take the leap of faith necessary to learn to trust others, that they can indeed disrupt themselves and become the leader their company needs, and that their employees deserve.

the best product companies hire competent people of character, and then coach and develop them into members of extraordinary teams. This is why staffing and coaching go hand in hand.