Review: Empowered by Marty Cagan and Chris Jones

A good read on products, product teams, and product leaders and managers. A lot of the content is repeated from the book Inspired, but there is plenty of new stuff here too. Also, like Inspired, the organization of the content isn’t great: this time, it’s broken down across 80 chapters (!), which are in an odd order, and repeat a lot of the same content over and over. So it takes a lot of work to make sense of this content.

Despite that, I still found many useful insights in this book:

1. Empowered product teams

Just as in Inspired, this book strongly recommends organizing the company around empowered product teams instead of feature teams.

Feature teams are assigned projects to do or features to build by someone outside the team (e.g., execs). These teams rarely do product management; the product is already decided ahead of time for them, so most of what they are doing is actually project management. The team is entirely focused on outputs: the goal is to deliver that project or feature. Once it’s delivered, they consider their work finished; if that project or feature doesn’t achieve the desired business goals—and the first attempt almost never does—you can’t really hold the team accountable for it, as they are just doing what they are told.

Empowered product teams are assigned problems to solve. The team is entirely focused on outcomes: the goal is to deliver a specific business result. How the team achieves those outcomes—what products or features they build—is entirely up to them. To figure that out, these teams typically do a lot of product management, including product discovery work and design. If their first solution doesn’t solve the problem, they know they aren’t finished, and they will keep iterating until the desired outcome is achieved. As a result, the team will develop a much stronger sense of ownership, autonomy, purpose, and accountability, and they will start to act more like missionaries rather than mercenaries.

2. Product vision

It’s critical for empowered product teams to have a clear product vision. The product vision describes the future you’re trying to create and how this future impacts the lives of your customers. It should typically be 3-10 years out, and it should be inspiring. It should act as a “north star” that excites the team and makes them want to come to work every day.

One way to communicate the product vision is to create a visiontype. This is a high-fidelity prototype that gives a clear glimpse of what the future might look like. Unlike prototypes built for user-testing, which are typically prototypes of something you can build in the very near future, the visiontype is a prototype that looks 3-10 years out, so under the hood, the prototype is all smoke and mirrors.

You should show this visiontype to your team members and to executives; you may even want to record a video of the walkthrough. Seeing is believing, so the benefit of the visiontype is that it can be highly inspiring and unifying for everyone to get a concrete glimpse of what the future could be like. It can be a great way to get buy-in across the board.

You may also want to show this visiontype to customers. It’s very common for cusotmers to ask to see you roadmap: they do this because, if they are signing up for your product, they are as invested in its future as you are. But roadmaps change all the time, so showing them to a customer can be problematic, as either (a) you don’t end up building many of the features on the roadmap, thereby disappointing the customer or (b) you end up forced to build some feature on your roadmap, because the customer now expects it, even though you may learn it’s not the right feature to build. Showing a customer the product vision, perhaps in the form of the visiontype, is typically a better option, as it gives them a higher level glimpse of the future, which is really what they want, without committing to specific features on specific timelines.

3. Product strategy

The product strategy defines how you’re going to make the product vision a reality, while meeting the needs of the company as you go. The strategy doesn’t go into the details—those are left to the tactics—but it outlines your overall approach and the rationale for that approach. The book talks about the importance of product strategy, but I found the content on how to actually figure it out to be rather sparse.

4. Objectives and key results (OKRs)

The book doesn’t explicitly recommend using the “official” OKR system, but it does recommend that:

1. Executives define specific objectives for each team to achieve.
2. Each team defines specific results (KPIs) they will target as the way to measure that they accomplished their assigned objectives. Note that these results must come from the team, so they feel a sense of ownership in what they are committing to. That said, the executives can provide feedback on these KPIs, so this will be a back-and-forth discussion.
3. You explicitly define the level of ambition for these objectives and results. Some of them will be moon shots, where you’re aiming for a massive (10x) improvement, which is a high risk / high reward endeavor where everyone agrees that the odds the team achieves the goals are relatively low. Some of them will be roof shots, which are more conservative and achievable, and everyone agrees that the odds the team achieves the goal are quite a bit higher. And some of them will be high integrity commitments, for tasks where the team is expected to succeed 100% of the time. You’ll want to have a mix of moon shots, roof shots, and high integrity commitments each quarter.
4. It is OK for multiple teams to have the same or overlapping objectives and for teams to collaborate on these objectives.
5. Teams can only be held accountable for objectives if they are empowered product teams that can determine how they achieve those objectives. If they are a feature team, where they don’t have that control, then there is no way you can hold them accountable.
6. Every team has some level of “keep the lights on” activity that will not be accounted for in their objectives. They should factor this in when making commitments to ensure they aren’t overcommitting.

5. Managers and coaching

Managers play a central role in the success of empowered product teams—here, we are talking about the people managers that are part of the empowered product team and not a higher level directors or executives—and one of the most important roles a manager can play is as a coach. The goal of the manager is to develop the skills of the people on their team. This is not about micromanaging them, but about systematically identifying each person’s strengths and weaknesses, and working with them to address those weaknesses.

One way to do this is to:

1. Systematically identify the specific skills needed for each role on a team (the skills taxonomy).
2. Do a gap analysis where the manager determines the expectation for each skill on a 10-point scale and the employee’s current capability rating for each skill. The manager should always set the expectation—this is often tied to the person’s current “level” in the company, their role, and the team’s needs—and the manager and employee should jointly assess the employee’s current capability: e.g., the manager provides their assessment, the employee provides a self-assessment, and then you discuss any discrepancies. For example, the manager might expect their senior engineer to be at 9/10 on a system design skill, but you both discuss it, and realize that the engineer is currently a 6/10.
3. You then create a coaching plan to help the employee improve on any skills where they are below expectations. Typically, you’ll want to focus the plan on the top-three areas where there are gaps, rather than trying to take on everything at once. The plan can include coaching from the manager, coaching or mentoring from other co-workers, classes, books, and so on.
4. Meet with the employee at least weekly in 1:1s, and, amongst other things, see how they are doing against the coaching plan. Repeat the self-assessment from time to time, and as the employee improves, you may want to update their level (i.e., give them a promotion), the expectations, and the coaching plan.

“Every member of a product team deserves to have someone who is committed to helping them get better at their craft.”

This is one of the reasons that in most strong product organizations, engineers report to engineering managers, designers report to designers, product managers report to product managers, and so on.

6. Ramping up PMs

The book talks about the manager’s role in ramping up a PM. In addition to the coaching plan mentioned in the previous section, there are a few other tips I found useful:

1. The new PM should meet with at least 15 customers as part of their ramp up. In some cases, they will need to meet with far more (e.g., 30 or 50). Chatting with customers, seeing how they work, seeing the issues they struggle with, and understanding the industry is essential for any PM to be able to build products for that industry.
2. The PM needs to become very familiar with industry trends. Some of this they can learn from chatting with customers, as per the previous point, but some of it they will get by doing lots of industry research. But the PM will also need to do lots of other research, reading about the industry, experiencing the problems first hand where possible, and so on.
3. A key part of this research is doing a competitive analysis to understand what solutions are available. A good practice is for the new PM to evaluate the top 3-5 competitors out there and write up a document that includes a comparison of their strengths and weaknesses, as well as opportunities.

7. The 6-page narrative

A technique used by companies such as Amazon is to have PMs write up a 6-page narrative as the starting point for any new product initiative. This narrative is not a spec. A spec describes is a “how to” document that provides the details on how to build something; that comes later. The 6-page narrative is a “why” document, written in a narrative format, that is designed to convince the team that this product initiative is worth doing. It should be about 6 pages long, it should be inspiring and persuasive, it should lay out the goals and address key risks, and it should stand completely on its own (so anyone can read it at any time and be equally persuaded). In Amazon’s product review meetings, they spend the first ~20 minutes of the meeting quietly reading the 6-page narrative, and then the rest of the meeting discussing it.

8. Rewarding success

The book has a brief mention of ways managers can reward employees. You can of course give people promotions, salary increases, bonuses, and more equity, but one of the nice ideas in here is to also provide more personalized gifts, such as:

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

6. Interview question

The book includes an interesting interview question that’s better than the traditional “what are your strengths and weaknesses?” formulation. The idea is to ask the candidate to stack rank their abilities across four broad work attributes:

1. Execution: how good are you at getting things done, doing the right thing without being asked, and tracking many concurrent tasks?
2. Creativity: how often are you the person in the room with the most or best ideas?
3. Strategy: how good are you at looking at the big picture, figuring out the higher level context, and communicating that to others?
4. Growth: how good are you at multiplying effort through process and team management?

The key point is that the candidate has to rank these in some order, and talk about which of these they are good at, and where they have room to grow. This can be far more revealing about that candidate’s strengths and weaknesses, as well as how self-aware, transparent, and honest they are.

9. The artifact trap

One trap team members often fall into is to start producing artifacts for each other and debating those artifacts rather than working together to try to figure out how to solve the underlying problem. For example, the PM might send a spec to the designer; the designer might send a mock up to the engineer; the engineer might come up with a list of tasks for the PM; and so on. The entire work process starts to focus entirely on these artifacts (the outputs) and you quickly lose sight of the original problem you were trying to solve (the outcomes). This can also lead to a lot of fighting, as you start to argue about details of the artifacts, forgetting that you are all on the same team, working to solve the same problem.

The way to solve this is to get everyone in the same room or on the same video call and chat live. It may feel inefficient to do this, but this live chat allows you all to come back to the “how do we solve this problem discussion,” which is the only way to move forward.

Rating: 4 stars