Product Leadership
Lessons from ‘Empowered’ by Marty Cagan and Chris Jones (SVPG)
After nearly 10 years in leadership roles in technology departments/organisations, I have recently moved into our product organisation at Elsevier.
I joined Elsevier 3 years ago in our technology organisation and almost immediately read Marty Cagan’s book Inspired, and went on an excellent two-day training course with his partner from SVPG(the Silicon Valley Product Group) Chris Jones. Ever since, I’ve been a big fan of SVPG and an advocate for what they say about product management and how to make great products.
Their new book Empowered is about “product leadership” and is aimed at “product leaders and aspiring product leaders, especially the leaders of product managers, product designers and engineers”.
As with other books I’ve read or training that I’ve done recently, I’m writing what has stood out for me, in order to help me to distil, remember and embed what I’ve taken from the book/training. Of course, by necessity this post is therefore entirely subjective and covers only a fraction of what is covered in the book, and my key lessons could be entirely different from what you’d take from the book if you read it, which I recommend you do.
TLDR:
Lessons from the top tech companies
As with Inspired, Empowered starts by highlighting the differences between how the best companies create technology powered products and how most companies create products. They highlight three differences that they say are both fundamental and striking:
- the role of technology,
- strong product leadership, and
- empowered product teams.
I agree that those three areas are fundamental if you want to create products customers love. In terms of my own experience: (1) seems like a basic pre-requisite — you have embrace tech as a business enabler and have in-house product teams, I bought the book because I wanted to know more about (2) and what they mean by “product leadership”, and (3) can be hard.
So how do you empower teams? And what is the role of product leaders?
The key responsibilities of Product Leaders
The authors say that the key to building strong product companies is having strong product leaders. They say that these people have six main responsibilities, and the book contains a section on each:
- Coaching the product teams
- Staffing the product teams
- Product Vision and principles
- Team topology
- Product Strategy
- Managing to results, through the use of team objectives
The book distinguishes between management, which it defines as being about execution, and leadership, the purpose of which is inspiration. And whilst people normally need to combine these skills, the book divides the product leadership responsibilities between the two categories. The three key management responsibilities of product leaders are: coaching, staffing, and team objectives.
“All product managers need to be lifelong students of leadership”
1. Coaching
The section on coaching is the longest section in the book — about a quarter of the whole thing — which reflects their belief that coaching and developing the people on the product teams is “the most important responsibility of strong product leaders”. They also point out (in something that matches my own experience) that in the technology industry “we focus so much on the core skills and competencies used by product managers designers and engineers but so little on the skills and competencies in managers and leaders, yet it is these managers and leaders who are responsible for moulding people into effective teams.”
“The difference between a competent PM and a truly effective PM is often people skills. For most people you can significantly improve and develop their people skills but they do have to want to improve.”
They argue that “coaching is what turns ordinary people into extraordinary product teams” and as product leaders “we need to see where we can help improve people as individuals and especially as a team.” They define good coaching as “an ongoing dialogue with the goal of helping the employee to reach her potential”.
They suggest that “developing people is the job #1” for a manager, and if you are a manager, “you should be spending most of your time and energy on coaching your team. This means expending real effort on things such as assessing your team, creating coaching plans and actively helping them improve and develop.” I love this provocative statement, it’s a real challenge, and I wonder what percent of product leaders spend more than 50% of their time on coaching their team.
“Managers need to focus at least weekly on whether each of her product people feels she is doing meaningful work, progressing in her career, and building the necessary relationships with her team and with the execs that enable her to effectively and successfully lead an empowered product team”
Other bits that stood out for me in this section and had me nodding along included:
- “Empowering means creating an environment where your people can own outcomes and not just tasks” you must step back — your job is not to drive a team’s task list.
- “You need to create a space where alternative points of view can flourish”
- “Collaboration is not about consensus or artefacts or compromise”
(I was pleased to see that they are not suggesting managers encourage consensus within a team, since I’ve written previously about why it’s important to move away from consensus and shift to a place where it’s ok for people in a team to disagree, because you can disagree well, and conflicting views are welcomed.) - “Managers need to raise the level of performance of the people that report to them.”
- They advocate this framework for assessing a product manager’s skills and then using it as the foundation for coaching the person to success
2. Staffing
Under the heading of ‘staffing’ the book covers a large subject that includes recruiting, hiring, interviewing, onboarding, and promoting and firing people. As with their comments on the importance of management, coaching and people skills, I love how the authors tackle issues head on.
I have often heard people claim that, if they are going to compete with the likes of Google and Amazon, they need to hire exceptional people — something I’ve never quite believed. So I was pleased to read the authors say that “this is a dangerous misconception. [...] the best product companies hire competent people of character, and then coach and develop them into members of extraordinary teams.”
They are also crystal clear and explicit that “staffing is the responsibility of the hiring manager” (not your HR team or your Talent Acquisition team): the hiring manager needs to step up and take responsibility for staffing. And this is because their empowered team model is a people-first model, it’s about hiring capable people and giving them space to do remarkable things. Consequently, “staffing must move from being seen as a set of necessary tasks to a strategic skill”.
Skill in staffing is one of the most important and telling leading indicators for a company’s success.
Whilst arguing that you recruit people based on competence (which includes capabilities, skills, and track record) and character (includes integrity, motive, and intent with people), they are also clear that you must not recruit for cultural fit, which they call “one of the most damaging concepts for your efforts to build a great organisation.” For too many organisations, cultural fit “is the politically correct term for what essentially translates into: ‘hire people who look and think like we do’” Yet, “one of the unintended and damaging consequences of hiring people like us is that they too often think like us”, and this lack of diversity reduces the chances of solving hard problems. “So, rather than looking for people like yourselves, make it as an explicit point to look for people that are clearly not like yourselves.”
They argue that recruiting needs to be “an ongoing and high priority activity” for managers. This stems from their philosophy that, as a manager, “you are only as good as your weakest employee. These people are your product.” So your goal needs to be that “every hire should raise the average.”
It is an ongoing activity because you can always be working to strengthen the pool of people you look to bring in by:
1. Building your network of potential recruits
2. Hosting talks in your offices with selected industry speakers to cast attract candidates and also help build the reputation of your organisation
3. Writing on a company blog
Whilst recruiting is an ongoing activity, there will be periods when it needs to take up more time:
When you have a vacancy on your team, then until that role is filled, you should expect to spend a minimum of 50% of your time on that task. Everything else is secondary.
The hiring manager needs:
- to ensure that the hiring process moves quickly
- to own and actively manage the interview process (eg “The hiring manager should very carefully select and curate the interview team. Each person should be selected both of her competence and her character. There should be people a strong candidate would be proud to work with”) — and here is one of the author’s favourite interview questions
- to do reference checks (a serious task that cannot be delegated),
- to call the successful candidate and “explicitly tell the candidate that if she joins and commits to putting in the effort, then you will promise to personally invest in coaching and developing the candidate to reach her potential,”
- to invest in new hire’s onboarding (and, whilst they propose the model of a five-day intensive boot camp during their first week on the job to set them up for success, they are referring to the new employee’s first three months)
3. Product vision and principles
A product vision describes the future you are trying to create (with a timeframe of three to ten years). It needs to be customer centric and to tell the story of the product from the perspective of users and customers and demonstrate how their lives will improve in some meaningful way.
Its purpose is to inspire and to help teams understand the overarching goal, the bigger picture, and how their work contributes to this larger whole.
Given this purpose, the authors counsel that you need to think carefully about the format you use for your vision. Again, I love their directness here, with their pithy put down: “PowerPoint presentations rarely inspire anyone.” So true.
Instead, they suggest using video, or a storyboard. Whatever the format, it needs to be told from the users’ perspective, and it is worth spending real time and effort getting it right because it can be a helpful tool for recruitment and evangelism:
Your company’s executives, investors, stakeholders, sales and marketing staff, customer service and customer success staff, and key influencers from across the company and beyond-you need all these people to understand the future you are trying to create. Why? Because in ways large and small, they will all need to help your vision to reach its full potential.
Product principles complement the product vision by stating the values and beliefs that are intended to inform the very many product decisions that teams will need to make in designing and building the product (eg the common trade-offs between ease of use and security). The principles are a tool for product teams to guide them in their daily work and help with resolving issues that arise by clarifying priorities. As such, they form an important part of the strategic context.
And given that the authors advocate leading with context, not control, they see product principles as a key contribution to empowering teams. This was one point when I was left wanting a bit more. I would have appreciated seeing more examples of different principles. Perhaps this is because are often not public. At Elsevier a couple of years ago we made public four principles underpinning our products that support researchers and research leaders.
4. Team Topology
A team topology, they explain, defines how you structure your teams and needs to answer questions such as:
• How many product teams should our organisation have?
• What is the scope of responsibility of each team?
• What are the skills required for each team?
• What are the dependencies between the teams?
Choosing a team topology is a decision for the leaders of product, design and engineering, working together, balancing the needs of each.
In choosing a team topology that optimises for empowerment, these leaders need to balance three inter-related goals:
•ownership — scope and clarity of ownership, ensuring that each team is responsible for something meaningful,
•autonomy giving teams problems to solve and enough control so that they can solve the problem in the best way that they see fit, which often involves minimising inter-team dependencies, and
•alignment alignment with different aspects of the strategic context (eg with the technical architecture, with other business units).
There are two fundamental types of product teams:
• Experience teams, which are responsible for how the product value is exposed to users and customers, and
•Platform teams, which manage services so they can be easily leveraged by other teams.
The purpose of a platform team is to enable the experience teams to better solve problems for their customers. A platform team therefore often shares the same goal as an experience team, so that the two teams “are connected as to why the work is important, and what it means for the business”, although the contribution of a platform team is normally indirect.
For experience teams, they recommend creating a topology that is aligned by customer, in order to maximise empowerment by giving the team as much end-to-end responsibility as possible.
In terms of the physical location of a team, they suggest optimising for the product team (as opposed to optimising for the managers, or for access to customers, or for anything else).
Every product team has two types of work:
1. their main purpose, and
2. the daily work necessary to keep the product/business running — “things like fixing bugs, addressing performance issues and adding critical capabilities for non-negotiable things that come up such as compliance issues.” Platform teams have more of those obligations than the average experience team, and that’s because of the nature of the work involved in enabling the teams that depend on them, “it might be close to half of their work”.
5. Product Strategy
A focused and compelling product strategy — based on quantitative and qualitative insights — is among the most important contributions of product leadership.
Whatever your goal for your product, your product strategy is how you’re planning to go about accomplishing that goal. It requires four things:
1. Focus: Being willing to make tough choices on what’s really important
2. Generating, identifying, and leveraging insights
3. Converting insights into action
4. Active management without resorting to micromanagement.
Key for me in this section was the chapter on focus: a product strategy helps decide what problems to solve: “not everything we do is equally important or impactful, and we must choose which objectives are truly critical for the business.”
It is important to pick the few things that can truly make an impact: “decide which objectives should be pursued by which product teams, and then provide those teams with the strategic context necessary for them to solve the problems we need them to solve.”
I’ve found that many organisations find focus hard and I recognised the authors’ experience:
I can’t tell you how many companies I’ve gone into that have on an office wall or in a spreadsheet a list of literally 50 major objectives or initiatives they’re pursuing.
I once saw a list of 76 major objectives!…
However, they caution that “by not picking your battles and focusing on the few truly critical problems, most of the work going on does not make an impact and for the truly critical priorities, there is not enough attention to actually move the needle.”
Importantly they’re not just talking about individual product teams needing to focus, but about how “absolutely critical” this concept is at the level of the broader product organisation [music to my ears!]. This is because
“There is a real cost to the organisation, and especially to the leadership, for each high priority effort or initiative. This cost involves management time, decisions, monitoring and tracking, staffing issues, and more.”
The same concept of WIP limits that some product teams use applies at the organisational level.
6. Team Objectives
The point of team objectives is to execute on a product strategy.
SVPG are advocates of the OKR model for setting team objectives, and whilst they argue that “how work is assigned matters”, they caution that “if a company 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.”
This is because the most important benefit of OKRs is how you can use them to empower teams:
The essential point of team objectives is to empower a team by: (a) giving them a problem to solve more than a feature to build, and (b) ensuring they have the necessary strategic context to understand the why and make good decisions.
They are intended to give the product team the space to come up with solutions to hard and important problems. To use them like this, you need to define success by business results (outcomes) and not simply activity or output. A common problem is to list activities or deliverables as key results. The need to separate these two was the first and most important lesson I learnt about OKRs when I started using them. And much of this section of the book will be familiar to anyone who has done much reading about OKRs (eg the need to be clear on the level of ambition — roofshots vs moonshots — and the importance of setting objectives for cross-functional product teams rather than cascading objectives through management functions). However, I nonetheless took two new and important things from this section.
First, they distinguish between the role of product leaders in assigning objectives to product teams and the role of the teams in setting the key results.
“It is the responsibility of the leaders to decide which problems should be worked on by which product teams. The whole point of assigning objectives to product teams is to execute on a product strategy. The product strategy is all about deciding which problems to work on. Leaders have to ensure that in aggregate, the organisation is covering as much of the overall organisational objectives as possible.”
However, if leaders want their product teams to feel ownership of the results, then “the key results must come from the team.”
Leaders have some role in specifying how success will be measured (that is, which specific metrics to use) but not in setting the expected value or timeframe, because those need to come from the team. “The reason for that is because, if we were to provide a team explicit messages of success including timeframe, they won’t feel ownership over the commitment. So the actual quantity values need to come from the team.”
The best OKRs therefore come from a “back-and-forth dialogue between the leader and the team”.
I have said before that not everything a team is trying to do needs to be or should be expressed as an OKR. OKRs are not the only work that a product team is responsible for. And the second key take away for me from this section was a concept that helps with understanding how that can work in practice.
“In all businesses there are occasional situations where something important must be delivered by specific deadline date.” They advise that you shouldn’t have too many of these date-driven commitments —they should be the exception not the rule — but recognise that they’re necessary when trying to run a business (eg in order to meet an important external commitment or a very important and substantial internal commitment).
“So a key condition to moving to empowered teams is that the teams be able to provide dates and deliverables when necessary — dates that leaders can count on.” The authors call these “high-integrity commitments” and the actual deliverable is the commitment that needs to be noted and tracked, independently of key results.
The book:
Other reviews of Empowered:
‘Book summary: Empowered by Marty Cagan’, by Toby Sinclair
‘Book review: Empowered’, by Marc Abraham
‘Empowered by Marty Cagan & Chris Jones: A book review’, by Hannes Rössler
Other materials from Marty Cagan relating to ‘Empowered’:
- Product Leadership Is Hard, blogpost by Marty Cagan
- Empowered — Achieving extraordinary results with ordinary people, video of a talk by Marty Cagan at the Productized conference in November 2018 (and talk summary by Productized)
- Empowered — Achieving extraordinary results with ordinary people, slides from a talk by Marty Cagan at AgileAus2019
- Interview in April 2021 with Marty Cagan on why empowered teams make the best products
