Your team is smarter than you are: why autonomous product teams work better "Product people - Product managers, product designers, UX designers, UX researchers, Business analysts, developers, makers & entrepreneurs 8 March 2022 False Alignment, Autonomy, Cross-Functional Team, Team, Mind the Product Mind the Product Ltd 1798 Figures,Blocks,Of,People,On,A,Blue,Background.,Concept,Of Product Management 7.192
· 8 minute read

Your team is smarter than you are: why autonomous product teams work better

I’ve always argued that product management is a team sport. But as soon as you have more than one team in an organisation and you need them to interact with each other, you introduce friction. This friction between teams is why we have libraries full of project management books and methodologies, inboxes and outboxes, dependency management, and so much more. All friction. And friction kills momentum. Friction kills speed.

Team Friction
An example of Team Friction

If you instead remove dependencies between teams and introduce autonomous product teams—then there’s no cause for friction.

Cross-functional teams

This starts with ensuring that each team has all the skills and know-how to execute their objectives. One of the first blog posts I wrote used a Venn diagram to define product management as the intersection of the customer, technology, and business. Of course, it doesn’t just end there. Maybe your teams need customer success, marketing, compliance, or more, on the team as well. It’s useful to think in detail about what skills you really need in your team to make it successful. It’s also important to consider how to map out that diversity so you ensure you bring in different contexts, experiences, and insights to your team too.

This spider chart is by no means a definitive list but a model for you to think about. As you start mapping out individuals on your team you can quickly see how they overlap, where they complement one another with different experiences and skill sets, and where you might have gaps that need filling.

Product Team Skills
Product Team Skills

This diversity—not just of gender and background (though those are table stakes for me), but of skills, experience, and contexts—is not just important to remove dependencies on other teams. It’s crucial because the more contexts and viewpoints you’re exposed to in a team, the more likely you are to be able to understand and empathise with your customers too.

My favourite example of this comes from Wise, Formerly TransferWise—an online currency transfer platform. Its currencies team is responsible for launching new currency paths like transferring USD to GBP. As you can imagine it’s a little more complicated than just adding the option to a drop-down. It means opening bank accounts in the target country and updating terms and conditions to comply with local money-laundering and securities laws. In any other organisation, this would require the team to ask the legal department for help with the terms and conditions, and then ask the banking department for help with accounts. But Wise thinks differently. At Wise, the team doesn’t just have design, engineering, and product on the team, it has a banker and a lawyer too. That means team members never have to go to another team or department for help and ca just focus on executing their goals.

In contrast, I recently met an amazing data scientist, working at a Fortune 50 company. They proudly pronounced that they worked for the research and insight division. Think about that for a moment. A division responsible for research and insights

On the one hand that sounds fantastic right? A whole division! Lots of smart people and amazing resources to do groundbreaking customer research, ethnographic studies, surveys, data collection etc. So much amazing research!

Friction Between Divisions
Friction Between Divisions

But imagine the bureaucratic nightmare that’s caused by it being in a separate division. Imagine the request forms, the prioritisation, and approval processes needed to gatekeep that resource and share it among all the other divisions.

Imagine having to make a business case for the research you need to make a business case…

Autonomy

We’re no longer working in cotton mills or factories, so why are we using the management styles that came out of them? Command and control made sense when only a handful of top managers held all the knowledge and skills and labour was a literal human resource that needed to be corralled.

Factory vs Creative Processes
Factory vs Creative Processes

Most of the agile and lean methodologies we use today come from the Toyota Production System. And they’re great if you’ve designed a car and want to build it as cheaply, efficiently, and error-free as possible. But we forget that the team that designs the car in the first place doesn’t work that way. It just can’t. That’s just not how it works anymore.

At the end of the day, your team is smarter than you are, it has more information than you do, it is closer to the problem than you are, and closer to the customer than you are. So why are you telling your team what to do?

Instead, we need to empower our teams. We need to embrace autonomy. We need to let the team use all of that amazing knowledge, experience, and skills to get on with the job of solving the customer problem.

Autonomy motivates

Most people believe that the best way to motivate is with rewards like money—the carrot-and-stick approach. That’s a mistake, says Daniel H. Pink. In his book Drive (also an exceptional TED talk), he draws on four decades of scientific research to assert that the key to motivation is the deeply human need to direct our own lives.

His research shows that once you pay people enough, additional financial incentives simply don’t make an individual or team more motivated, more innovative, or more successful.

Instead, we are motivated by Autonomy, Mastery, and Purpose. Autonomy is our desire to be self-directed and it increases engagement over compliance. Mastery is the urge to improve our skills—and master our craft. The purpose is the desire to do something that has meaning and is important.

Autonomy means staying nimble

True autonomy means removing any dependencies and reliance on shared resources or central teams. As we’ve seen from the Transferwise example, ensuring that each team has everything it needs means it doesn’t need to worry about other teams’ priorities.

But it doesn’t just stop there. All teams should be able to change any part of the product if it furthers their goals. So, for example, marketing shouldn’t have to wait for product to build what they need. They should have full access to build pages, change user flows, or do anything else necessary in pursuit of their goals. A true growth marketing team can’t stop at the landing page. They need to follow their cohorts through the full conversion and retention process to know whether a channel or campaign is truly successful.

Autonomy means everyone gets involved

True autonomy also means everyone in the team gets involved and bring their skills to bear to all the challenges that the team faces. Only by co-creating can we truly bring all those skills and perspectives to bear on the customer.

As Marty Cagan said: “If you’re only using your engineers to code, you’re only getting half their value.” I would argue that is true for all of us. If you’re only using your designers to push pixels, you’re only getting half their value. If you’re only using product managers to groom backlogs, you’re only getting half their value.

So get your engineers involved in design. Get your designers involved in engineering discussions. Get everyone involved in customer research. Because insight, inspiration, and great product ideas come from the least expected corners.

Aligned autonomy

Now a lot of people hear autonomy and think of chaos or anarchy. They think that it means everyone can do whatever they want, build whatever they want, and come and go as they please.

But the key to successful autonomous product teams is to do it with accountability. It only works when teams don’t just feel ownership of the process and what they build, but they feel ownership over the customer outcome too. Because then they’ll live or die by those outcomes.

Leadership still has a huge role to play in setting the vision, the mission, and the goals that teams are tasked with executing so that those autonomous teams have guardrails within which to operate.

Leadership’s biggest job is to ensure alignment between these teams so that each one knows what their goals are, how they tie back to the company goals, and what everyone else is working on.

Henrik Kniberg, the agile and organisational coach behind the famous Spotify squad and tribe model, illustrates this with a great 2×2 chart. And like any good 2×2 matrix, you want to be in the top right, because high alignment and high autonomy is how you build innovative organisations.

Alignment v Autonomy
Alignment v Autonomy

Bringing it together

I remember what is probably still one of the proudest moments in my career as a product manager. Many years ago I was working at a SaaS company and we were experimenting with this new way of working. We’d already set up semi-autonomous teams with a product manager, front and back-end engineers and a designer. Although we were a small startup with only two of those teams, we rotated them through business-as-usual work and big new feature pushes.

One day we were kicking off one of those big new features, totally rewriting and redesigning a core piece of the product. For the first time, we gathered everyone involved for those first two days of our sprint zero. We were clarifying exactly what we were going to do and build.

And when I say everyone, I mean everyone. We had the product manager, the engineers, and the designer, of course, but we also had sales reps, the marketing manager, and the customer service manager.

Once we’d briefed everyone on the goals of the project, the customer problem we were aiming to solve, and the research we’d done validating that customer problem, it happened.

I didn’t write a single story or sketch a single wireframe for that feature. The team came up with all the ideas we needed to solve that customer problem. Most importantly one of the junior developers came up with the cornerstone feature—something that ended up taking only a few hours to code but solved 80% of the customer problem. Something I could never have come up with on my own.

Never forget that as a product leader you are only as good as your team. Setting up autonomous product teams for success and giving them the space to do their best is ultimately how you and your product will be successful.

Discover more insights on Building Product Teams. 

Comments 2

Loved the article and I couldn’t agree more. Even so, it sounds easy in your article I know that
it is god damn hard work to achieve the described status, especially in an
enterprise context. That is also one reason why I am attracted to the ideas behind the LESS framework. Looking forward reading more of those good articles. Thx!

Great article Martin, and I totally agree with your theory. In my experience, cross-functional teams working together around a new product or feature can get things done much quicker and efficiently..often with better outcomes and solutions. I also advocate employing the cross-functional team approach around methodologies like CXJM to get to the shared understanding of problems quicker and ultimately delivering better solutions.

Join the community

Sign up for free to share your thoughts

About the author

I’ve always argued that product management is a team sport. But as soon as you have more than one team in an organisation and you need them to interact with each other, you introduce friction. This friction between teams is why we have libraries full of project management books and methodologies, inboxes and outboxes, dependency management, and so much more. All friction. And friction kills momentum. Friction kills speed. [caption id="attachment_12696" align="aligncenter" width="1000"]Team Friction An example of Team Friction[/caption] If you instead remove dependencies between teams and introduce autonomous product teams—then there’s no cause for friction.

Cross-functional teams

This starts with ensuring that each team has all the skills and know-how to execute their objectives. One of the first blog posts I wrote used a Venn diagram to define product management as the intersection of the customer, technology, and business. Of course, it doesn’t just end there. Maybe your teams need customer success, marketing, compliance, or more, on the team as well. It’s useful to think in detail about what skills you really need in your team to make it successful. It's also important to consider how to map out that diversity so you ensure you bring in different contexts, experiences, and insights to your team too. This spider chart is by no means a definitive list but a model for you to think about. As you start mapping out individuals on your team you can quickly see how they overlap, where they complement one another with different experiences and skill sets, and where you might have gaps that need filling. [caption id="attachment_12697" align="aligncenter" width="1000"]Product Team Skills Product Team Skills[/caption] This diversity—not just of gender and background (though those are table stakes for me), but of skills, experience, and contexts—is not just important to remove dependencies on other teams. It’s crucial because the more contexts and viewpoints you’re exposed to in a team, the more likely you are to be able to understand and empathise with your customers too. My favourite example of this comes from Wise, Formerly TransferWise—an online currency transfer platform. Its currencies team is responsible for launching new currency paths like transferring USD to GBP. As you can imagine it’s a little more complicated than just adding the option to a drop-down. It means opening bank accounts in the target country and updating terms and conditions to comply with local money-laundering and securities laws. In any other organisation, this would require the team to ask the legal department for help with the terms and conditions, and then ask the banking department for help with accounts. But Wise thinks differently. At Wise, the team doesn’t just have design, engineering, and product on the team, it has a banker and a lawyer too. That means team members never have to go to another team or department for help and ca just focus on executing their goals. In contrast, I recently met an amazing data scientist, working at a Fortune 50 company. They proudly pronounced that they worked for the research and insight division. Think about that for a moment. A division responsible for research and insights On the one hand that sounds fantastic right? A whole division! Lots of smart people and amazing resources to do groundbreaking customer research, ethnographic studies, surveys, data collection etc. So much amazing research! [caption id="attachment_12698" align="aligncenter" width="1000"]Friction Between Divisions Friction Between Divisions[/caption] But imagine the bureaucratic nightmare that’s caused by it being in a separate division. Imagine the request forms, the prioritisation, and approval processes needed to gatekeep that resource and share it among all the other divisions. Imagine having to make a business case for the research you need to make a business case…

Autonomy

We’re no longer working in cotton mills or factories, so why are we using the management styles that came out of them? Command and control made sense when only a handful of top managers held all the knowledge and skills and labour was a literal human resource that needed to be corralled. [caption id="attachment_12699" align="aligncenter" width="1000"]Factory vs Creative Processes Factory vs Creative Processes[/caption] Most of the agile and lean methodologies we use today come from the Toyota Production System. And they’re great if you’ve designed a car and want to build it as cheaply, efficiently, and error-free as possible. But we forget that the team that designs the car in the first place doesn’t work that way. It just can’t. That’s just not how it works anymore. At the end of the day, your team is smarter than you are, it has more information than you do, it is closer to the problem than you are, and closer to the customer than you are. So why are you telling your team what to do? Instead, we need to empower our teams. We need to embrace autonomy. We need to let the team use all of that amazing knowledge, experience, and skills to get on with the job of solving the customer problem.

Autonomy motivates

Most people believe that the best way to motivate is with rewards like money—the carrot-and-stick approach. That’s a mistake, says Daniel H. Pink. In his book Drive (also an exceptional TED talk), he draws on four decades of scientific research to assert that the key to motivation is the deeply human need to direct our own lives. His research shows that once you pay people enough, additional financial incentives simply don’t make an individual or team more motivated, more innovative, or more successful. Instead, we are motivated by Autonomy, Mastery, and Purpose. Autonomy is our desire to be self-directed and it increases engagement over compliance. Mastery is the urge to improve our skills—and master our craft. The purpose is the desire to do something that has meaning and is important.

Autonomy means staying nimble

True autonomy means removing any dependencies and reliance on shared resources or central teams. As we’ve seen from the Transferwise example, ensuring that each team has everything it needs means it doesn’t need to worry about other teams’ priorities. But it doesn’t just stop there. All teams should be able to change any part of the product if it furthers their goals. So, for example, marketing shouldn’t have to wait for product to build what they need. They should have full access to build pages, change user flows, or do anything else necessary in pursuit of their goals. A true growth marketing team can’t stop at the landing page. They need to follow their cohorts through the full conversion and retention process to know whether a channel or campaign is truly successful.

Autonomy means everyone gets involved

True autonomy also means everyone in the team gets involved and bring their skills to bear to all the challenges that the team faces. Only by co-creating can we truly bring all those skills and perspectives to bear on the customer. As Marty Cagan said: “If you’re only using your engineers to code, you’re only getting half their value.” I would argue that is true for all of us. If you’re only using your designers to push pixels, you’re only getting half their value. If you’re only using product managers to groom backlogs, you’re only getting half their value. So get your engineers involved in design. Get your designers involved in engineering discussions. Get everyone involved in customer research. Because insight, inspiration, and great product ideas come from the least expected corners.

Aligned autonomy

Now a lot of people hear autonomy and think of chaos or anarchy. They think that it means everyone can do whatever they want, build whatever they want, and come and go as they please. But the key to successful autonomous product teams is to do it with accountability. It only works when teams don’t just feel ownership of the process and what they build, but they feel ownership over the customer outcome too. Because then they’ll live or die by those outcomes. Leadership still has a huge role to play in setting the vision, the mission, and the goals that teams are tasked with executing so that those autonomous teams have guardrails within which to operate. Leadership’s biggest job is to ensure alignment between these teams so that each one knows what their goals are, how they tie back to the company goals, and what everyone else is working on. Henrik Kniberg, the agile and organisational coach behind the famous Spotify squad and tribe model, illustrates this with a great 2x2 chart. And like any good 2x2 matrix, you want to be in the top right, because high alignment and high autonomy is how you build innovative organisations. [caption id="attachment_12695" align="aligncenter" width="1000"]Alignment v Autonomy Alignment v Autonomy[/caption]

Bringing it together

I remember what is probably still one of the proudest moments in my career as a product manager. Many years ago I was working at a SaaS company and we were experimenting with this new way of working. We’d already set up semi-autonomous teams with a product manager, front and back-end engineers and a designer. Although we were a small startup with only two of those teams, we rotated them through business-as-usual work and big new feature pushes. One day we were kicking off one of those big new features, totally rewriting and redesigning a core piece of the product. For the first time, we gathered everyone involved for those first two days of our sprint zero. We were clarifying exactly what we were going to do and build. And when I say everyone, I mean everyone. We had the product manager, the engineers, and the designer, of course, but we also had sales reps, the marketing manager, and the customer service manager. Once we’d briefed everyone on the goals of the project, the customer problem we were aiming to solve, and the research we’d done validating that customer problem, it happened. I didn’t write a single story or sketch a single wireframe for that feature. The team came up with all the ideas we needed to solve that customer problem. Most importantly one of the junior developers came up with the cornerstone feature—something that ended up taking only a few hours to code but solved 80% of the customer problem. Something I could never have come up with on my own. Never forget that as a product leader you are only as good as your team. Setting up autonomous product teams for success and giving them the space to do their best is ultimately how you and your product will be successful.

Discover more insights on Building Product Teams.