Leading a product team during a high-growth period can be exciting. The team grows, roles shift, output increases, and many other pivotal changes happen within the product team and the organization as a whole. At the same time, rapid growth can present some challenges for product management. How do you ensure everyone keeps things moving at the same pace as the team grows? How should you structure the team? As the headcount increases beyond just one or two product managers, how can you maintain a consistent product culture?
These are all valid questions for product people at high-growth organizations. And the good news is, you’re not the first to ask them, nor will you be the last. In today’s article, we hope to provide some tips for navigating some of the most common product team growing pains and overall, product management scaling secrets. We’ve curated stories from seasoned product managers about what they’ve learned while scaling product management and provided our own takeaways for you to consider as you scale your own product team.
Problem: Getting executive buy-in on every product decision does not scale.
When a product organization is small, it’s not uncommon for each individual product decision to go directly through the executive product team. But, as an organization grows, access to executives may not be possible for every single decision. How can product teams keep the executive team involved in their process without too much red tape?
Solution: A lightweight structured process drives shared understanding at Dropbox.
Sean Lynch strongly believes processes are the answer. He says a lightweight structure helped Dropbox scale product management. He stepped in as a product manager at Dropbox while the product team was still fairly small. At the time, he says the company’s co-founder and CTO personally reviewed almost every product decision. As Lynch recalls, the CTO was busy, but the review process seemed to work well while the team was still small. However, as the team grew, it became difficult for anyone to get time with the CTO.
As a result, progress started to slow down. According to Lynch, by 2014, the product team was getting increasingly frustrated with its inability to get time with the CTO for feedback and approvals on decisions. At this point, another product manager at Dropbox, Anand Subramani suggested a basic framework for reviews during each stage of a project.
The framework breaks each project down into three phases and defines what type of feedback is required during each phase, explains Lynch. Each phase was designed to get consensus around a specific question:
- Phase 0—What is the problem we’re solving? Why is it worth solving?
- Phase 1—How are we going to solve that problem?
- Phase 2—What does our solution look like?
In an article about his tenure at Dropbox, Lynch goes on to explain that the specific framework itself is not necessarily what helped the most. Instead, he says, the framework’s value came from the shared understanding it provided.
The framework accomplished this in three main ways. First, it standardized both the type of feedback and depth of feedback that would be given at each phase in a project. Second, it split up “problem” and “solution” agreement. Therefore, stakeholders would agree on the problem at one phase, and the solution at a later one. This kept everyone aligned. And finally, Lynch says the framework was so simple that the entire organization could use it.
The Takeaway
A little structure goes a long way when it comes to scaling your product team. Many organizations are against using too many formalized processes and tools and favor instead of people and interactions. And while this advice can generally help your team be more agile, it may not apply 100% of the time. In many cases, as was the case with Dropbox, a formalized process actually helped the team be more agile by eliminating several layers of red tape. So, don’t be afraid of all the processes. Some can help you, especially as your team grows.
Problem: What worked yesterday doesn’t work today and what works today won’t work tomorrow.
It’s not uncommon for managers to stress about team structure as they scale their team. Product management leaders, in particular, may worry about “getting it right” the first time with their team’s structure. But with endless possibilities and no one-size-fits-all approach to product team structure, getting things “right” the first iteration is unlikely. And that’s ok, as long as you accept that your team will (and should) evolve over time, and embrace changes as they come your way.
Solution: Buffer’s product team is constantly evolving, and they embrace change.
Over the years, there have been many iterations of Buffer’s product team structure, and they continue to make improvements as they learn. Initially, the product team was simply that, “the product team.” During this iteration of Buffer’s product team structure, there was a single, scrappy, product team in charge of all aspects and features of the product.
While the team was still moderately small, it was easy to work within this structure. However, as the team grew, things became more disconnected and fragmented. At that point, Buffer switched their product team to what they call the “decision maker model.” This model featured a cross-functional team of representatives from various departments. Each cross-functional team featured a “decision maker.”
In their quest to continue improving their team’s structure and underlying processes, Buffer eventually decided to move away from the decision maker model in favor of what they call “fluid task forces.” These were cross-functional task forces focused around specific goals.
“Over time, we began to crave a more sustainable way to work—one that would allow us to focus in an area and become specialists, with ownership and accountability,” explains Buffer’s Courtney Seiter. That’s why Buffer’s current iteration of its product team structure is similar to Spotify’s product squad approach, with a few modifications. Each of Buffer’s cross-functional squads focuses on a single goal, and within each squad, there are several role-based chapters within each squad.
Despite its confidence in the current product team structure, the Buffer team says they will continue making changes to better suit the needs of the team. Because as Seiter explains, “We’re constantly learning more and evolving.”
The Takeaway
Change is the only constant and software is not the only thing that should be iteratively developed. Recognize that growth requires some experimentation, and often you have to get it wrong a few times to learn. Don’t be afraid to make drastic changes if something isn’t working. Continuously adapt and evolve as you learn. Your product is changing. Your team is changing. The world around you is changing. Shouldn’t your approach reflect that too?
Problem: Maintaining consistency across product values, vision, and culture is difficult at scale.
They say two heads are better than one. And in many cases, adding more minds to your team can help provide a broader perspective. However, as you’re rapidly bringing more product people on board, how do you convey to them how to make decisions? As your team goes from one person to five or more, how can you maintain consistency across the board?
Solution: Standardized guidelines for decision making empower and align Intercom’s growing product team.
How did Intercom successfully grow its product team while maintaining a product roadmap that the entire organization could rally behind? According to Intercom VP of Product, Paul Adams, one of the team’s secrets to success is a standardized set of guidelines for product decisions. Adams recently shared some lessons learned from scaling a product team and pointed out the importance of defined parameters for making decisions.
“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,” he explains before outlining 5 of his team’s guidelines.
The guidelines share some similarities to the values and principles laid out in The Agile Manifesto. For example,”we optimize for face-to-face collaboration” and “many small steps are better than bigger launches.” Beyond helping the team make smart decisions, the guidelines also help support a healthy product culture that is unique to the product team at Intercom.
The Takeaway
Document, centralize, standardize. One of the best things you can do to maintain cohesion and shared understanding across your product team and the organization as a whole is to define parameters for decision making. If you document the things that matter most in your team’s decision-making process, you give your growing team context into how to approach decisions that they otherwise would not have. This context also helps empower the team to make decisions confidently because they know what matters to the organization.
Problem: Empowering teams to innovate and work autonomously while also maintaining focus on key objectives.
We’ve written before about a few reasons enterprise organizations may struggle to innovate at the rate and capacity they’d like to. We’ve also heard several stories about how product teams evolved over time to find that perfect balance between experimentation and planned development. As product teams scale up, it’s not uncommon to struggle to find this delicate balance.
Solution: Amplitude’s autonomous teams can look to their north star for guidance.
As the product team grows, preserving a sense of autonomy and empowerment is important. Too many layers of management and lack of access to resources can slow down product teams. Not enough guidance from the top can lead to the delivery of the wrong solutions. As Amplitude VP of Product, Justin Bauer, explains, the structure of your team has a lot to do with how well it will perform in the future.
That’s why Bauer decided to organize the product team at Amplitude in “pods,” focused around a single “North Star Metric.”
“We define pods as small autonomous groups of people defined by their common objective and measure of success. These objectives are tied to the broader product strategy, and as such can shift around depending on the needs of our users and the business,” explains Bauer.
There were several underlying goals behind Amplitude’s pods. First and foremost, the team agreed that autonomy and the ability to innovate quickly is of utmost importance. The pod approach, which is modeled loosely after Spotify’s product squads, ensures each team has sufficient resources to work autonomously.
In addition to the cross-functional nature of pods, the form of the goals they pursue also helps encourage autonomy. Each pod has its own set of goals and objectives to pursue but has the freedom to decide how they approach them. So, while executive stakeholders hold the pods responsible for high-level objectives, they do not dictate the specific initiatives the team must pursue to accomplish them.
Finally, borrowing from Amazon’s two pizza rule, Bauer’s team keeps their pods small. This way, they can minimize communication overhead and stay as productive as possible.
The Takeaway
Define the what but not the how. One reason Amplitude’s pods work well is the teams within them know what they must achieve but have flexibility around how. This flexibility helps support the team’s creativity, encourage experimentation, and empower the team to make decisions on its own. At the same time, the team is on the same page about the desired outcomes, and executive stakeholders have bought into those outcomes. Therefore, experimentation is focused on moving the right metrics.
Different Teams = Different Challenges
Despite their various stories and approaches to scaling product management, each of the product management experts in this article shares a common belief: The process and structure that works for one team is not by any means universal. So, our final takeaway for product leaders who are scaling their product teams is to take what you’ve learned here and adapt it to align with the unique needs of your own product team.
What are the most challenging aspects of growing the product team? Let us know in the comments below.
