Every development team that works with the product has a Product Manager. Sometimes it’s a Manager that works on a daily basis with a team, sometimes it’s a guy that catches up with the team once per week. Whatever the relation is this person usually tells the team what to do next and why it matters. Sounds familiar? In this article, I would like to cover how you can take this relationship to the absolute next level.
A typical development team (a group of 5-8 people):
- Does daily standup
- Works in agile
- Has a roadmap, sprint, and backlog boards that are regularly reviewed by the team
- Analyzes and estimates tasks
- Does retrospectives once per week or two
- Shows their results on a weekly demo
How many of these are usually conducted by the PM? You already know the answer - probably most of them. Why does it work like that?
Cause being in sync, having estimated tasks, sharing results and all that stuff is usually a tool that helps the Product Manager do their job better. It helps to precisely plan, execute and summarize the work done by the team.
But why would only the Product Manager care about that? Why this couldn’t be a “problem” for a whole team?
It’s all about a feeling?
I think it is usually by lack of something that I would call ‚product feeling’. It’s an emotion that connects work with a product. It’s not only the awareness of business KPIs or some other businesses’ direction-driving metrics. It’s a wide knowledge of a product, made by regular use of it. It’s an awareness of users’ issues and needs. It’s a desire to design fast, safe, and bug-free user paths. It could even appear as being an evangelist of a product.
The magic starts to happen when more and more team members start to have such a feeling. Then the whole team purpose is sprouting. And this is the moment when the way that team works changes.
A team that is aware of product needs not because they’re instructed by the Product Manager but because they built that awareness themselves tries to find a way that they can support product growth the best. The team can decide that some routines are not necessary, i.e. drop the daily standups, or they might even introduce some new ones, such as regular regression tests done by the whole team. In my opinion, there is no single way the team will come together on. The most important part is to keep the space for iterations and experiments, which is beautifully called empowerment. The worst thing you can do is to manage such changes. The idea is to ‚reduce’ the Product Manager role to the same team member as anyone else on the team.
How?
How do we do that? It’s probably the most difficult question in this article. How to achieve such a relationship? How to build an empowered, engaged team that is self-organized and constantly improves the team ‚manifesto’.
Leader
It’s good when the team has a leader. I wouldn’t say it’s a must-have, but it might help the team greatly. A good leader can help influence the team through their everyday engagement. The leader might help to find the balance between product and technology needs. Maybe the team has some dysfunctions that the leader might help overcome. A good team leader would know the team’s strengths and weaknesses and how to use them.
But the most important part is to also ‚reduce’ the team leader’s role to a team member and stay far away from management because management is the opposite of building trust, empowerment, and engagement.
Team member
Other ideas are for team members (actually also for a team leader). You have to allow your PM to become a team member. A good start for this is to sit down together and listen to your Product Manager’s needs. Do not focus on the need to satisfy stakeholders or some corporate supervisors. Focus on real needs and think as a team about how you could approach these needs. It’s highly possible that these needs would be similar to the team’s needs. Everyone wants to make the product better, user journeys smoother, and smartly earn more money. Listen to each other.
Product Manager
And finally a few words for the Product Manager. You need to take a step back and stop conducting the team’s work for a longer period. While it applies to the amount of work to do in the team (team capacity) it’s also valid when it comes to all these team routines. Maybe you don’t have to do refinements and estimations for some time? The truth is that you’ll never know what might happen but you need some space for that. Besides that, you also need that willing to become a team member. Listen to the team members’ needs and think about how could you help them. It is highly possible the team will need your wide product knowledge — after all you are an expert in this domain. My approach is that you should put your ego aside and share everything you know to make the team better.
Summary
There is no single recipe for success when it comes to people. It’s a complex system where a relation between cause and effect is only visible in a hindsight. But I strongly believe that you can achieve great results by doing small changes. My suggestion for the first step is to drop any hierarchy in the team and throw all the management away. Team leaders and product managers should be the same team members as anyone else. Only that highly maximizes the chance that the team member’s needs will become the ones of the whole team.