Product Teams: striving for Autonomy & reaching for Business Agility
Within The Netherlands, bol.com is known for being an early adopter of agile practices and has been an example for a lot of companies in their (agile) transformation. But while I was working there as a product owner I still felt that we were not quite there yet regarding agility.
The main struggle I faced was the lack of end-to-end responsibility of a software development team hence for me as a product owner. But as I never had the hands-on experience of working with full-blown multidisciplinary teams with end-to-end responsibility myself, was it fair that I said we should change?
Then the opportunity came to work at a company that was working in this fashion, the company I currently work for, Onefootball. And although the companies are not comparable (2000 vs 200 employees, 100 vs 5 engineering teams), I am truly convinced: every company should try to organize their teams to have end-to-end responsibility. I call them: product teams.
In this article, I try to explain what I mean with product teams and the reasons why I think every company should strive for them. Then amplifying these arguments with some of the anti-patterns of non-product teams.
I know a lot has been written about this subject and it has been called a lot of different names. So keep in mind that this is just my way of explaining things, based on my experiences, and I hope it can help you to reflect on your own situation.
Product Teams
When I picture a Product Team, I think about a team that has all kinds of different roles within the team, that is fully autonomous and that has a clear customer (focus).
Multidisciplinary teams
Probably a term you heard before. For a team to be autonomous you need to have all the expertise in place, and ideally, all these crafts have a dedicated spot within the team. This does not only mean being able to cover the entire technology stack (front-end, backend, infra) but also being able to design solutions, doing user research, and so on.
Does this mean one or multiple FTE’s for each expertise/role? Maybe, maybe not. This comes down to practicalities and nobody can say without knowing your situation what will be the best way of organizing it. But it means that the team should have access to all the expertise at the time the team needs it.
What you can read between the lines here is that this also means that “business” and “IT” are working together as one team. Or at least that these two teams are so aligned that they can operate as one team, working together on a daily basis and being able to make decisions fast.
Autonomy enables Continuous Innovation
With end-to-end responsibility I mean teams being responsible all the way from idea generation until the customer feedback (looping back to idea generation). And giving them the tools to make all the decisions regarding their product themselves. Full autonomy.
Why would you want to give your teams autonomy? Well if you ask that question, it makes me a bit sad, but okay… I will bite. There is a lot written about this already, but for me there are two main reasons: agility & drive.
- If you are not new to the agile world, you probably know that to be really innovative and moving forward in a fast-changing world, you need to be able to respond fast: to be agile. The more you empower teams to make decisions themselves, the easier it is for them to respond while working on the product.
- Empowering is not only good for your business, it is also good for your people and their motivation. If you haven't done so already I would highly recommend reading the book Drive of Daniel Pink. He explains very well what motivates people, and surprise surprise, one of the three factors is autonomy.
A Product has a Customer
Why do I call it product teams? Well, that is simple: you are responsible for a product. A product that has customers. You know, those people who you try to create value for. The people who determine what you do and the reason for existence as a team or even as a company.
Although that sounds obvious, it might not always be the case. Too often I heard teams naming all their (software) services or API’s when answering the question for what product they are responsible for. And although there are cases where this is actually your product, and the people/developers consuming your API are actually your customers, most of the time it is just blurring your real end-user.
If you get to the point where you cán identify your (end-)customer, where you cán talk to them and start to really get to know them, you should be very happy. All of a sudden it becomes so much easier to improve your product. You can use real-life customer feedback from yesterday to improve the product today and have happier customers tomorrow. Yes, that sounds like the agile dream, but with modern software practices, it can be a reality.
You can use real-life customer feedback from yesterday to improve the product today and have happier customers tomorrow.
And again I will refer to Daniel Pink. Next to autonomy he also mentions purpose as a motivator. People want to make an impact and most of the time this means an impact on other people (and their lives). I can not tell you how fulfilling it is to release something and have a customer tell you the next day how happy he or she is. Or the other way around: how motivating it is to hear customer problems, real struggles from real people, and being able to solve/work on them the next day.
At my team at Onefootball, we have a slack-channel where customer feedback is coming in real-time (using a Usabilla integration) which is highly motivating/rewarding, to say the least.
Antipatterns of Non-Product Teams
Sorry, I don't have a very creative way of describing "non-product teams". Teams that are not organized based on (customer) products but something way more practical, like based on a certain skill set, the size of the team, or on the software architecture that is already in place.
In those teams it will be super hard to really work autonomous as a team and also to feel the connection with the customer, affecting the agility and the motivation of a team. Because what happens with the customer feedback? And how are new ideas introduced? Most of the time this needs some kind of coordination or governance structure, caused by the dependencies between the teams.
The Idea Waterfall
We live in an ever-changing world and that is also very true when it comes to software development. I don’t want to pretend like I am some dinosaur who has seen it all and say things like “remember the time…” but… well, fuck it, I will do it anyway: remember the time where teams were only responsible for the development of their software and not for deploying and running it?
I experienced the DevOps movement first-hand and it was the next step in working agile at bol.com. Teams taking responsibility for the delivery ánd the operations of their software. It was awesome to get this autonomy as a team. There is a reason why we said: You build it, You run it, You love it.
So now picture these super agile (software development) teams. Working sprint by sprint, user story by user story, developing software, deploying it to production, and making sure it keeps on running smoothly. Isn’t that what autonomy is all about?
But what about this phase before the development starts? What if the discovery for ideas is not the responsibility of the team that also does the implementation? What if there is an entire (business) team of people working on ideas, figuring out what the value is of solving a certain problem, or developing a certain feature. Where this team is building business cases for weeks if not months, only to then pitch it to a manager or product owner of a team who needs to give them the bad news: sorry our roadmap is already full.
How do you make sure you get their attention and get it on the roadmap? Well, you can do two things: make your idea bigger (they need to pay attention to the next big thing right?) or maybe just picture the numbers and value a bit better, I mean.. otherwise all the work you put into was all for nothing.
I hope it is obvious what the risk is of this idea waterfall.
- People will work weeks or months on something that will never be implemented.
- The ideas will become huge projects.
- And if they are actually going to be as valuable as projected, well.. let’s see. Because probably there was also no time for an experiment right?
This is exactly why you need to treat this discovery phase as a funnel. Not all ideas should be researched, not all ideas should be prototyped or experimented with. This elimination can be done before you decide not to implement something. For that reason it makes the most sense to give the ownership of this discovery funnel to the same team that is responsible for the delivery. Because they know their velocity best, and they know when there is a big need for new ideas or when it’s best to spend your energy elsewhere.
Blurry Customers
Too often I heard teams naming all their (software) services or API’s when answering the question for what product they are responsible for. And although there are cases where this is actually your product, and the people/developers consuming your API are actually your customers, most of the time it is just a dependency in disguise. With your real customer out there somewhere, but the view and connection to them “blocked” by another team.
If you want teams to have end-to-end responsibility they need to be able to identify the product they work on and the value they create for… the customer.
In the way of working I described earlier, it will be really hard to handle small requests based on user feedback. Because with the “discovery team” responsible for the innovation, and the “delivery team” for the operation, what happens to optimization?
If the user feedback will be heard by the delivery team at all, they probably have no time to implement it. Because how can this user feedback compete with all these big ideas that people have been working on for weeks or months? And how are you going to organize it with all the dependencies with the other teams to make this happen?
Sometimes you will see a pattern that teams have optimization weeks, time that some product owners or teams probably had to fight for. Handling all these piled up small requests and trying to implement as many as possible. Different teams working together and bringing value with incredible speed. If you ask any team that experienced such a week, they loved it. They could work on something they know that sucked and customers have complained about for months or years.
My point is that although these are incredible initiatives and I credit and applaud any person that starts them, they should not be needed. Teams should be able to make the decision to pick up a story based on customer feedback they got, in-scope it in their sprint, and get it done. This should not require any pitching of time, or any hard coordination or process.
Because come on… if you wake up as an engineer, a designer, or any other role within a team, and you want to improve your product and make an impact on your customer, but you don’t because it will take too much of your energy to coordinate… there really is room for improvement.
How to create Product teams
So I hope by now I could convince you a little bit that product teams are the way to go. And if you want to move towards product teams, why not organize them around the products you have?
For small companies this is simple, it might be the entire product. But how do you do it for large organizations? Do you split it by feature? Do you split it by customer type? I will not pretend I am some kind of team organization expert, but there is a lot of good theory about this ever-interesting topic. I would really recommend reading the book Team Topologies. It gives a simple framework explaining the different nature of teams and guidelines on how to organize your teams, combining all the existing theories out there.
Wrapping it up
I hope I could share some of my passion for product teams and inspire you with some of the (anti-)patterns I have seen and have experienced. I know it’s not an article that will guide you in re-organizing your teams but I hope it did trigger you to think about how you can improve your own setup, strive for autonomy and reach for business agility.
At bol.com I noticed already that I was not the only one who questioned our team setup. So I playfully promised a group within bol.com that I would come back to share my first learnings with them, which I did. I gave a talk at the conference of bol.com: Spaces Summit, which you can watch below.
