Talking about empowered product teams is no easy task but let's start by defining what an empowered product team is and how do you know if you have one.
“Empowered product team” is a term coined by Marty Cagan from SVPG to define a team that truly owns their product.
Many companies have an aspiration to implement empowered product teams, but they are often misunderstood or not implemented well.
If you unsure what it means to work in an empowered product team, ask yourself if you are actually owning your product.
Ownership means being accountable for the product’s success.
Do you have success metrics stated as business outcomes (e.g. number of subscriptions, churn rate, conversion rate)?
Or are your success metrics output-based (e.g. no. of features delivered, releases on time, bug metrics)?
As a product manager in an empowered team, you want to be measured on the outcome rather than output. Measuring only output does not indicate how your product contributes to the company’s success.
You can deliver thousands of lines of code that contribute nothing to the bottom line, yet in an output-driven world, this would be counted as a success.
Which leads to the second and third question:
What is on your roadmap? And how does it get there?
If your roadmap is a long list of features to work down in sequence, chances are that that list has largely been populated by stakeholders around the business.
Maybe you have collaborated and negotiated with stakeholders to arrive at this list, but in essence, this is still an output-driven model.
In that world, your remit is to deliver these features, but nobody can know in advance if these are the right things to build at the time.
In an empowered product team world, the product manager collaborates with stakeholders on what are the biggest and most urgent problems to solve rather than exactly what features to build over the whole year.
This focuses all minds on outcomes.
As you develop, release, and measure in an iterative fashion, your insight increases into what works and what doesn’t work.
Therefore, the roadmap needs to be a living document with maximum transparency for all parties involved.
Ask yourself, is there a feedback loop with the business to revisit and adjust the roadmap based on new insight?
This all sounds very nice and “empowering” for me as a product manager, but don’t stakeholders know best what needs to be built as they are the experts in their areas?
Yes, they are, but each one of them only knows their own part of the business and most likely none of them are digital experts.
The customer service will want you to fix issues that customers have reported.
The sales team will ask you to build stuff that sales prospects have asked for.
The marketing team will ask you to build personalization for better targeting of customers. And so on.
If you focus all minds on what are the biggest problems you should solve in the product and negotiate those, it will lead to better outcomes.
A product team that is truly empowered to deliver solutions to the agreed problems can make better decisions on what exactly to build.
For every item to be built, four questions need to be answered:
Is this valuable for customers, i.e. does it solve a real problem for them? This can be partially addressed through internal insight from subject matter experts, but should always be complemented by market and user research, competitor analysis, and product discovery techniques.
Is this viable for the business? Does this work within the boundaries of our business or could it for example have tax or legal implications or damage the brand somehow. Stakeholders are essential here to contribute their expertise.
Is it technically feasible? Do we have the technical expertise and technology platforms to build this at a justifiable cost?
Is it usable? Design expertise and usability testing can answer this question.
As you can see, answering these four questions requires the whole product team to contribute to finding the right solutions and also includes stakeholders to contribute their expertise.
The term “empowered” therefore refers not only to the ownership of the product but also to the empowerment of every individual team member within a product team to contribute to identifying the right solution.
Your role as a product manager is to facilitate the collaboration with stakeholders and the discovery of solutions within the team.
Your role is crucial to driving good outcomes, but it is not to tell your team what to build.
Many companies want to strengthen the role of product management within the organization.
This comes along under different headlines like digital transformation, agile transformation, business agility, or even customer value streams.
It has largely been recognized that stakeholders telling development teams what to build does not always lead to good outcomes.
Many companies even introduce product management for the first time, when they establish agile teams with an agile product owner.
But the introduction or transition to a truly empowered product team is not easy. Stakeholders may be slightly wary of this initially as they may feel that part of their control over what gets built gets taken away.
In order to address this, it is important to engage them continuously to show that their subject matter expertise is still very much valued and that they will continue to contribute to what gets prioritized.
Also, agile product owners in existing teams may be quite junior employees who currently just execute what has been asked of them.
The agile literature does not define what the role of an agile PO is when it comes to making decisions about what to build.
For a PO to step up to be a product manager and take true ownership of the product may be daunting and require training and mentoring.
Introducing empowered teams takes support from the management as the product is elevated into a more senior position in this setup.
Communication with stakeholders is key, but even more important than telling is showing.
One approach is to agree on solving a small but important problem, agreeing on a success metric, and tackling the problem quickly with an innovative (small) solution.
This can show the whole cycle of the problem – solution – success metric quickly and establish trust.
If you embark on a complete website overhaul or technology migration as your first problem to solve as an empowered team, it will take very long for stakeholders and management to see the benefits of this approach and come to trust you.
To conclude, many companies will claim that they have a strong product management discipline, but if you look under the hood this is not always true.
The ones that do usually outperform their competitors in innovation, speed, quality, agility, and adaptability.
All of these are critical in a fast-changing world.
Kerstin Exner