Scaling your Product Team: When and How to Start

So your organization is growing, your products are becoming more complex, and you’ve got more customers demanding your attention and new functionalities. Congratulations! These are all good things, but they can stress product teams that haven’t kept up with the rest of their organization’s growth.It’s important to recognize when it’s time to scale up and think big, which is not always easy for product management leaders that have been running lean and mean since the early days of proof-of-concepts and MVPs. When is the right time to grow the group? What are you trying to achieve by scaling your product team? and how exactly do you do it?These are all good questions for the aspiring product leader looking to evolve with the times. Let’s start by looking at the key moments when growing the team is no longer optional.

When to Scale your Product Team

When you’re the problem

This one is obvious. Product management is working well when the engineers have plenty of meticulously planned and researched user stories, epics, and requirements piling up in their queue. Product management is NOT working well when the technical team is waiting around for product management, or you’re letting things fall through the cracks as you try to keep up with the many demands on your plate. If there’s simply too much for you to do, it’s time to scale up. Don’t be the bottleneck, build a wider bottle.

When you’re adopting a platform approach

Shifting from a single product to a platform is also an excellent opportunity to scale your product management organization to meet the new challenges that presents and skillsets that are required.“You need to make an explicit delineation between customer facing product managers (AKA “Solutions Product managers” in SAAS companies) and platform product managers,” says Wyatt Jenkins of Hired, “Platform PMs are in charge of creating functionality that spans multiple product lines. These PM’s need to understand the large strategic vision well enough to make short and long term trade-offs across different products.”

When you’re feeding the beast at growth-oriented companies

At consumer tech companies, there is often an obsession with growth. That’s not necessarily a bad thing, as growth typically increases revenue and/or valuation. But… rapid growth has two major impacts on product management:

• If it’s successful, you’ve got a ton of scaling issues to worry about that have very little to do with defining new functionality and everything to do with making sure your systems can run through the night without a babysitter.
• Your growth engine is actually a product of its own, with tentacles reaching into web sites, social media, CRM and more.

That’s why many organizations assign product management to growth, or assign growth to product management. For example, at organizations like Uber and Facebook, under their VP of Growth they’ve got product teams (including product managers) for functions like Signups, Notifications and Onboarding. Meanwhile, at companies such as Twitter and Dropbox, they actually place the growth team under the VP of Product, again with individual product managers assigned to core growth functions.Both of these scenarios represent an additional layer of challenges for scaling a product team. If you’re embedding product managers inside of a growth team that has nothing to do with the core product experience, your organization risks each PM and their respective team creating their own processes and habits that might not play well with others down the line. On the other side of the coin, if a PM executive is responsible for non-PM functions, they need to serve two masters.“Pramod Sokke is the Head of Products for all clients on all BitTorrent platforms. He’s responsible for BitTorrrent’s growth metrics and non-growth metrics. Meaning Pramod must develop his product roadmaps for growth and non-growth KPIs because he’s responsible for both sets of KPIs,” reports Andrew McInnes, “People not working on growth initiatives at BitTorrent are confident that he’s prioritizing growth initiatives in a balanced way to ensure the success of everyone in the long run.”And, of course, we all know no matter how great the growth engine may be, it ultimately comes down to product-market fit and user experience. “What is the point in acquiring all those users, if they leave once they see the product?” says Uber’s Andrew Chen. “Growth is an after-effect of strong product market fit and great distribution.”

How to Scale your Product Team

So you know you need to grow, but how do you do it? And how do you communicate the goals of this growth to everyone involved? You’re not simply adding an additional assembly line to the product management factory, you’re building a team of high-performing individuals combining to create something better than before. Here’s a few things to remember:

More product managers ≠ more features

It’s easy to equate an increased product management function with an increased output of new functionality and features, but there are a few problems with that assumption. First of all, a new product manager can create specs all day long, but if there isn’t an additional dev team to build them, you’re not going to see an increase in features hitting the market. More importantly, more features shouldn’t be the goal of scaling your product management team. You might even begin requesting fewer new features as you grow your team, but the items you are asking for will be better researched, more clearly defined and more closely tracked and aligned with your company’s key goals and metrics.

You’re not cloning yourself

While you have plenty to teach your new product managers, the goal of scaling is not to literally replicate yourself. Instead, you’re trying to build a team. And just like a great basketball team doesn’t put five point guards on the floor at the same time, you need to assemble a diverse combination of skillsets, experiences, and outlooks as you grow.

“You have to stop being the product manager or pattern manager, and start being the builder of a team,” says Microsoft veteran Steven Sinofsky, “As a product leader, it’s not necessarily your responsibility to build the product, but to be the creator of a framework for how decisions are going to get made. In doing this, you are allowing people to discover the patterns on their own. Because these might not be patterns you thought of originally, and a new pattern might be on the verge of being created.”This means you need to accept different styles, embrace diversity, and give them a long leash. Sure, they’ll make mistakes that you would have avoided, but that’s how they’ll learn what they need to be successful in the long run. What is essential, however, is establishing a tone and framework that ensures this diverse set of individuals is all working toward the same thing.“In order to grow and scale our product teams, people need a set of values to help them make good decisions that align with what we believe” says Paul Adams of Intercom.

Build or buy

Since no one gets a degree in product management, there’s always the question of whether you pull folks from within your own company into product management or recruit from outside the firm. Many companies often start by converting technical personnel into product managers, under the assumption that their knowledge of the code, systems and players will be advantageous and let them hit the ground running. While this is true, it also means you’re importing their biases and institutional memory into the product management organization while skimping on business chops that an external candidate offers. That’s why some firms like to take a little of both.“We decided to employ a mixed strategy. We hired 5 PMs from the outside, and transferred in 4 from other internal functions,” says Scott Williamson of SendGrid, “We like this combination, as it provides us with a rich mix of PM, email, and SendGrid experience. The ‘SendGrid-grown PMs’ can learn PM best practices from the more experienced team members, and the external PMs can learn from the SendGrid veterans about the customers and technology behind SendGrid.”And just as your product management team may hail from different places, their individual job responsibilities and functions should also be tweaked and tailored to fit their individual skills.“Not everyone has the same idea of what a product manager does, so we tried to be specific about what tasks PMs could own while sharing a vision for what the role could accomplish,” Says Isaac Souweine of Frank & Oak, “By taking an iterative approach, we were able to customize the PM role to the specific organizational and team context at Frank & Oak.”

Laying the groundwork for expanding the team

While product management seems like a no-brainer for product managers, a lot of people in the organization don’t always understand why it’s so important to grow product management at the same rate as the rest of the company. That’s why you need to win over the hearts and minds of decision makers and sell them on the merits of expanding the team.“Given the overall organizational skepticism around the value of PM, I knew I had some bridge building to do,” says SendGrid’s Williamson, “One of my first moves was to set up 1:1s with key players across the company, to listen and understand their issues with PM to that point, and to open lines of communication that didn’t previously exist. Over time, trust developed and with it came the internal support to grow the team.”

This internal campaigning must not only raise the importance of product management throughout the company, it should also focus on getting the budget to hire quality and not just quantity. Top talent with experience will demand higher salaries than a fresh grad or junior engineer looking to see how the other half lives.When it comes to how big your new team needs to be, there’s no perfect answer, but plenty of opinions on the ideal ratio.“Tech companies should have a product management team that vaguely scales with Engineering,” says product management guru Rich Mironov, “50 Engineering folks might suggest 3 product managers; 200 Engineering folks may need 7-10 product managers wrestling with requirements/priorities/markets/interrupts.” Whether you’re basing your new org chart on how many engineers you have, the size of your product suite or which verticals you’re targeting, your rationale should be consistent and defendable when challenged by management.

An ever-evolving organizational approach

Just like there’s no single, perfect product organization, there’s also no product organization that doesn’t need to adapt over time. As your company grows and matures, pivots and expands, refocuses and repositions, your team should also mirror the new directions and goals of the organization.Take Buffer, for example. They’re on their fourth iteration of how they organize product management, beginning with a one-stop-shop approach before breaking up the team into holistic teams, then fluid task forces and now operating under a “goal-focused squads” and “chapters” model.They assign a collection of skillsets to specific squads focused on particular aspects of the product suite (such as “Android” or “Onboarding”). These squads include engineers, designers, product managers, customer development and sometimes growth analysts.Buffer also assigned everyone to chapters, where everyone with the same job role gets together (i.e. all the product managers, all the designers). It’s at the chapter level where they maintain the standards for product management, exchange ideas about best practices, etc.“Not only does this arrangement help us create specialists with great ownership of the challenges they’re working on,” says Buffer’s Courtney Seiter. “It also shows us exactly where we need to grow the team in order to be at our most effective.”Buffer’s approach is similar to those used at Spotify and Hudl. And while the squad/chapter approach creates a lot of high-functioning and purpose-driven teams within the organization, it does come with its own set of challenges.“They rely heavily on squads and team members themselves to communicate openly, challenge themselves by staying uncomfortable, and share knowledge with other parts of the company when it’s needed,” says Hudl’s Jordan Degner. “As easy as that sounds, it can be even easier to stay in the comfort of your own expertise and keep that expertise to yourself.”Of course, not every organization is a great fit for a bunch of independent teams, but the principle of assigning discrete ownership of specific areas is a common thread in successfully scaled product organizations. You have a product executive at the top, and individual product managers take ownership of measurable and contained things.“It should be obvious and apparent what area each product owner runs, what metrics they are responsible for, and how it impacts the business,” says Barron Ernst of ShowMax. “If you have a PM working on special projects that don't advance your startup, it's time to question the purpose of the role.”That means product teams should have a defined area of need and future ownership for any new product management hire. Unlike in engineering–where an extra hand is always appreciated and can be swapped from one area to the next for extra bandwidth–bringing on a new product manager with no specific purpose is unlikely to improve the situation. It’s also the reason product leaders need to create a framework for success when they add members to their team.“Individual product managers are rarely able to define their jobs, or push back on groups that dump random work in their direction,” says Mironov. “Without someone to establish job boundaries, they end up doing a little of everything and not enough of their real value-add.”This brings us back to the most important thing to remember as you scale your team. You’re no longer just “the product person,” you are a team leader. It’s not about what you’re doing, it’s about what you’re team is doing, and how they perform and interact with rest of the organization is a direct reflection on you. So scale wisely…