What do you think?
Rate this book
Empowered: Ordinary People, Extraordinary Products
What is it about the top tech product companies such as Amazon, Apple, Google, Netflix and Tesla that enables their record of consistent innovation? Most people think it’s because these companies are somehow able to find and attract a level of talent that makes this innovation possible. But the real advantage these companies have is not so much who they hire, but rather how they enable their people to work together to solve hard problems and create extraordinary products. As legendary Silicon Valley coach--and coach to the founders of several of today’s leading tech companies--Bill Campbell said, “Leadership is about recognizing that there's a greatness in everyone, and your job is to create an environment where that greatness can emerge.” The goal of EMPOWERED is to provide you, as a leader of product management, product design, or engineering, with everything you’ll need to create just such an environment. As partners at The Silicon Valley Product Group, Marty Cagan and Chris Jones have long worked to reveal the best practices of the most consistently innovative companies in the world. A natural companion to the bestseller INSPIRED, EMPOWERED tackles head-on the reason why most companies fail to truly leverage the potential of their people to innovate: product leadership. The book covers: EMPOWERED puts decades of lessons learned from the best leaders of the top technology companies in your hand as a guide. It shows you how to become the leader your team and company needs to not only survive but thrive.
416 pages, Hardcover
Published December 3, 2020
Ratings & Reviews
Friends & Following
Create a free account to discover what your friends think of this book!
Community Reviews
Displaying 1 - 30 of 233 reviews
August 26, 2023
"Empowered" is the best science fiction book of 2020.
Reading "Empowered" I caught myself having a strange feeling - like I was reading a good science fiction book. Everything described made perfect sense, it is smart and believable. And yet the world Marty describes feels not totally real to me. Like a utopia we all are trying to reach but still miles away from being there.
Reading "Empowered" I caught myself having a strange feeling - like I was reading a good science fiction book. Everything described made perfect sense, it is smart and believable. And yet the world Marty describes feels not totally real to me. Like a utopia we all are trying to reach but still miles away from being there.
February 14, 2021
Having read 2/3s of it, I consider this book really flat vs the expectation I built up from others’ fascination and it seems more like a hype to me. I started reading in in anticipation of learning more about successful product management. What I got, however, was a superficial collection of topics to lead product teams structured along 81 chapters.
That’s actually where my first criticism starts: a large number of chapters have very few pages. Often, it seems more like the authors brush over something adjacent that they have no expertise or deeper insight to discuss (e.g.; Chapter 17: Stakeholder Collaboration - 3 pages, Chapter 39: Product Principles and Ethics, Chapter 68: Business Results - 2 pages). As a consequence, one learns little more than that this topic is also important, needs to be taken care of, and can be a cause of ineffectiveness. It often triggered a “you don’t say” reaction in me.
Following this first point, I notice as a second that this seems more like a “look-up” resource, a sort of “product wiki” which you can look up basic terms of product management. Examples would be: “what is team topology”, what are team OKRs”, “what is product evangelism”. It’s good to look up a first piece of information on any subject; but you will rarely find something really enlightening. One illustrative quote is below:
“Evangelism Skills
Especially in medium to large-sized companies, so much of product involves persuasion. This involves convincing your team and your stakeholders that you understand what you need to do, and you've got a solid plan to deliver.“
What 2 stars then?
1. Benefit of the doubt for the remaining 1/3
2. I found it useful the put a name to the often observed phenomenon of a “feature team” - building stuff organized on backlog/roadmap versus a “product team” (platform or experience) which is not there to “serve the business” and “deliver capacity” but truly build great product under a multi-year vision.
3. I quite liked the Product Manager profiles and understanding how some leaders have put this in action. (again short 2-3 pages long)
That’s actually where my first criticism starts: a large number of chapters have very few pages. Often, it seems more like the authors brush over something adjacent that they have no expertise or deeper insight to discuss (e.g.; Chapter 17: Stakeholder Collaboration - 3 pages, Chapter 39: Product Principles and Ethics, Chapter 68: Business Results - 2 pages). As a consequence, one learns little more than that this topic is also important, needs to be taken care of, and can be a cause of ineffectiveness. It often triggered a “you don’t say” reaction in me.
Following this first point, I notice as a second that this seems more like a “look-up” resource, a sort of “product wiki” which you can look up basic terms of product management. Examples would be: “what is team topology”, what are team OKRs”, “what is product evangelism”. It’s good to look up a first piece of information on any subject; but you will rarely find something really enlightening. One illustrative quote is below:
“Evangelism Skills
Especially in medium to large-sized companies, so much of product involves persuasion. This involves convincing your team and your stakeholders that you understand what you need to do, and you've got a solid plan to deliver.“
What 2 stars then?
1. Benefit of the doubt for the remaining 1/3
2. I found it useful the put a name to the often observed phenomenon of a “feature team” - building stuff organized on backlog/roadmap versus a “product team” (platform or experience) which is not there to “serve the business” and “deliver capacity” but truly build great product under a multi-year vision.
3. I quite liked the Product Manager profiles and understanding how some leaders have put this in action. (again short 2-3 pages long)
January 16, 2021
While the 'Inspired' book focused on product development techniques, Empowered focused on people and organisation. I had a couple of epiphany moments while reading it, as I felt that words were finally put on some of the challenges I observe. Complete book on how to shape a great organisation, including a detailed case study. It's definitely a book to put in the hands of people managing tech/ux/data/product teams.
January 27, 2021
Direct continuation of "Inspired" - it picks it up where "I" has left it, so a reader doesn't have to go through the basic terminology, but "stacks up" more upon the foundations.
The form is equally good - clear, concise, to-the-point. It's not really based on facts and anecdotes - more like a synthesis of highly opinionated thoughts. But in my case I wasn't eager to question anything - my observation and experiences match the learnings Cagan brings to the table.
What are the concepts this book is about? There's a lot about coaching, effective decision making, staffing and shaping up the team topology, the importance of proper product vision and strategy. In general - very good stuff and worth reading through.
What didn't I like? The case study felt very dry - I'd rather prefer some real life cases with fact-based anecdotes backing up Cagan's statements. But still - I honestly recommend "Empowered" - both money and time well spent.
The form is equally good - clear, concise, to-the-point. It's not really based on facts and anecdotes - more like a synthesis of highly opinionated thoughts. But in my case I wasn't eager to question anything - my observation and experiences match the learnings Cagan brings to the table.
What are the concepts this book is about? There's a lot about coaching, effective decision making, staffing and shaping up the team topology, the importance of proper product vision and strategy. In general - very good stuff and worth reading through.
What didn't I like? The case study felt very dry - I'd rather prefer some real life cases with fact-based anecdotes backing up Cagan's statements. But still - I honestly recommend "Empowered" - both money and time well spent.
September 11, 2022
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.
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.
October 1, 2022
I tried reading this book a year ago when I’d just left what I think Marty would describe as a “Product organization”. Back then, I didn’t finish it. It all seemed too obvious to me. I didn’t understand why anyone would need to write this book. Who would they write it for. It felt to me like Marty wrote a book explaining how to breathe.
Then I changed jobs. I realized my worldview was limited. Not every organization does Product the way Marty describes. Not everyone understands. Perhaps there is an audience for this book after all.
But I’m not convinced this book goes deep enough. Not convinced it will help organizations change. The words ring true, but change is hard. The descriptions are too vague. If I didn’t have the benefit of experience in a Product organization, I’m not sure I’d know what to do. And since I do have that experience, this book didn’t teach me anything new.
Then I changed jobs. I realized my worldview was limited. Not every organization does Product the way Marty describes. Not everyone understands. Perhaps there is an audience for this book after all.
But I’m not convinced this book goes deep enough. Not convinced it will help organizations change. The words ring true, but change is hard. The descriptions are too vague. If I didn’t have the benefit of experience in a Product organization, I’m not sure I’d know what to do. And since I do have that experience, this book didn’t teach me anything new.
January 3, 2021
EMPOWERED is essential reading for the product leaders of companies building technology products, which includes the CEO, Head of Product and Product/Design/Engineering Leads. It describes how most tech companies today use feature teams, whereas the most successful tech companies use the empowered team model, and it provides the reader with a manual of how to transform from feature- to empowered teams. Aspiring product managers, designers and engineers and those looking to start their own company can benefit from this book to get it right from the start.
EMPOWERED is the 2nd book by Marty Cagan of the company SVPG. Marty's first book INSPIRED was directed at product managers, whereas EMPOWERED (written together with Chris Jones) targets product leaders; those who lead product managers, designers and engineers (this person's role can have different titles partly based on company size; it can be the CEO, the CPO or the Head of Product, as well as the leaders of design and engineering).
The hero of the story is the company using the empowered product team model, such as Amazon, Google, Apple, Netflix and Tesla. Empowered product teams are best at "discovering a solution that our customers love, yet works for the business" (p. 11). The book EMPOWERED is about, as mentioned on the cover, "product leadership lessons from the world's top tech companies".
The book covers:
- How empowered product teams are different from the "feature teams" used by most companies to build technology products
- Transforming the company from feature teams to empowered product teams, by:
- Recruiting and coaching the members of the product teams
- Creating an inspiring product vision and product strategy
- Assigning empowered product teams problems to solve, rather than features to build
The authors introduce the villain of their story in Part 1 of the book; the company that employs 'mercenaries' and organizes them in subservient 'feature teams' who exist to 'serve the business'. They see technology as a cost of doing business, instead of the core enabler of the business. Therefore they are open to outsourcing software developers (engineers). These companies do not have a bad product strategy; they completely lack one. The company Pandora is presented as arch enemy, due to it's process of letting stakeholders "buy" features. For the authors, this is a clear example of how NOT to do product (p. 247). Proof is presented in the form of a dwindling share price for Pandora, which started at $16 and ended at $8 before the company got sold off.
Empowered product teams are cross-functional (a product manager, a product designer, and a engineering/tech lead), who are assigned problems to solve rather than features to build, and are empowered to come up with solutions that work. They are measured by outcome (not output) and are held accountable to results. These companies would not consider outsourcing these roles.
The product manager is responsible for ensuring that the solution is valuable (that customers choose to buy and use it) and viable (that it meets the needs of the business). The product designer ensures the solution is usable, and the engineer ensures the solution is feasible. The designer and tech lead contribute more than usability and feasibility, but this is about responsibility and accountability for each type of product risk (p. 10).
The argument for empowered product teams over feature teams, is that they achieve better results for the business. The authors argue that "our stakeholders aren't able to tell us what to build." (p. 10), as they don't know what is just now possible using new technology. Furthermore, with technology solutions it's very hard to predict in advance which solutions will work (p. 11); the empowered product teams are best-positioned to iterate towards a solution with the best fit. Empowered product teams understand these inherent issues, and they are about "...discovering a solution that our customers love, yet works for the business" (p. 11).
The book kicks off in Part I with a description of how tech companies should work, along the lines of the topics:
- The role of technology
- Coaching
- Staffing
- Product vision
- Team topology
- Product strategy
- Team objectives
- Relationship with the rest of the business
- Empowered teams
In Chapter 81 'The Destination', the authors go over how the tech company using empowered product teams goes about, using the same topics as in Part I.
The authors provide case studies and build upon their extensive experience building (digital) products, which is believable and their arguments are convincing. However, the authors could provide more and better proof. An example of such proof that the authors do provide, is the 'negative' proof for why Pandora is an example of how not to do product; a dwindling share price. The authors leave implicit that Amazon, Google, Apple, Netflix and Tesla have delivered fabulous financial returns to their shareholders - which indeed they have. However, one can ask whether the empowered team model is really the core driver of these results, and conversely how many tech companies have used the empowered team model but went bust nevertheless? Academically-speaking; is it correlation, or causation?
Overlap: the authors write extensively on Coaching and also Staffing, the content of which has great overlap with the book High Output Management by Andy Grove. There is also extensive overlap between this book and Marty's previous book INSPIRED. Furthermore, if you follow the SVPG blog you will recognize content from previously published blog articles.
The authors provide 8 'Leader Profiles' in the form of chapters that close off 8 of the Parts of the book. I found these profiles not very valuable, due to being short (ca. 4 pages each) but ambitious in the topics they cover. This results in quite general, 'high-over' material. I found more value in the the company case study of a jobs marketplace company (Part VIII) and also The Guardian (Chapter 77) was more meaningful to me, as it's written from the experience of Marty who was in a product role at the company at the time, and as the chapters are more lengthy, it provides more context and detail.
Something I noticed; the book is written by 2 authors Marty and Chris, and at the beginning of the book they explain that they do not mention which author has written which chapters, because they agree so much on the content. However, in some chapters you can read "I (Marty) ... ", which makes you wonder why.
EMPOWERED is the 2nd book by Marty Cagan of the company SVPG. Marty's first book INSPIRED was directed at product managers, whereas EMPOWERED (written together with Chris Jones) targets product leaders; those who lead product managers, designers and engineers (this person's role can have different titles partly based on company size; it can be the CEO, the CPO or the Head of Product, as well as the leaders of design and engineering).
The hero of the story is the company using the empowered product team model, such as Amazon, Google, Apple, Netflix and Tesla. Empowered product teams are best at "discovering a solution that our customers love, yet works for the business" (p. 11). The book EMPOWERED is about, as mentioned on the cover, "product leadership lessons from the world's top tech companies".
The book covers:
- How empowered product teams are different from the "feature teams" used by most companies to build technology products
- Transforming the company from feature teams to empowered product teams, by:
- Recruiting and coaching the members of the product teams
- Creating an inspiring product vision and product strategy
- Assigning empowered product teams problems to solve, rather than features to build
The authors introduce the villain of their story in Part 1 of the book; the company that employs 'mercenaries' and organizes them in subservient 'feature teams' who exist to 'serve the business'. They see technology as a cost of doing business, instead of the core enabler of the business. Therefore they are open to outsourcing software developers (engineers). These companies do not have a bad product strategy; they completely lack one. The company Pandora is presented as arch enemy, due to it's process of letting stakeholders "buy" features. For the authors, this is a clear example of how NOT to do product (p. 247). Proof is presented in the form of a dwindling share price for Pandora, which started at $16 and ended at $8 before the company got sold off.
Empowered product teams are cross-functional (a product manager, a product designer, and a engineering/tech lead), who are assigned problems to solve rather than features to build, and are empowered to come up with solutions that work. They are measured by outcome (not output) and are held accountable to results. These companies would not consider outsourcing these roles.
The product manager is responsible for ensuring that the solution is valuable (that customers choose to buy and use it) and viable (that it meets the needs of the business). The product designer ensures the solution is usable, and the engineer ensures the solution is feasible. The designer and tech lead contribute more than usability and feasibility, but this is about responsibility and accountability for each type of product risk (p. 10).
The argument for empowered product teams over feature teams, is that they achieve better results for the business. The authors argue that "our stakeholders aren't able to tell us what to build." (p. 10), as they don't know what is just now possible using new technology. Furthermore, with technology solutions it's very hard to predict in advance which solutions will work (p. 11); the empowered product teams are best-positioned to iterate towards a solution with the best fit. Empowered product teams understand these inherent issues, and they are about "...discovering a solution that our customers love, yet works for the business" (p. 11).
The book kicks off in Part I with a description of how tech companies should work, along the lines of the topics:
- The role of technology
- Coaching
- Staffing
- Product vision
- Team topology
- Product strategy
- Team objectives
- Relationship with the rest of the business
- Empowered teams
In Chapter 81 'The Destination', the authors go over how the tech company using empowered product teams goes about, using the same topics as in Part I.
The authors provide case studies and build upon their extensive experience building (digital) products, which is believable and their arguments are convincing. However, the authors could provide more and better proof. An example of such proof that the authors do provide, is the 'negative' proof for why Pandora is an example of how not to do product; a dwindling share price. The authors leave implicit that Amazon, Google, Apple, Netflix and Tesla have delivered fabulous financial returns to their shareholders - which indeed they have. However, one can ask whether the empowered team model is really the core driver of these results, and conversely how many tech companies have used the empowered team model but went bust nevertheless? Academically-speaking; is it correlation, or causation?
Overlap: the authors write extensively on Coaching and also Staffing, the content of which has great overlap with the book High Output Management by Andy Grove. There is also extensive overlap between this book and Marty's previous book INSPIRED. Furthermore, if you follow the SVPG blog you will recognize content from previously published blog articles.
The authors provide 8 'Leader Profiles' in the form of chapters that close off 8 of the Parts of the book. I found these profiles not very valuable, due to being short (ca. 4 pages each) but ambitious in the topics they cover. This results in quite general, 'high-over' material. I found more value in the the company case study of a jobs marketplace company (Part VIII) and also The Guardian (Chapter 77) was more meaningful to me, as it's written from the experience of Marty who was in a product role at the company at the time, and as the chapters are more lengthy, it provides more context and detail.
Something I noticed; the book is written by 2 authors Marty and Chris, and at the beginning of the book they explain that they do not mention which author has written which chapters, because they agree so much on the content. However, in some chapters you can read "I (Marty) ... ", which makes you wonder why.
March 29, 2021
Un résumé m'aurait suffit. Je cherche des livres qui vont m'apporter de l'expertise très pointue, donc j'ai été déçue, surtout après Inspired.
C'est un livre qui traite quasi exclusivement sur l'organisation, la structuration et le management d'une équipe produit, sans que ça soit très précis. Je n'ai rien trouvé de vraiment actionnable, c'est très conceptuel et général.
L'enjeu est de créer des équipes de missionnaires, qui vont s'attaquer à un problème, plutôt qu'une équipe de mercenaires qui va livrer des features.
Il y a quelques idées intéressantes pour l'onboarding et la formations des Product Managers, sous forme de Bootcamp, avec une session intensive de discovery utilisateur et de debrief pour coacher les product sur l'identification des problèmes à résoudre pour les clients
C'est un livre qui traite quasi exclusivement sur l'organisation, la structuration et le management d'une équipe produit, sans que ça soit très précis. Je n'ai rien trouvé de vraiment actionnable, c'est très conceptuel et général.
L'enjeu est de créer des équipes de missionnaires, qui vont s'attaquer à un problème, plutôt qu'une équipe de mercenaires qui va livrer des features.
Il y a quelques idées intéressantes pour l'onboarding et la formations des Product Managers, sous forme de Bootcamp, avec une session intensive de discovery utilisateur et de debrief pour coacher les product sur l'identification des problèmes à résoudre pour les clients
October 25, 2022
So superficial that I can't give more than a 3/5 rating. The case study was decent though but writing 81 chapters and almost never covering how to actually do something with actionable advice is quite the feat. Most chapters are filled with platitudes that I agree with "1:1s are for the direct" or "you have to assign problems and provide strategic context". If you dig practical books like me you will have to keep looking though.
For OKRs read Radical Focus. For actually managing a team read The Effective Manager. For broader reads on Product Management I've enjoyed Melissa Perri, Teresa Torres and Laura Klein so much more.
For OKRs read Radical Focus. For actually managing a team read The Effective Manager. For broader reads on Product Management I've enjoyed Melissa Perri, Teresa Torres and Laura Klein so much more.
May 7, 2021
I felt this was good, and in the early parts, I took a lot of great things I was copying and pasting into slack and sending to other leaders, but honestly, by the end of it, I was just skimming through it finding a lot of it was just not that relevant - it was like a lot of cliff notes about lots of topics instead of going deep on a few things I could run with. I feel like I've covered a lot of this material in other books or articles. But a good book no doubt, I think I just had such high expectations after Inspired.
November 5, 2022
A great book on leadership in Product Management. It provides many interesting insights, stories from large tech companies and direct passages from some impressive people. Great inspiration for all who work in tech, product development and startups.
Pay special attention to the hard things it recommends that most companies do not do!
Pay special attention to the hard things it recommends that most companies do not do!
December 28, 2020
Excellent companion book to INSPIRED. A must-read for product managers, product designers, and engineers alike. Key quote: "Great teams are made up of ordinary people who are inspired and empowered."
February 20, 2021
A must-read for any professional who is managing or working with product teams. The book describes a lot of practices which are at core common sense, but which are not applicable in today’s organizations. I love the idea of empowered product teams, who have the autonomy to solve problems, and who are not “feature machines”. In order to get there a mindset shift needs to happen in organizations and leadership plays a key role in it.
March 14, 2021
This is the book I wish I had when I started my product leadership career - a lot of which I had to learn through blood sweat and tears. A must read. It’s direct, cuts straight to the point, and arms you with tangible insights as a product leader.
May 9, 2022
As a design leader I’ve worked on many “feature” teams and struggled to do meaningful and impactful work. I needed to change the way we all work collectively. This book gives an excellent explanation of product teams and how to make the change into a product led, empowered structure.
December 25, 2022
Excellent book, highly recommend. Though, it will make you sad that your own company is doing everything wrong…
March 3, 2022
Kind of mediocre, despite the hype in product/engineering circles.
This book gets a ton of attention, and it escapes me as to why. It’s massively longer than it needs to be, has a rather preachy writing tone, and doesn’t actually go deep in anything despite the length. It also seems more primarily as an on-ramp / advertisement for “hey please read my other book and buy consulting hours from SVPG to fix your broken outdated company”.
If you’ve worked in product or any kind of software creation role (dev, design, etc.) for 5 or so years, nothing in here will be new to you.
This book could be a good reference to very early career product managers trying to understand some of the basic concepts like OKRs and understanding customer problems rather than their imagined solutions, but it is targeted toward product leadership, who should know this stuff backwards and forwards.
One additional nit beyond the writing voice: early on, Prof Galloway is cited as a reference, which is a bad sign for anyone who pays attention to the industry. I’ve got the top Goodreads review on his book, “The Four”. Go check it out to find why I’m immediately suspect of anyone who finds him to be a valid voice in the tech industry.
This book gets a ton of attention, and it escapes me as to why. It’s massively longer than it needs to be, has a rather preachy writing tone, and doesn’t actually go deep in anything despite the length. It also seems more primarily as an on-ramp / advertisement for “hey please read my other book and buy consulting hours from SVPG to fix your broken outdated company”.
If you’ve worked in product or any kind of software creation role (dev, design, etc.) for 5 or so years, nothing in here will be new to you.
This book could be a good reference to very early career product managers trying to understand some of the basic concepts like OKRs and understanding customer problems rather than their imagined solutions, but it is targeted toward product leadership, who should know this stuff backwards and forwards.
One additional nit beyond the writing voice: early on, Prof Galloway is cited as a reference, which is a bad sign for anyone who pays attention to the industry. I’ve got the top Goodreads review on his book, “The Four”. Go check it out to find why I’m immediately suspect of anyone who finds him to be a valid voice in the tech industry.
June 6, 2021
Not sure whether I had too high expectations after reading Inspired 2 times, but this book simply didn't meet my (too high?) expectations. It lacked some deep dives and felt that Marty is just numbering terms and thoughts that he collected as best practices in the past. I expected more case studies, before and after, some transformation examples of organisations that became empowered and how it affected them. I do like most of what was said in the book and I am really happy to see that I am currently working in the company that is the most empowered one so far as per Marty's criteria. :-)
This book is definitely a must-read for PMs and leads, especially PM leads or someone who is aspiring to become one.
This book is definitely a must-read for PMs and leads, especially PM leads or someone who is aspiring to become one.
February 3, 2021
If you work in developing Tech products, then this is probably a good book to read...However if you already read Marty’s first book Inspired, then you can definitely skip it. I was slightly dissappointed to see that he has re-rewritten Inspired + a study case at the end on how you can apply some of the principles in the books.
I do like Marty Cagan, but he could have done better with this book, especially since it’s coming with a high price tag.
I do like Marty Cagan, but he could have done better with this book, especially since it’s coming with a high price tag.
March 27, 2022
خب بالاخره تموم شد.
اکثر فصل هاش رو دو سه بار خوندم .
تجربه هم زمان خوندن و هم نسخه صوتی رو با صدای نویسنده گوش دادن بی نظیر بود.
حتما مجدد میخونمش.
از اون کتابهایی هست که باید بیش از یک بار خوند تا بتونی توی عمل هم استفاده کنیش.
اکثر فصل هاش رو دو سه بار خوندم .
تجربه هم زمان خوندن و هم نسخه صوتی رو با صدای نویسنده گوش دادن بی نظیر بود.
حتما مجدد میخونمش.
از اون کتابهایی هست که باید بیش از یک بار خوند تا بتونی توی عمل هم استفاده کنیش.
December 10, 2020
Just okay. Much of what's covered in the book he covers in his blog posts. Very little net-new information.
December 22, 2020
An incredible book, covering the hardest topics of product leadership. A must read.
April 24, 2021
Yet another strong, but insanely boring and wordy self-help book.
September 23, 2022
A good read albeit sometimes hard and dull to read in audio book form. It took me the better part of 2 months to get through. I don’t know how I feel about the author’s blatant use of ‘she’ instead of his/her when talking about managers and all 6 of the case studies were women! Isn’t that sexist? To say that women make the best product managers is like saying men make the best engineers. That’s so sexist!
At any rate, it was a good read to delve further into how the most innovative teams are empowered teams and why it’s imperative to hire missionaries and not mercenaries and that’s why you should never as soon outsource your engineers as you would never outsource your executives!
At any rate, it was a good read to delve further into how the most innovative teams are empowered teams and why it’s imperative to hire missionaries and not mercenaries and that’s why you should never as soon outsource your engineers as you would never outsource your executives!
December 9, 2022
I don’t get the reviews and the hype. Don’t get me wrong, the concepts are all fine and core to a successful team. But what makes this book stand out from material anyway available for free on Medium, Twitter and Substack? I did not feel the content in the book surfaced anything new or even stood out from what’s out there. And end of the day, there were way too many topics and absolutely no depth to any. This felt like a page turner but in a bad way. This was pretty much the same issue with “Inspired” as well.
January 15, 2022
Must-read for all Product Leaders. Highly recommended for all Product Managers, Product Designers and engineers.
It’s incredible how everything sounds common sense when Marty Cagan and Chris Jones explain how products should be made now days. I listened to audiobook narrated by Marty and it’s a perfect set-up for this book 👌
Together with “Inspired” this book is a starting point for all Product Managers and Leaders
It’s incredible how everything sounds common sense when Marty Cagan and Chris Jones explain how products should be made now days. I listened to audiobook narrated by Marty and it’s a perfect set-up for this book 👌
Together with “Inspired” this book is a starting point for all Product Managers and Leaders
July 5, 2021
This book has so many insights of what it takes to be a great Product Leader. I'll probably re-read parts of it several times.
I loved the enphasis on the coaching as the leader responsibility and how it's directly related to creating a team of Missionaries (and not Mercenaries).
The Team Collaboration chapter is so good that I shared it with my whole team.
I loved the enphasis on the coaching as the leader responsibility and how it's directly related to creating a team of Missionaries (and not Mercenaries).
The Team Collaboration chapter is so good that I shared it with my whole team.
January 21, 2022
Though I've read the book maybe a little too early in my career (I'm not a product leader yet...), but no doubt this book helped me a lot to better understand how to be a product leader later on, and at the same time, what to expect from my leaders while doing Product Manager roles and how to up my game as a PM in a tech company.
Super recommended!
Super recommended!
February 28, 2021
Must read for anyone in product and especially product leadership roles.
It is not a repeat of Inspired as it focuses on the management of product teams, especially when setting visions and strategy, and coaching your product people.
It is not a repeat of Inspired as it focuses on the management of product teams, especially when setting visions and strategy, and coaching your product people.
December 26, 2021
The first 2/3 of this book was a slog, but around the 70% mark there was a very detailed case study, and from that point the book improved drastically. I would recommend this to people who are in management in a product organisation (or aspiring to management in a product organisation) but probably not to ICs who want to remain as ICs.
Displaying 1 - 30 of 233 reviews