Empowered: Ordinary People, Extraordinary Products

by Marty Cagan

A good product vision serves as the North Star for the product organization so that we have a common understanding of what we are hoping to accomplish together.

A good product vision inspires ordinary people to create extr...

A good product vision provides us with meaningful work. A list of features on a roadmap is not meaningful. How you can positively impact the liv...

A good product vision leverages relevant industry trends and technologies that we believe can help us solve problems for our customer...

A good product vision provides the engineering organization with enough clarity about what's coming in the next several years so they can ensure they have in pl...

The product vision is a primary driver of the...

it's also important to not be too detailed or prescriptive, which runs the risk of product teams confusing the vision with a specification.

The product vision is one of our primary tools for keeping the organization truly focused on what the customer cares about.

While we need to understand the impact on our company, we need to never forget that all of the benefits derive from providing real value to our customers.

When we tell the story of the product vision, we do so from the perspective of our users and customers. The idea is to demonstrate how their lives will improve in some meaningful way.

Our job as the broader product organization then is to figure out how to deliver on the promise of the vision. This requires an intentional product strategy, and years of continuous discovery and delivery.

The product vision represents the common goal and constantly reminds us of the larger purpose.

Your team may be responsible for one component of the product vision, but we need each and every product team to understand the bigger picture: Ultimately, what is the endgame? How does the work of my team contribute to this larger whole?

it makes no sense for each product team to have their own product vision. That would totally miss the point. The product vision is meant to be the common goal.

The product vision describes the future you are trying to create. In what ways will you improve the lives of your customers?

You are not trying to explain how you will get there—that is to come from the product strategy and the product discovery work. For now, we are just trying to describe what the end state is and why it is so desirable.

Normally, the timeframe for the product vision is between 3 and 10 years out.

As product leaders, you need to decide which are trends and which are fads and, most important, which trends have the opportunity to substantially help you deliver innovative solutions for your customers.

Most of the time, our product vision leverages one or more major industry trends.

Remember that customers don't care about our technology—they care about how well we solve their problems. So, while we may make a bet on specific technologies, we must always keep in mind the purpose of that technology is to solve problems in ways that customers love.

in order to come up with a compelling product vision, the head of product will need to work very closely with the head of design and the head of technology. The product vision is a critical collaboration between the customer experience, the enabling technologies, and the needs of the business. It will likely require the talents and best efforts of all three.

Good product leaders are skilled at helping others feel shared ownership.

It's worth investing some real time and effort into the best way to communicate the product vision. Remember that the vision's purpose is to inspire.

while it's good to know we are working on a worthy problem, that's not enough. People will only buy if they believe we have solved the problem well enough to get them to switch.

pursuing a product vision is largely a leap of faith. We're betting on ourselves; that we'll be able to discover a solution that delivers on the promise of the vision.

Your company's executives, investors, stakeholders, sales and marketing staff, customer service and customer success staff, and key influencers from across the company and beyond—you need all of these people to understand the future you are trying to create.

Evangelism is something that is never finished. You need to plan on delivering the message multiple times, to the same people, and you need to expect that just because someone is convinced one day, this does not mean they will be convinced the next.

we would much rather share the product vision than a product roadmap. Though the customers don't generally use this terminology, the product vision is usually what they're hungry

Remember: stubborn on vision, but flexible on details. Sharing the vision is fine, but sharing a roadmap is very dangerous.

The engineering organization needs the product vision so that they can ensure that the architectural decisions they make will serve the needs of that product vision.

for the majority of normal product decisions, we can provide the team with the information they need. The product principles play a major role in this.

So many decisions revolve around trade‐offs, and the product principles help to illuminate the values we prioritize when we make these trade‐offs. The product team needs to understand these principles and the reasoning behind each one.

As the product leaders create the product vision, I encourage them to also prepare a set of product principles to complement the vision, and to think through and provide as much guidance to the product teams regarding ethics as possible.

a director's highest responsibility is to bring to bear the best of what each team member has to offer in service of the shared goal. Rarely is the director the most highly skilled at any of the jobs that others on her team do. Of course, she must be knowledgeable so that she can appreciate, support, and grow each person on the team, but she isn't the best, and in some ways, that's the point.

your topology choices should be guided by principles that support team empowerment. These include giving teams real ownership of the space of problems they will be responsible for, providing autonomy in their ability to deliver the solutions to the problems they're asked to solve, and alignment with various aspects of the company's customers, business, and technology.

Optimizing for empowerment requires balancing three interrelated goals: ownership, autonomy, and alignment.

Ownership is bigger than just the team's objectives. It sets the scope of each team's full responsibilities around functionality, experience, quality, performance, and technical debt. Teams are expected to make the necessary trade‐offs to best address the work that fits into their scope of ownership.

Empowerment improves when each product team has something meaningful that they are responsible for.

Empowerment doesn't just depend on the scope of ownership—it also requires clarity of ownership. When teams are unclear on which work applies to them, their empowerment is undermined. While you should expect that there will always be occasional cases where ownership of work is ambiguous, a good topology should resolve more ownership questions than it raises.

Autonomy is a powerful concept, yet is often misunderstood by leadership and product teams alike. It does not mean that a team should never have dependencies on other product teams. Nor does it mean that a team is allowed to go off and pursue whatever it likes.

Autonomy does mean that when we give teams problems to solve, they have enough control so that they can solve the problem in the best possible way that they see fit. A topology that results in too many dependencies can make this difficult.

Alignment refers to how well the boundaries between teams track with other aspects of the strategic context. When alignment is high, teams generally have fewer dependencies to get things done. They can make faster decisions and are more connected with business‐level outcomes. In short, when alignment is high, empowerment is improved.

Alignment is typically the most complicated aspect of topology because there are so many dimensions to consider. The two most significant of these are the architecture and the business.

Keep in mind that there will never be a single “perfect” team topology for your organization. There are many trade‐offs to consider, but the overarching objective is to optimize for empowerment. The best way to do this is through driving ownership, autonomy, and alignment.

in many of the top product organizations, the best engineers in the company are asked to work on platform teams because of the leverage and importance.

platforms reduce the cognitive load for experience teams.

Experience teams are responsible for how the product is experienced by users in the form of apps, UIs, solutions, or journeys.

if a product team is working on the experience for anyone who is part of the company's customers—including consumers—this is called a customer‐facing experience team.

If a product team is working on a product experience for these types of internal employees, this is called a customer‐enabling experience team.

Platform teams raise the level of empowerment for other teams by abstracting away the underlying complexity of the services and the architecture.