Transitioning to Autonomous and Empowered Product Teams
I currently work at Subito, the leading marketplace in Italy to buy and sell second-hand items — you can find nearly everything from electronics, cars, and collectibles, to housing, clothing, and furniture. You can also buy and sell new products and offer professional services, however our core mission is to give a second life to used items, reducing CO2 emissions and having a positive impact on the environment.
Subito is also part of Adevinta, one of the global market leaders in online classifieds, operating in 16 countries and with almost 3,000 employees around the world. More than 27 million daily users buy or sell their items through our trusted marketplaces.
Many books and articles have been written about autonomous and empowered product teams, and how they can benefit the entire organization — a must-read on this topic is “Empowered Product Teams” by Marty Cagan. However, it is quite difficult to find practical examples of how to transition from “feature-request teams” to “empowered product teams”, and what are the main challenges along the way.
I worked for companies that both failed and succeeded in this transformation, but I truly believe, today more than ever, it is a required step to take in order to stay competitive and attract the best talents in the tech scene.
In this article, you can read about what I learned, and what is, in my opinion, the best path to follow. I give some advice and practical tips on how to start the transformation and reach the “first milestone”.
Hopefully, you’ll find some inspiration while I take you through this journey.
How to get started
Easy to say, hard to do: start with why. Your employees (or people — how you should call them), need to understand why a similar change is needed, what are the expected benefits, what a “Product-led Organization” really means (breaking news — it doesn’t mean “led by Product Managers”), and how you’re going to approach the change and measure the value it creates.
In both TransferWise — another company I worked for — and Subito, it all started understanding the why and defining a few leading principles for both the company’s values and the structure. They can be summarized as follows:
- Discover what users really need, what are their problems, and try to solve them.
- Focus on outcomes, instead of outputs, through OKRs and Business Health Checks.
- Autonomous, cross-functional and accountable teams for the OKRs they decide to pursue.
- Weekly, monthly and quarterly events to align the entire company on goals or new challenges and give an update on the progress each team has made.
Honestly, there is probably nothing really new you haven’t heard before. However, it’s always a big challenge to put all these principles in practice, especially when you want to engage the entire company.
At Subito, we shared these principles in a company-wide meeting, and we moved forward with consistent evangelism from our CEO, our Head of Product and other key figures in the company. Also, we wanted to make sure that every Product Manager was on the same page, so we organized few internal training where we went through some key aspects of our role, how to set OKRs, the discovery process, how to prioritize problems and ideas, and the basics of lean product development (a must-read on this topic is “The Lean Product Playbook” by Dan Olsen). In addition, some of us had the opportunity to join a 5-days training program in Adevinta’s Office, where we met with PMs from other marketplaces and dug into some key topics as GIST, ICE, product research and product design. A special thanks to Adevinta’s organizers, the “yellow team”, and our trainers, Itamar Gilad, Austin Keeble and Gerard Cadiach.
The transition often requires some team reorganization, otherwise, you just pretend and ask people to be autonomous and empowered, without the right infrastructure or resources — this is one of the most common reason for failure.
I think reorganizations are not bad by definition, however, you shouldn’t play around and change things every quarter, or multiple times in a quarter. You might need to iterate a little bit from your starting point, but try to stick to your decisions for at least a year.
Also, don’t reorganize teams thinking you will fill the gaps with new hires — hiring the right people takes a lot of time and it is probably the worst way to start. If you miss some important roles, just postpone the change for a better time.
Finally, I’m not a real expert on this topic, but I think that Domain Driven Design (DDD), which was introduced in Subito a while ago, was a good starting point for us. If your company doesn’t follow this approach, or you have never heard about that, you should probably have a look at DDD before taking your first steps.
So, to recap, the key points to get you started are:
- Start with why.
- Define and share leading principles.
- Constant evangelisms and training.
- Reorganize teams, if needed.
How to reach the first milestone
“Well begun, half done” — says an international proverb.
If you communicate the why in the right way, you make people aware of this need, you create the inner desire of a change, and, finally, you set the right organizational structure, you’ve already done a great job.
However, in order to reach the very first milestone, I believe it is really important to:
- Assign a feedback coach to each team.
- Let the teams being autonomous and empowered from day one, even if you’re afraid they might fail quite soon.
Why feedback is so important
It is really hard to succeed in the long term if you don’t introduce the role of the “feedback coach”. I believe this is a key role in this process, however, you might not have the right people to play this role — or you might pick the wrong ones.
A good feedback coach needs to be someone who:
- Knows how to give feedback — it might sound obvious, but it is a skill very few people can master.
- Truly believes in autonomous and empowered product teams (n.b. he/she doesn’t have to be a Product Manager), and is a true advocate for the leading principles mentioned before.
- Doesn’t have any personal interest in the team’s goals and how they want to achieve them.
- Is well seen and respected by most of the people in the assigned team and the entire organization.
In a company I worked for, we didn’t introduce this role and things didn’t go very well. In Subito, we introduced some sort of feedback coaches, even though we made some mistakes and we had to iterate on that. In TransferWise, each team had the opportunity to choose their coach, and I think this is probably the best way to proceed. If you’re afraid the teams might not have the maturity to choose the right coach yet, you can provide a list of selected people and let them pick one of them.
It’s critical for feedback coaches to:
- learn about team members and review historical plans or initiatives.
- explore future team’s plans and understand why they are focusing on where they are.
- challenge the team on impact/focus, capability, and their assumptions.
- help them to overcome obstacles and reach the right level of confidence.
Be bold and dive into unknown waters
Depending on the company and the people working there, you can either start the transition with few teams or the entire company. There isn’t a better way among the two: it really depends on your organization, culture, and market.
Either way, I suggest giving the teams 2–4 weeks for understanding the principles and for approaching their first autonomous quarterly planning (while keeping the business alive), and 2 weeks to iterate on the feedback anyone can give, before the new quarter starts.
In Subito, for example, each team had two weeks to gather together and:
- Define which objective(s) and the key result(s) they wanted to address in the coming quarter.
- Elaborate some hypothesis to achieve those goals.
- Estimate the impact they expected to see if the hypothesis were right.
We went through some exhausting but also rewarding days, and there are a few good practices I can share:
- It is important to have a kick-off meeting where new team members can meet, the expectations are set and the final output is agreed.
- Always set a detailed agenda for each meeting and stick to it — if you have some difficulties leading this kind of meetings, ask somebody else to be a facilitator.
- Before choosing any OKR, make sure to find and understand the right problems to solve — consistent and continuous discovery is always the key.
- Agree on one or two objectives, and a couple of key results to measure them — don’t try to show off setting tons of objectives and KRs, you’ll lack focus and probably fail.
- Brainstorm ideas in a collaborative way (from “brainwriting” to a more fun “crazy eights” — try a few of them), keeping in mind the problems you want to solve and the OKRs you picked.
- Prioritize ideas with a shared framework — I can recommend ICE, but also others simpler frameworks can do the job
- Don’t do everything together, work asynchronously and share insights at the right time.
- Make your work accessible to everyone (I simply use Miro and G Suite — you can see an example below).
- Define a “from” and a “to” for your key results and make sure to share with the entire team how the estimation was done.
- Run a good retrospective and iterate on the process — we used Funretro and the 4Ls framework.
Finally, it’s time to share your OKRs and hypothesis with the rest of the company, listen to their feedback and eventually iterate on them.
Remember, one of the main principles in this transition is to focus on outcomes, so when sharing your work and hypothesis, don’t mention any deadline, milestone or very detailed initiatives you’re going to validate in the next weeks. You can still agree on some milestones with the team, but they don’t have to be public. If you’re giving feedback or asking questions, please don’t say “so, what are you doing in the next quarter, in practice?”. And, if you are on the other side, kindly educate the audience about the principles — this will be an on-going process for many of you.
Teams are responsible for reaching the goals they set, how they do it might evolve with new learnings, so it can be shared during the process.
Wrapping up
In short, transitioning to autonomous and empowered product teams means:
- Starting with why.
- Developing the desire for a change.
- Setting the right structure.
- Outcomes over outputs.
- Constant and clear communication.
- Giving feedback and iterating on the process to make it stick.
Hope you enjoyed and found this article useful, but please don’t hesitate to give me any feedback or ask questions. It is a learning experience for me as well.
PS: If you would like to get in touch and discuss other topics too, you can reach me on Linkedin.
