Product team structure: 6 ways to coordinate a reorg that benefits everyone
The catalyst for rethinking the product team structure at Productboard last year was likely similar to what happens at a lot of other companies. As you grow, structures and processes that worked well when your organization was smaller start to become unwieldy.
There’s a risk that communication could break down, or that “coordination overhead” — the number of stakeholders that need to be involved to move the work along — starts to increase. You reach a point where you want to ensure you get more stability and ownership around the most important areas of your product.
Reorganizing the product team’s structure is not always a response to growth — it can be driven by other changes in the business. The nature of the problems you’re solving and your customers’ needs might have shifted out from under you.
I’m going to share a bit more about how we approached our reorg and hopefully offer some best practices you can apply:
1. Identify the gaps
When I joined Productboard, we had ten PMs already organized across four ‘Tribes’ that were focused roughly on the primary ‘jobs to be done’ that our product solves for our customers. Our reorg didn’t involve tearing everything down and starting from scratch. It was geared towards making sure we were organized around the right set of problems.
This sounds straightforward, but it can get lost as organizations get caught up in a wide range of different projects and priorities. One of the biggest realizations we had leading up to the reorg was that our customer base had shifted towards larger and more complex organizations and we didn’t have a Tribe focused on solving the needs that emerge when large groups of users are collaborating together in one space.
2. Solidify your structure
At Productboard, we refer to the groups focused on a particular problem area as ‘Tribes’ (a name popularized by the Spotify model; you might hear them go by other names in other organizations, e.g. Pillars).
The defining characteristic of our Tribes is that they’re focused on a top-line problem. They consist of somewhere between two to four product teams (made up of a PM, designer, engineering manager, four to six engineers). While the product teams may shift their attention to different initiatives within the Tribe quarter over quarter, the Tribe’s focus area is more stable. Thus, the Tribe leads are able to set a longer term vision and strategy, and are held accountable for defining and driving outcomes for their area of focus.
There are three Tribe leads, each representing a function:
- PM owning value/viability
- UX owning usability
- Engineering owning feasibility.
Going back to our example, as part of our reorg we decided to form a new Tribe (that we call ‘Scale’ internally) to focus on the collaborative needs of our larger customers that hadn’t had stable attention before. This meant that we were able to set a long-term strategy in this area to help our customers understand how we’d be tackling some of their most acute needs.
3. Compromise when needed
Forming a new Tribe meant that we had to move people off of existing teams. While it’d be great to be able to wave a magic wand and make new, fully ramped people appear, sadly that’s not possible. That meant that we had to make a decision about how to manage the impact on existing Tribes.
We wanted to avoid creating Tribes that were ‘in name only’ and aimed to have at least two product development teams per Tribe. This made sure that the teams weren’t too siloed and could easily share knowledge while also reducing the number of cross-team dependencies and boundaries that we needed to manage.
Historically, we had separate Tribes focused on Roadmaps and Prioritization, but with the creation of our new Scale Tribe we decided to consolidate them into a single Tribe. We compromised here because:
- Their respective strategies were closely aligned this year
- They shared a large part of their codebase and teams could work productively across both areas
Wherever you draw lines, you’ll invariably get into situations where there isn’t a clean separation. As mentioned before, there’s no perfect way to slice things, but it is important that clear boundaries are established. It can help to rank the dimensions you think are most important. For us, we made sure Tribes had at least two teams and a perfect mapping of Tribe to problem area.
4. Make it a human-centered process
Reorgs can be stressful because there’s a lot that’s changing, and information that typically cascades through the organization can break down because of it.
The sense of uncertainty can also be challenging for people on the team. People may start to feel disengaged because they’re not sure where they’re going and whether they’ll still be owning the problems they have until now. One of the worst things you can do is have the process drag on.
That’s why, generally speaking, the faster decisions can be made and action taken, the better. 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 time sharing context with whoever now owns their previous area. Go into it knowing moments of miscommunication are likely. Repeating yourself ad nauseam, in this case, is actually a good rule of thumb.
5. Avoid cargo culting
There are plenty of companies that seem to have the art and science of product team structure perfected. You might have read about Spotify’s ‘Squad’ approach, or you might read this post and think Productboard has it all figured out.
We don’t, and no one really does — especially as it pertains to how you should organize your company. Researching how other companies have approached things is a great idea, but take the content at face value. Rather than copy another approach completely, recognize that your company has unique realities — your product release cadence, the kinds of customers you work with, how you’re geographically distributed, the strength and experience of your current team, etc. This all plays a role in how best to structure things.
Try to learn from the principles that have worked in other organizations but be prepared to adapt them. You should feel confident that you understand the ‘why’ behind all of your decisions, otherwise you’ll never be able to explain it to others satisfactorily.
Also, don’t do too much at once. Trying to make wholesale team changes, process changes, and organization changes at the same time is a recipe for failure. Instead, think of this as building a new habit. Once you’ve got one change squared away you can move onto the next.
6. Change is hard, but necessary
One of the reasons that Productboard aligned around the Tribe model was that, at a certain point, it becomes impossible for the senior leadership team to have deep context about all the problem areas a product is designed to address.
Having an additional layer of Tribes gives each team more autonomy in their respective areas and helps make sure nothing falls through the cracks. It also helps establish Tribe leaders as experts of their domains across the broader organization.
The process to get there, however, can be bumpy. Companies can’t halt everything while change is happening, which can make the process even harder. That’s why no matter what structure you ultimately decide on, it’s so important to clearly define areas of accountability, responsibility, and ownership, and to sell the vision behind the change.
Remember: you’re not blowing up the existing plan. A reorg should be seen as part of the plan. As organizations grow, change is necessary to make sure the company evolves alongside its customers and market. The end result should always be the same: that the product team is working on the things that matter most for both your customers and the business.
