Empowered: Ordinary People, Extraordinary Products

by Marty Cagan

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.

The product vision, done well, serves as the North Star for the product organization.

Just as the North Star can guide people to their destination even when they're scattered across the globe, the product vision provides this purpose for all of the product teams, no matter where they are in the organization, or on what piece of the larger product they're working.

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

Ultimately, what is the endgame? How does the work of my team contribute to this larger whole?

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?

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

The head of product is responsible for ensuring the organization has a compelling product vision, as well as the product strategy that can deliver on that 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.

to succeed, the CEO (or GM for a business unit in a very large organization) is going to need to feel a very real sense of ownership of this product vision.

the CEO will need to “sell” this vision literally thousands of times—

A visiontype is a conceptual prototype—a high‐fidelity user prototype

The visiontype describes the world once the vision is a reality—that may be 3 years or 10 years in the future.

As with a video showing off a visiontype, a storyboard focuses on the emotion and the customer experience and not on the details.

We can validate the demand for the vision.

solutions? What we can't validate is the solution.

Evangelism is something that is never finished.

we would much rather share the product vision than a product roadmap.

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.

Product principles complement the product vision by stating the values and beliefs that are intended to inform the many product decisions that will need to be made.

When we empower product teams, we are giving them problems to solve, and we are giving them the context required to make good decisions. The product vision is a major part of that context, but there will always be issues that arise during the product discovery and delivery work.

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.

What CEOs Need to Know about Design.

A product organization's team topology answers questions such as: How many product teams should our organization have? What is the scope of responsibility of each team? What are the skills required for each team, and how many of each skill? What are the dependencies between the teams?

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.

The team topology you choose needs to be a decision made by the leaders of product and design, and the leaders of engineering, working together.

Team Topologies: Organizing Business and Technology Teams for Fast Flow

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

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

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.

When alignment is high, teams generally have fewer dependencies to get things done.

the architecture is based on the product vision, as the job of the architecture is to enable the product vision.

the two fundamental types of product teams: platform teams, which manage services so they can be easily leveraged by other teams, and experience teams, which are responsible for how the product value is exposed to users and customers.

Platform teams provide leverage because they allow for common services to be implemented once but used in many places.

Platform teams also allow for managing complexity because they can encapsulate particularly difficult or specialized areas of the product.

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.

In many of the large, top tech companies, as many as half of the product teams are platform teams.

platforms reduce the cognitive load for experience teams.

experience teams are able to use platform services without having to understand h...

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.

Whether a team is customer‐facing or customer‐enabling, a true experience team will have a direct impact on our customers if its product goes down.

experience teams are most empowered when they are given as much end‐to‐end responsibility as possible.

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

the purpose of a platform team is really to enable the experience teams to better solve problems for their customers.

separating out the keep‐the‐lights‐on work, there are two main ways that platform teams are empowered to move the platform forward: shared team objectives and platform‐as‐a‐product objectives.