How a Product Manager can build ownership and autonomy in their team
Have you ever worked in a team and felt like you were always the most enthusiastic about the product you were all building? It’s quite lonely championing a product by yourself and energy-draining if you’re always having to motivate those around you. Often, the person that feels this way is the Product Manager and for quite an obvious reason: the Product Manager typically spends significantly more time sympathising with the end-user and understanding their problems/needs. They’ve hypothesised the impact that a solution is going to make and can’t wait to get it out into the world. But what about those building it?
Often, developers are so far removed from the WHY that they rely on the Product Manager to tell them what to build. Without having any empathy for the end-user, developers are unlikely to keep them in mind when innovating and building a solution. As a result, detailing what should get built in the form of user stories becomes a full-time job. Companies sometimes hire Product Owners to take on this responsibility so that Product Managers can focus on figuring out the next problem to solve. When the right solutions are still not being delivered fast enough, Scrum Masters are sometimes hired to protect the developers from distractions and aid in efficient delivery cycles.
Involving developers from the START
What if developers understood a problem/need just as well as the Product Manager understood it? What if… are you ready for this… they stopped coding and joined the Product Manager, designers, and researchers in workshops to unpack the problem and contribute to potential solutions?
A developer that is always busy coding is not valuable if they’re not solving the right problems. When you bring a developer into a workshop or design sprint, you add a unique lens for the problem to get looked through. Their understanding of the infrastructure and underlying systems also gives them an edge when brainstorming solutions. Trust me, if you’re not involving them in these conversations, you’re only realising half of their potential.
In a typical design sprint, the Product Managers’ responsibility is to come in with a well-defined problem statement. They’re encouraged to not jump straight into solution mode and instead, first explore the problem space further with all the people that will actually be building the end solution. Doing it this way shifts the narrative: instead of getting told what to build down the line, developers are encouraged to get to the crux of the problem, vote on where they think the biggest pain points lie, look for inspiration in other products, and put their own ideas on paper. This same energy often gets carried into the building phase and, just like that, the Product Manager isn’t the most enthusiastic person in the room anymore! The need for a Product Owner and Scrum Master also begins to diminish when developers start to work with the Product Manager to set goals together, decide what the first ‘thin slice’ of the solution looks like and how they want to build it.
The Tech Lead + Product Manager power duo 🤜🏽🤛🏽
It sometimes isn’t possible to carve out time for all the developers in a team to attend every workshop, design sprint or usability test — and that’s okay. There is one person, however, who should be kept close to all of this and that is the Technical Lead. Product Managers and Tech Leads have very complementary skill sets — the former’s strength lies in understanding what we should build and why we should build it and the latter, how we should build it.
Practically speaking, a Product Manager partnering up with the Tech Lead means sharing insights into discovery work, business strategy, and user data so that there is a mutual understanding of the problem the team is solving and the urgency behind it. It means healthy debates on whether we’re working on the right thing or taking the right approach, weekly catch-ups, raising technical blockers early on and together, finding ways around them. The Tech Lead is the best partner that a Product Manager can have in building products and when they have the right connection, they are unstoppable.
Developers should dictate the HOW
One of the benefits of having the Tech Lead as invested in a product as the Product Manager is that they will start to champion building it. A Product Manager does not always have the knowledge and experience to best make decisions on how a product should get built. Backlog grooming and sprint planning can begin to feel very authoritative if the Product Manager is leading the creation of user stories and tasks. It can very quickly turn into an exhausting back-and-forth, with the Product Manager trying to get as much out of the team as possible and developers, in turn, trying to defend their time.
Agile promotes self-organising teams and to achieve this, the Tech Lead needs to be given the autonomy to figure out with the rest of the development team how they build a solution. There is usually a lot of anxiety with giving teams this level of autonomy but, when the Tech Lead is aligned with the Product Manager, you usually have nothing to worry about. The same goes for almost all Agile rituals — most of them have been developed for the benefit of DEVELOPERS. They assist in how teams work together and build products but shouldn’t be forced or done just for the sake of saying you’re Agile. Instead, they should be tested, adapted, and incorporated, or discarded depending on how useful the team finds them. Every team is unique and part of the fun is figuring out what works for you.
Creating a shared sense of ownership over a product and building autonomy in a team takes time and requires the support of an organisation to make this part of their culture. Once you have it, it’s a game-changer but you also have to maintain it! The Product Manager should keep sharing results and learnings with the team as they iterate, you should revisit the goals you’ve set together and retrospect regularly so that you keep challenging one another to improve how you work.
Keep learning. Keep sharing. Keep building impactful products ✌🏽.
