View profile

🔥 Adam's Product Management Newsletter - Issue #9 - The key to a self-managing product team

Hi there, One thing I think about often is how to create highly effective self-managing teams. I thin
🔥 Adam's Product Management Newsletter - Issue #9 - The key to a self-managing product team
By Adam Wintle • Issue #9 • View online
Hi there,
One thing I think about often is how to create highly effective self-managing teams. I think I’ve probably made many versions of this over the years, and I’m always looking at ways to improve the way a product team self-manages.
Here’s what I see as the key pillars of a self-managing product team. This isn’t all there is to it by far, but it’s a good starting point.

Focusing on One Product at a Time
Within a typical organisation, such as a SaaS product, or even a digital agency who works on a client’s products, I think it’s very important that the product team can be released from “business as usual” pressure for at least six months.
This means they aren’t pulled into other projects as they pop up, and they don’t get pulled into other Product Manager’s roadmaps, or ad-hoc tasks. The team members are completely focused on the one product roadmap for at least six months. Then after this initial period, they could maybe rotate away to another product team if they wanted to.
This gives everyone in the product team time to fully focus on the problems and make a significant enough impact to the product.
And also members of the product team shouldn’t have their time divided between multiple simultaneous projects or products, this will only reduce the amount of focus and either create burnout or result in them having a less meaningful impact on the product.
The Product Team has Direct Access to…
It’s critical that everyone on the product team has direct access to a few important things. Here’s my top three:
Customers and End Users
The first is access to actual customers and end users. There needs to be some transparency between the product team and the end users. So if required a team member, can directly lookup, email, survey or communicate with users in some way.
This isn’t to say they need to constantly be chatting with customers. But for example, if there’s a particular bug which needs more user details, then the developer working on this bug can get direct access to the customer.
Or if the UX team want to run a survey on a segment of users, then they are empowered to go ahead and do this.
Stakeholders
Everyone in the product team has ways to access stakeholders, for example, the client or, higher levels of management or investors/sponsors.
This also doesn’t mean its uncontrolled and can happen any time, but there should be processes where team members get access to stakeholders so they can directly ask questions and hear product feedback and ideas from stakeholders.
It’s important for everyone on the product team to hear the vision and explanation of certain product decisions directly from stakeholders, in the stakeholders own words.
It’s also important to manage stakeholders so they are aware building a successful product is a two-way process; where anyone on the product team can raise questions and the stakeholders should be prepared to talk about their views on the product.
Usage Metrics and Analytics
I find it’s empowering for everyone on the team when all of the data, metrics and analytical tools are open and accessible to everyone on the product team. Of course sensitive customer data should have controlled access, but in general anonymised user data can be shared across the entire team.
The advantage to this is any developer, UXer, customer support, etc can dive into some data if they are investigating a bug or some kind of problem. There’s no need to request a data dump, or specifically ask for a query to be made, they can just go ahead and look for themselves. This not only speeds things up but also makes every team member feel empowered to help themselves.
On this topic, I believe the Growth Team should be the gatekeepers of all analytics and metrics; they are still responsible for configuring metric events and collecting the right data and then preparing it for everyone on the product team to access in an appropriate way.
The Product Team has Direct Access to…

Customers and End Users

It’s critical that everyone on the product team has direct access to a few important things.

The first is access to actual customers and end users. There needs to be some transparency between the prodcut team and the end users. So if required a team member, can directly email, survey or communicate with users in some way.

This isn’t to say they need to constantly be chatting with customers. But for example, if there’s a particular bug which needs more user details, then the developer working on this bug can get direct access to the customer.

Or if the UX team want to run a survey on a segment of users, then they are empowered to go ahead and do this.

Stakeholders

Everyone in the product team has ways to access stakeholders, for example, the client or, higher levels of management or investors/sponsors.

This also doesn’t mean its uncontrolled and can happen any time, but there should be processes where team members get access to stakeholders so they can directly ask questions and hear product feedback and ideas.

It’s important for everyone on the product team to hear the vision and explanation of certain product decisions directly from stakeholders, in the stakeholders own words.

It’s also important to manage stakeholders so they are aware building a successful product is a two-way process; where anyone on the product team can raise questions and the stakeholders should be prepared to talk about their views on the product.

Usage Metrics and Analytics

I find it’s empowering for everyone on the team when all of the data, metrics and analytical tools are open and accessible to everyone on the product team. Of course sensative customer data should have controlled access, but in general anonamised user data can be shared across the entire team.

The advantage to this is any developer, UXer, customer support, etc can dive into some data if they are investigating a bug or some kind of problem. There’s no need to request a data dump, or specifically ask for a query to be made, they can just go ahead and look for themselves. This not only speeds things up but also makes every team member feel empowered to help themselves.

On this topic, I believe the Growth Team should be the gatekeepers of all analytics and metrics; they are still responsible for configuring events and collecting the right data and then preparing it for everyone on the product team to access in an appropriate way.

Other Ways to Achieve Product Team Autonomy

There are a lot more requirements which need to be in place to achieve full autonomy and become a fully self-managed team, such as:
Other Ways to Achieve Product Team Autonomy
There are a lot of other requirements which need to be in place to achieve full autonomy and become a fully self-managed team, such as:
  • The team is empowered to regularly trying new things that could “fail”, but still provide learning
  • The team is empowered to safely deploy small, incremental improvements into production when required
  • The team can allocate time to iterate on work based on user feedback
  • The team is empowered to focus on only outcome-based objectives (and not just building only what stakeholders dictate)
There’s more but I’ll leave it at that for now…
And as usual, here’s some related articles:
Product vs. Project Managers: Marty Cagan’s Twelve Best Lessons for Product Team Work
Alignment Enables Autonomy: How to Build Empowered Product Teams
Team Health: A Daily Checkup – John Cutler
Thank You
Thanks again for sticking with me through to the ninth issue! 🙏🏻
Next week I’ll be hitting double-digits, which means I’ve been consistently writing this newsletter for 10 weeks! ⚡️
If there’s a topic that you’re curious to hear my opinion on let me know.
Have a great week ahead,
Thanks,
Adam Wintle
Did you enjoy this issue?
Adam Wintle

This newsletter is a curated roundup of product management tips and articles from around the web that I find every week, mixed with my own take and opinion on the topics. I’ll only be sharing the best links I find which should help save you some time.

Who Am I?

I’ve got a UX background and I’ve been working as a Product Manager for 5+ years. I’m currently working in Bangkok, Thailand helping clients achieve product-market-fit!

If you don't want these updates anymore, please unsubscribe here
If you were forwarded this newsletter and you like it, you can subscribe here
Powered by Revue
Made in Bangkok 🙏🏻