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.
If you instead remove dependencies between teams and introduce autonomous product teams – then there’s no cause for friction.
This starts with ensuring that each team has all the skills and know-how to execute on 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, but 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, and 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.
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 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 go to the legal department to ask for help with the terms and conditions, and then to go to the banking department and ask for help with the accounts. But Transferwise thinks differently. At Transferwise this team doesn’t just have design, engineering, and product on the team. It has a banker and a lawyer too. Embedded in the team. That means team members never have to go to another team or department for help and can instead just focus on executing on their goals.
In contrast I recently met an amazing data scientist, working at a Fortune 50 company, who proudly pronounced that they worked for the Research and Insight Division. Think about that for a moment. A division responsible for research and insights
One 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!
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…
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.
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.
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. 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. Etc.
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.
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 autononomy is how you build innovative organisations.
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 in London, building collaboration software, 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, and although we were a small startup with only two of those teams to begin with, 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, and for the first time we gathered everyone involved for those first two days of our sprint zero – where 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.
And 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, and 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, and 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.