Empowered: Book Summary and Key Insights
Empowered is a book about how to build a strong product organization and why does it worth it. The author dedicates his work to product leaders, but the takeaways of this book are valuable for most of us.
The best works and most interesting solutions that I came across in the last few years all came from the intersection of different disciplines. This is particularly true for SEO, whether we are looking at the use of machine learning for search engine optimization, utilizing the mental models of the MBA curriculum for getting management buy-in, or planning SEO projects in an agile way.
These are partially the reasons why I like to read books outside of my expertise. Also picking a generalist mentality when choosing my next read is more fun. There are more new ideas, you can read interesting stories, and you rarely come across the same concepts repackaged in another boring book.
Norbert Hires
Why should you read Empowered?
Okay. I finished reading all the good SEO books. But why did I choose one about product management and why should you?
The success of the biggest projects, I was involved in as an SEO was always enabled by product teams. I am fascinated by a well-functioning product organization, especially by the role of product leaders. However, I had no clue about what and why product leaders are doing, only felt the impact and this made me curious.
But why should you read Empowered?
First of all Empowered checked my boxes. I learned about the processes of the best product companies from leaders who often established the product function in their companies. But the takeaways of this book can be useful for you even if you have little to do with product-led companies.
In Empowered you can read about:
- frameworks to solve problems more effectively,
- tips you can use to better deliver your messages and have an impact,
- soft skills and leadership in a non-BS way,
- what kind of data should you use and care about,
- how to treat trends and make bets.
Why am I writing this review?
There are already great summaries published about Empowered, which are providing a nice outline of the main points of the book.
I did not want to reinvent the wheel or create a longer version of the same stuff.
From this review, you won’t get a complete overview of the concepts discussed in Empowered. I collected concepts I found interesting.
Which are:
- The difference between feature factories and empowered product teams
- People skills and nuances
- Practical tips
Feature Factory vs. Empowered Team
- Feature factories: “These companies rarely have an inspiring, compelling product vision. They may have had one during the early years of their company, but after the founders left, the vision faded. The people on the technology teams feel like they're just working in feature factories.”
- Empowered Teams: “…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.”
- Features vs. Problems: The difference really boils down to whether you give your product teams features to build, or problems to solve. Most of the time the difference is obvious (e.g., “Add videos to our online help offering” vs. “Improve the new‐user onboarding success rate”). But sometimes the difference is more nuanced (e.g., “We need an app” vs. “Our users need to be able to access our services from anywhere”).”
- OKRs are bad for feature teams: “If the company is still using feature teams, as most unfortunately are, then the OKR technique is going to be a cultural mismatch, and almost certainly prove a waste of time and effort.”
- Focus on the outcome instead of output: “The product designer asks the product manager to write down some type of “brief” or requirements or constraints. The tech lead asks the designer when she can provide some wireframes so the engineers can start planning. The product manager asks the engineers for estimates. Very soon, the new remote work process has reverted back to waterfall‐like passing along of artifacts. And not only will innovation suffer, but the entire discussion will quickly move back to output rather than outcome.”
People, leadership, nuances
- Difference between leadership and management: “Overall, we look to leadership for inspiration and we look to management for execution.”
- Good leaders consider diverse opinions: “An insecure manager may suppress opinions that are different from her own. This obviously impedes the development of the team, but it also stifles her effectiveness as a leader. Good leaders know that they will get the best results when they are able to consider diverse points of view.”
- Public praise, private criticism: “Always remember to praise publicly but criticize privately.”
- Traits that don't serve you anymore: “Self-awareness begins with being honest with yourself and understanding what behaviors or traits might be getting in your own way, or in your team's way. Ask yourself, what are the behaviors that may have served you well earlier in your career, but now are no longer advantages?”
Practical tips from Empowered
- Arguing as your competitor: “Let me tell you what I would do if I was a product leader at Amazon or Apple, and we've decided to go after your market because we believe it is large and underserved, and that technology is available that enables dramatically better solutions for your customers.”
- The Written Narrative: “I'm talking about a roughly six‐page document that describes in narrative form the problem you're trying to solve, why this will be valuable for your customers and for your business, and your strategy for solving the problem. If this narrative is done well, the reader will be both inspired and convinced. The structure is to write the narrative itself in a few pages and then follow this with an FAQ. The idea is to anticipate the different concerns and objections that might come from key executives and stakeholders, take the time to consider and write up clear answers to these objections, and then review these responses with the people that have these concerns.”
- Involve engineers before creating a ticket: “An easy way to tell whether or not you have empowered engineers is if the first time your engineers see a product idea is at sprint planning, you are clearly a feature team and your engineers are not empowered in any meaningful sense. If you're just using your engineers to code, you're only getting about half their value.”
- Take presentation skills class: “I also encourage PMs to take a presentation skills class where your presentations are video recorded and you are provided professional critiques.”
- What if your emails get published? “Is it something that, if all of the emails and documents and discussions around the product were published online, you'd be embarrassed? How would government regulators react if they knew everything? Will the product be something that you will be proud of as part of your personal brand?”
- Don't share learning only in written form: Unfortunately, the most common way that most teams try to share these learnings is by writing them down somewhere—an email, Slack, or a report. Sadly, this is rarely effective.
- Be genuinely excited: “If you're not excited about your products, you should probably fix that either by changing what you work on or changing your role.”
Empowered: Book Review
If you have problems to solve, teammates to cooperate with, or unique challenges to deal with then you can drive insights and inspiration from Empowered even if you are not a product professional.
The leader profiles included in the book make the already actionable tips even more applicable.
Above I shared with you some snippets from the book which I found interesting. You can find several other summaries or talks of the authors online but I suggest you read the book.
I found the structure of the book easy to follow and the accompanying stories provided additional value to the concepts outlined in Empowered. Give it a try!
