View profile

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

Adam Wintle
Adam Wintle
@adamwintle
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
Product vs. Project Managers: Marty Cagan’s Twelve Best Lessons for Product Team Work
There’s so many great tips and advice here its hard to summarise. I think the key takeaway for me is to ensure you have a competent product team, which means no “juniors” or people who are fresh grads. My rule of thumb is everyone on the team should at least be at intermediate skill level, with roughly 2-3 years of experience. Otherwise their inexperience can create a management overhead which a high-performing team doesn’t want to spend time on.
medium.com
Alignment Enables Autonomy: How to Build Empowered Product Teams
Alignment Enables Autonomy: How to Build Empowered Product Teams
Your workplace is a diverse group with differing motivations, skills, worldviews, interests and hobbies. Throughout all this, there is one thing each individual and group shares: a strong passion for the product.
medium.com
Team Health: A Daily Checkup – John Cutler
Team Health: A Daily Checkup – John Cutler
John Cutlet’s made a useful daily team checkup sheet. I’ve tried it and had varying degrees of success. Usually I like to adapt this into my own version.
medium.com
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? Yes No
Adam Wintle
Adam Wintle @adamwintle

Focusing on People and Product: the intersection of psychology and product management.

After working in product for over a decade and speaking to many other product mangers (as well as UXers, growth people, marketers and techies) the number one struggle I heard again and again is that people are at the root of the majority of the problems.

Once you have mastered the basics of product management. Once you have read all the books. After you’ve been to all the conferences. You’ve seen all the YouTube videos; you’re a member of all the Slack communities. Then you are only left with learning how to lead, work with and manage other people, to get them all aligned and pointing in the same direction, so you can build your product vision and ultimately build a successful product.

This art of People & Product can take decades to master. I’m certainly not a master of this yet, but I thought you might enjoy following along on my journey. Want in?

In order to unsubscribe, click here.
If you were forwarded this newsletter and you like it, you can subscribe here.
Created with Revue by Twitter.
Made in Bangkok 🙏🏻