Marty Cagan - EMPOWERED

As such, in strong product companies, the purpose of the product team is to serve customers by creating products customers love, yet work for the business .

That is a profound difference, which impacts nearly everything about the company and how it works, and results in much higher motivation and morale. And most important, it results in a much higher level of innovation and value for customers and the business.

In most product companies, the role of true product leadership is largely missing in action.

Instead, they are mainly there as facilitators, responsible for staffing the in‐house (or even worse, outsourced) feature factory, and keeping the trains running on time.

In most companies, there is no product strategy. Notice I didn't say a bad product strategy—I mean literally no product strategy. The feature teams are simply there “to serve the business.”

The business certainly has reasons for what they request or put on the roadmaps, but they very rarely have a product strategy, or even the skills or data required to create one.

The stakeholders end up providing product teams with a prioritized list of features and projects that they need completed this quarter or this year. So, the “product strategy,” if you could even call it that, is really about trying to please as much of the business as possible.

When technology product companies moved to Agile methods over the past 10–20 years, many managers and leaders questioned whether they were still necessary, since team members would be expected to take a much more active role in how they work.

I realize this is counterintuitive to many people, but while moving to truly empowered teams does require moving away from the old command‐and‐control model of management, it does not mean you need fewer leaders and managers. It means you need better leaders and managers.

It's actually easier for a manager to manage (often micromanage) in the old command‐and‐control style. It's not hard to assign a team a list of activities, or a list of features to build, and just tell them to do the work as fast as they can.

While this command‐and‐control style may be easier for the manager, it creates teams of mercenaries with no empowerment in any meaningful sense.

In contrast, in strong product companies, the product leaders are among the most impactful leaders in the company.

They are responsible for staffing and coaching the product teams; they are responsible for the product strategy and converting the strategy into action; and they're responsible for managing to results.

Empowered product teams depend on skilled product managers, product designers, and engineers, and it is the leaders and managers who are responsible for recruiting, hiring, and coaching these people.

Further, a focused and compelling product strategy—based on quantitative and qualitative insights—is among the most important contributions of product leadership.

In most companies, the technology teams are not empowered product teams, they are what I call here feature teams .

Feature teams look superficially like a product team. They are cross‐functional, with a product manager, a product designer, and some number of engineers. The difference is that they are all about implementing features and projects ( output ), and as such are not empowered or held accountable to results.

The feature teams get to work first designing the features on the roadmap, maybe doing a little usability testing, and then proceeding to building, QA testing, and deploying the features (known as delivery ).

These feature teams sometimes claim they're doing some product discovery, but they rarely are. They've already been told what the solution should be; they're not empowered to go figure out the solution themselves. They're just there to design and then code.

In these feature teams, there is usually a person with the product manager title, but they are mainly doing project management. They are there to ensure the features get designed and delivered. Necessary perhaps, but this is not product management.

Because the teams are provided, or are pressed to provide, roadmaps of features and projects, the focus of the team is delivery —delivery of these features. And features are output. Even if someone were to complain of lack of business results, who would you hold accountable?

In contrast, in strong product companies, teams are instead given problems to solve , rather than features to build, and most important, they are empowered to solve those problems in the best way they see fit . And they are then held accountable to the results.

In the empowered product team model, the product manager has a clear responsibility, which is to ensure that the solutions are valuable (our customers will buy the product and/or choose to use it), and viable (it will meet the needs of the business). Together with a product designer who is responsible for ensuring the solution is usable , and a tech lead who is responsible for ensuring the solution is feasible , the team is able to collaborate to address this full range of risks (value, viability, usability, and feasibility). Together, they own the problem and are responsible and accountable for the results. 2

So, to summarize feature teams vs. empowered product teams:

Feature teams are cross‐functional (a product manager doing mainly project management, a product designer, plus some engineers), and assigned features and projects to build rather than problems to solve, and as such they are all about output and not business results.

Empowered product teams are also cross‐functional (a product manager, a product designer, and engineers), but in contrast to feature teams, they are assigned problems to solve , and are then empowered to come up with solutions that work—measured by outcome—and held accountable to results. 3

If you have not yet read INSPIRED , then you might be wondering: What is so wrong with the business owners and stakeholders deciding what goes on the roadmap , and therefore what the engineers should build?

This is considered the first and most important principle of product discovery: our customers, and our stakeholders, aren't able to tell us what to build .

It's not because our customers or stakeholders aren't smart or knowledgeable.

There are two fundamental reasons why our customers and stakeholders aren't able to tell us what to build:

First, the customers and stakeholders don't know what is just now possible—they are not experts in the enabling technologies, so they can't be expected to know the best way to solve the problems we're focused on, or even if the problem is possible to solve. It's often the case that innovations solve problems in ways that customers and stakeholders had no idea was possible.

Second, with technology products, it's very hard to predict in advance what solutions will work. There are many reasons why product ideas don't deliver the results we hoped. All too often we are excited about some idea, but our customers are not, so they don't buy what we thought they would. Or, we discover the idea has major privacy or security issues. Or we find out the idea will take much longer to build than anyone expected.

Empowered product teams understand these inherent issues, and product discovery is about discovering a solution that our customers love, yet works for our business .