Scaling your Product Management team

Building a Product Management practice (3/3): In this final post of the series I will share some hard earned advice on what’s important when you grow your PM team

Feb 01, 2021

In my last post I wrote about building a wide range of skills in your PM team and the importance of having a solid foundation that allows you to scale. However your job is not done here yet.

As my Product Management team grew, new challenges arose:

⏳ decisions started to become slower

🗒 consistency in processes across the various teams started to slip

⏰ I didn’t seem to have enough hours in the day to spend enough time with every report

Looking back a lot of my learnings on this journey came from trial and error. I would hold on to certain activities for a little too long, then adjust. Or hand over responsibilities without spending enough time coaching, then adjust again. The following advise hopefully prepares other PM leaders or also PMs to be more mindful of the necessary changes when the team is growing.

Set up your team for decision making

When you’re a small team, the Head of / Director / VP of Product and executive stakeholders are often involved in every big meeting or product decision. As I have experienced and other examples from Dropbox and Intercom echo, getting everyone’s sign off on every product decision does not scale. So how can you avoid lengthy review processes that become a bottleneck for all teams?

I know you’re here to read about scaling PM teams and not about organisational redesigns, but it’s important to understand that often the root causes of slow decision making lies in how product teams are organised in the first place.

I regularly talk to a lot of PMs in different countries and industries and I almost always hear that they run “cross functional product teams”. But when I dig further, the company either still thinks and works in departments, has shared part time resources floating between the teams with little ownership, or have massive dependencies on some specialised teams like the core platform team.

The key is to organise product teams so they have all the skills and ownership over a specific product or product area. Whether product areas are organised by customer problem or functional area or something else does not matter for this argument - the key is that one product team should not have to largely rely on another product team to (hopefully) re-align their team objectives to get anything released to the customer.

Having a cross functional team isn’t enough yet. You might have all the different roles, but the team might still be operating as a feature team. For true scale and successful product outcomes, those product teams also need to be empowered to tackle problems and make product decisions.

As Marty Cagan has shared in his article on product vs feature teams, both teams can look very similar on the surface, but can dramatically differ in how they operate. A feature team’s main job is to deliver, while a true empowered product team has the ability to solve problems and be accountable for the outcomes.

Marty’s latest book Empowered is a fantastic read if you want to learn more about team topology and of course, empowerment of teams. John Cutler also has some great articles on the common signs that you might be working in a feature factory.

Why is this all important for scale?

If decision making about what needs to be built is being kept on leadership level, bottlenecks will arise very quickly as your team of Product Managers grows. It’s not only about efficiency - it also truly reduces the sense of ownership and accountability in your Product Managers and the product teams.

Beyond the team structure to enable scale and ownership, you as the Product Management team lead (whatever your title) is to provide the right tools, context and principles to make the right decisions without always requiring your input.

As a VP of Product I often feel like a broken record talking abut the importance to leverage our company frameworks and tools for designing and delivering products. The point of that is not to follow processes for the sake of following processes, but much more that it enables better decision making aligned with the core principles of how we work in the company. Assuming the company’s frameworks follow modern product practises of course.

This also leads to more trust from stakeholders in every product decision. It flips the conversation from “policing” every decision that is being made across the company (and trying to hold onto this process as more PMs join the company) to: have I as a PM manager enabled them with the right frameworks, ownership and knowledge to make good decisions in the day to day?

Final 2 Cents

Equip your PMs with the right skills and frameworks for better efficiency but also true ownership. It is certainly not the easiest, but the only truly sustainable and effective way to grow the Product Management and product teams.

I still go deep into some products or product areas sometimes when I’m being asked for assistance of course. This should always be done from a coaching lens by the way, not to dictate solutions. But it’s important to realise where to best spend your time as a PM manager, and that you can’t stay across all details as you grow.

Letting go of the details has been hard for me, and coaching is even harder. There is also still a lot I am pondering about like how exactly to scale the coaching part of my role or team structures as we grow even further.

I always love to hear from other product leaders on their learnings and current challenges, so please reach out via LinkedIn or Twitter or leave a comment to share your wisdom! 🙏

The Insights Driven Product Manager

Discussion about this post