4 principles for optimizing the structure of your product organization

You have your product vision and roadmap — but do you have the right groupings of people to actually execute your plan? And will that structure stay the same months (or even years) down the road?

Every product leader inevitably faces these questions as their organization grows and changes. Reorganizing a scaling product team — optimizing the way people collaborate and drive work forward — is among the most crucial factors for delivering the right products and features to market, faster.

The challenge: the optimal structure of any product organization won’t stay the same. Not everything can be your top priority, so you might find yourself needing to move people within the organization to avoid groups becoming understaffed. There’s a risk that communication could break down, processes may become unwieldy, or that “coordination overhead” — the number of stakeholders that must be involved to move the work along — starts to increase. Before you know it, teams become so focused on their areas of responsibility that they become siloed and ineffective.

As teams scale, the ideal product team structure must change to meet the needs of the organization. The optimal org is whatever drives the most alignment through clear ownership and collaboration. And while there’s no one-size-fits-all formula, we’ve found the most successful product leaders follow a set of guiding principles as they scale their organization and structure their teams.

4 principles for structuring your product teams for scale

Most product organizations (both large and small) follow one of three overarching principles when structuring their teams, while some (Productboard included) tend to mix and match different options depending on needs. Remember, choosing one principle doesn’t mean you can’t consider the others — the right approach depends heavily on the pace of innovation for both your organization and your industry.

Organize around the problem space

Rather than starting with solutions, many companies organize product teams around core user problems—or jobs-to-be-done—and how your product addresses those needs.

Facebook is a great example of this. Instead of organizing teams around creativity-related solutions — for example, photo sharing — Facebook realized there will always be a need for users to express themselves. They, therefore, started a Create team, responsible for all of the features and functionalities that help users be creative, like Instagram filters and Facebook Stories.

Organizing teams around the problem space gives teams more flexibility in how they solve problems, so this structure makes sense for early-stage startups that may still be seeking product/market fit. It’s also a great option if you have a stable product and you want to continue to innovate and disrupt yourself, as Facebook did with their Create team.

The one downside to the problem-space structure is that teams may take longer to arrive at a solution since each problem has many potential answers. But you can be sure that the eventual solution will be as valuable as possible as it’s designed directly around user needs.

Organize around the solution space

Organizing teams by solution space instead of problem space trades off open-ended ambiguity for a lot of clarity on what the teams work on. 

This strategy works best for teams post-product/market fit, when you have a stable product you’re seeking to improve over time. Amazon, for example, organizes teams around strongly-defined areas of e-commerce — a homepage team, product detail team, search team, and checkout team. Each solution offers very stable functionality, so teams are organized around making those functionalities better.

Organizing by solution space makes sense when you’re in a large, scaling organization. It makes it easy to describe what different teams do when you’re hiring, find the right person to talk to in the organization, or facilitate when team members are trying to switch roles.

The downside: the solution space can be a scary thing for problem-oriented people. But, it brings clarity to your domain and you can still innovate if you’re diligent. Amazon’s orders status page, for example, has changed many times over the years and just keeps getting better and better. Even if it only takes a few hours for your package to be delivered, users still enjoy returning to that page to check the status of their orders, which is why it makes sense for Amazon to invest in improving the data flow and order tracking functionality.

Organize around customer segments or personas

Most organizations have a meaningful set of personas and customer groups that are well-known among stakeholders. Organizing around these personas gives everyone on the team a focused understanding of user needs, maximizing their chances of building and launching valuable products and features.

It’s a method best suited for teams with well-defined personas that don’t change often. Often, there might be a specific segment that is very valuable to your business. For example, Miro has a large group of customers who are workshop facilitators, so they have a team dedicated to these users and their needs.

Organizing around personas works particularly well if you have an existing business and want to enter a new market or launch a new product, but don’t yet have a specific problem you want to solve. You might not know what the problem is to solve, but you have a segment of the market you want to innovate for. Organizing teams around that segment is a great way to innovate and explore the new market.

Mixing and matching different product team structures

None of the above principles are perfect for every situation. The good news is that none of the principles are mutually exclusive. You might have certain personas that are really important to the business. You may also have a specific problem domain you want to focus on as well as specific solutions which require dedicated teams to drive innovation.

In this situation, mixing and matching different product team structures can be a godsend. In fact, it’s the approach we take with our teams here at Productboard:

• We have a growth team that owns the problem of new user onboarding and thinks about ways to drive additional product-led growth, like our free Customer Feedback Portal
• We have dedicated prioritization and roadmapping teams optimizing solutions
• We have a Scale team focused solely on growing our enterprise customer segment

We’ve found the hybrid approach makes it easier to talk about the organization’s broader mission in a concrete way, but still gives individual teams the freedom to own their specific areas of responsibility.

Mixing and matching structures works best once you have more people. Early-stage startups with fewer than 50 people will find the most efficiency by sticking with one principle, but once you reach 100-150 people it becomes easier to allocate enough resources across enough areas.

3 tips for avoiding reorg chaos

The right product team structure depends heavily on your business, your customers, and your market. But every product leader can benefit from following a few best practices to maximize transparency, alignment, and speed across the organization.

Align on key product areas that drive business

Identify key segments you want to support and key points of friction that you want to improve. If a significant portion of your business comes from a segment, organize your teams to focus on it. Rank the dimensions that are most important, and use those to choose the best team structure for reaching your goals. For Amazon.com it’s e-commerce. For Facebook, it’s content creation.

By building alignment around the why behind a restructuring, you’ll have a far easier time optimizing what your teams are working towards. And the faster decisions can be made, the better.

“Rip off the bandaid”

Once leadership teams have aligned on a new product team structure, execute on the agreed-upon changes quickly and decisively. Rip off the bandaid, so to speak. 

Let’s say everyone starts hearing about a potential reorg on Monday. You’ll want to start implementing changes on Tuesday. By Friday, the reorg should be complete, with everyone focused on how the new setup works and how they can best collaborate moving forward.

The goal is to avoid gossip and speculation while minimizing any fear and uncertainty that gets people distracted from your mission. Running a business is hard enough. You don’t want people to stray from doing their best work because of unnecessary stress.

Build transparency (and earn buy-in)

Reorgs are challenging. Minimize that stress by being transparent and ensuring that information doesn’t break down as it cascades through the organization.

Talk to people about the changes. A lot. We’ve found that getting visual — drawing something in Figma or another tool — helps stakeholders and team members understand the topology of the organization as you scale. Prepare for the knowledge transfer that will have to happen between team members, and know that post-reorg, teams may still need to spend a decent chunk of their time sharing context with whoever now owns their previous area.

There’s no one-size-fits-all approach to scale

Finding the right product team structure that maximizes your potential for scale isn’t easy. The optimal structure is whatever drives the most alignment through clear ownership and collaboration — but the process to get there can be winding, and you can’t exactly halt everything else while you chart a course. 

Be certain in your decisions, and know that even if they might be painful in the short-term, restructuring is a necessary part of achieving scale. Regardless, the end goal should always remain the same: building products that matter.