Evolving the organizational design (or, as it’s more commonly known, re-orging) usually greatly impacts the affected team. Organizational (”org”) design defines who reports to whom and who works on what. This means that re-orgs usually require the product org—and typically, its cross-functional peers—to change how they work, what they work on, and who they work with and report to. They can disrupt personal relationships, responsibilities, goals, and sometimes even job security. This can cause unsettling uncertainty and damage team morale.
Yet it is often necessary to re-org to align the org design with the product strategy. In this article, we’ll consult our experts to walk you through what a re-organization is, how to know when one is needed, how to design the new org, how to communicate the changes, and how to measure if it worked.
But, as with most complex issues in business, there’s no “silver bullet” way to go about this. Sanchan Sahai Saxena, former GM at Airbnb says, "There's never one answer for any of these things. You always have to have nuance. Organizational transitions require careful consideration of various factors, from culture to operational structure. There's no one-size-fits-all solution; each situation demands a nuanced approach tailored to the company's unique context and challenges."
Let's dive in to those nuances.
What is a Re-Org?
A re-org, sometimes called “org transformation,” is when a company restructures how a company's product teams are organized and operate. This can include transitioning from traditional functional leadership models to GM structures, establishing product operations roles, or redefining team responsibilities and processes.
For the purposes of this article, we will focus on the Product Organization, but re-organizing any part of the company has ripple effects. Ely Lerner explains, “[Org transformation]... it goes deeper than just the product org... changes are often more wide-reaching than just the product... reaching into how you structure engineering, how you structure sales, customer success, support, and so on.”
Re-orgs are pursued for a number of reasons such as improving efficiency, fostering better collaboration, modernizing the team, mapping resources to evolving strategy, and more. People and teams are arguably the most powerful strategic levers your business has, so it’s crucial to constantly evaluate if your organization design is serving your strategy.
There is nothing more important for a re-org than knowing if you need to consider one or not.
Ben Williams said, “Ultimately, a transformation implies going from one state to another state. And you have to have a solid reason for wanting to move from your current state to that envisaged state.”
In the next section we’ll explore some signals you can keep in mind when mulling over whether or not a re-org is needed.
How to Know When and If A Re-Org is Necessary
Re-orgs as a strategic lever should be used sparingly and only to align the org structure with the product strategy or to intentionally change the culture because of a problem you’ve identified.
Consider the following thoughts from our experts around some signals that it’s time:
“There's execution things like: we're moving too slowly, we're not able to keep up with the demands of our users and customers. That's one thing... Another thing that you often see is disconnects, decisions happening that are independently, potentially valid and correct for that local context but bad for the holistic product strategy.” Ely Lerner
“I inherited a 'C' team on PM and design. People were over titled and performance was subpar... I needed to completely revamp both the talent and culture... while building out a product and business strategy.” Yue Zhao
“Many companies go through this journey. In the beginning, it's a streamlined structure, but as growth occurs, complexities arise. Transitioning to a GM structure becomes inevitable when new product lines or industries are introduced, demanding accountability at a business level. It's a natural evolution in pursuit of efficiency and adaptability.” Sanchan Saxena
In Ravi Mehta’s Product Leadership course, he outlines three scenarios to determine if a re-org is necessary:
The product strategy has changed. If the product strategy has evolved, the org design needs to evolve to reflect the updated priorities.
The product strategy needs to be reassessed. A well-defined product strategy will last 1-2 years, but should generally be reassessed once a year. If this assessment suggests a change is necessary, the org design will also need to be updated.
There’s a gap between the product strategy and org design. Good org design imprints the strategic priorities right onto the org structure. A litmus test for org design considers whether the company would progress on its strategy if leadership disappeared for a year and every team did what it was defined to do. If the answer is yes, the org structure is optimal. If not, the org structure doesn’t reflect strategic priorities. Consider whether a lack of accountability, incentives, communication, or coordination is limiting the cross-functional org’s ability to deliver optimal impact. If the answer is yes, a re-org is necessary to eliminate these gaps.
Organizational design follows strategy. If your business is betting on shifting to Product-Led Growth, for example, you should consider re-orging and upskilling your team to better map to the execution of that strategy.
But beware: Product Leaders and other leaders often implement re-orgs for the wrong reasons. This widens the gap between the org design and the strategy, often leading to conflicting priorities across functions, unclear accountability for outcomes, challenging cross-functional communication, and slow, compromised decision-making that often drives lackluster product results. There are three common situations where product leaders might re-org for the wrong reason:
Re-orging as performance art. This often happens when a new, often very senior, Product Leader is hired and almost immediately changes the org structure. While this might indeed be due to an org design-strategy misalignment, it often has more to do with a desire to demonstrate action. Senior leadership may reward this behavior, especially if it coincides with a cost-cutting reduction in force. However, it signals that the company is unhealthy, which can negatively impact the morale and productivity of the remaining employees.
Re-orging to give a new product leader more responsibility. For example, a company that just made a big COO hire may re-org the product team into that executive's organization despite the executive having limited product experience. This can cause unclear accountability and collaboration, severely damaging the org's efficiency, effectiveness, and morale.
Re-orging to better manage product leader time. If it's possible to do this sort of re-org and keep the org design aligned with the product strategy, it can indeed be a good solution to give product leaders more leverage. But if the new org design widens the gap between org design and strategy, it will hinder the org’s ability to drive impact.
Another precursor for a successful re-org is getting cross-functional alignment on the path forward. Yue elaborates, “We had many conversations around this — some productive, some not. In the meantime, the team members were getting frustrated at our lack of alignment. We needed to decide. Ultimately, after many rounds of discussions on pros/cons, we surfaced it as a board of directors level conversation, and decided in favor of the pod structure. In some cases, effective and timely escalation is key to good leadership.”
Once you’ve aligned as a leadership team that a re-org is necessary, it’s time to think about what this new org should look like.
Types of Product Orgs
Designed by Ravi Mehta, the Product Organization Matrix helps product leaders see the tradeoffs and explicit decisions they need to make when considering the structure of the product org.
Based on where a team lands on the area of focus and level of accountability matrix, there are four possible product org structures:
Business Outcomes: Outcome Owner
Business Outcomes: Outcome Facilitator
Feature Development: Feature Development Owner
Feature Development: Feature Development Facilitator
It’s important to understand the difference between feature-based teams and outcome-based teams.
Feature-based teams are organized based on the product architecture. They’re held accountable for specific feature areas in the product. For example, a social product might have teams organized around friending, messaging, news feed, commenting, and groups. Feature-based teams are easy to define. The product is divided into parts, and ownership is allocated amongst teams. But they’re also difficult to master because they require product teams to map how the feature fits into the product strategy and which levers generate impact. If the team doesn’t understand the business, they might work on things that don’t drive the desired business outcomes.
Outcome-based teams are accountable for specific outcomes that drive value for the business. In an outcome-based structure, a social product might have teams for friend discovery, messaging engagement, feed engagement, and group membership. When product leaders understand the most important outcomes and clearly articulate them, outcome-based teams know precisely what they’re accountable for and can drive efficient progress against the product strategy. But this also means teams will lack strategic clarity if outcomes are too vague (e.g., “improve revenue”). This can incentivize teams to focus on short-term outcomes, often at the expense of clear UX or long-term strategic progress.
Now that you’ve learned about the different types of product org structures, let’s consider the tradeoffs between the four different product org design models:
The Outcome Owner model is optimized for quick, uncompromised decision-making. It works best for companies that understand their business levers and where product work directly maps to those levers. It can also work well for companies that have limited cross-functional staffing. In this model, PMs must balance the pursuit of outcomes with the integrity of the customer experience.
In the Outcome Facilitator model, teams are defined to work on meaningful areas of the business. Teams consist of dedicated counterparts in functions like engineering, design, user research, and data science. Each cross-functional peer is equally empowered to make decisions and held equally accountable for the results. For this model to work, cross-functional leads must be incentivized to prioritize outcomes, and an efficient process must be in place to resolve disagreements.
The Feature Owner model is easy to implement because it is straightforward to assign PM ownership based on a product's major features. This works well when PMs have significant agency and accountability, can map their feature area to outcomes that drive business impact, and feel comfortable speaking up when their feature area isn’t driving business value. It also works well when the right outcomes are not yet clear (as is the case for pre-PMF products), when outcomes change regularly, or when the PM’s judgment is frequently relied upon to determine the right business outcomes.
The Feature Facilitator model is easiest to implement but hardest to get right. It requires the PM and cross-functional leads to figure out and agree on how to use the feature to drive business impact. Feature Facilitator models can work well at companies like Apple, where qualitative goals, like achieving superb design, are baked into the culture.
While it is less common, consider whether it makes sense to mix models. In some cases, organizations might include both feature-based teams and outcome-based teams. This can make sense if these decisions are thoughtfully made and make sense for the product.
Once you develop an idea of which org structure you’d like to pursue, it’s time to start considering how you’ll communicate the changes.
Communicating the Changes
To effectively communicate a re-org, you need to develop a two-pronged messaging strategy. This should include a high-level narrative for the entire organization and detailed explanations for each employee affected by the re-org:
**High-level narrative for the entire org. **This narrative is aimed at everyone within the organization, providing a broad overview of the reasons for the re-org. It should communicate the strategic shift and explain why this re-org is beneficial for the organization. It is important to frame this narrative in positive terms to help alleviate any immediate concerns or anxieties.
Detailed explanation for each affected employee. This part of your messaging should address how each affected employee fits into the new org design. It should answer two questions: (1) Why is this re-org the right thing for the employee as an individual? and (2) How does the employee fit within the new org design?
Once you’ve crafted this messaging, you should then roll it out to employees who will be significantly impacted first, and then announce it more broadly.
Measuring if it Worked
This is an incredibly important and difficult part of any re-org. It will take a while for the dust to settle and for the impact (either good or bad) to show itself. Our experts provide a few ideas on how to know if it is working:
“Whatever mechanism you use, the equivalent of the internal NPS, really getting a pulse on how people on the team are feeling... should be the outcome of any positive transformation.” Ben Williams
“One thing that I think shouldn't be overlooked is... getting a pulse on how people on the team are feeling in terms of how directly they are able to create impact. That should be the outcome of any positive transformation.” Ely Lerner
“We documented heavily — the structure, the teams, the values, the processes, how we worked together. We implemented a product process retrospective where each quarter, we get together just to talk about the process — what’s working, what could be better, how we improve — and then assign leaders to drive the changes we wanted to see. We valued trying new ways of working, and would revisit after a quarter whether we keep or kill. The product org was an evolving product.” Yue Zhao
Their message is clear: one of the best ways to measure the success of a re-org is to get qualitative signals from the people impacted by the changes. But there are also some measurable signals that you can also keep an eye out for:
Shipping velocity: is the product team able to ship faster?
Progress towards product strategy: is the team making progress towards the outlined product strategy?
North star metrics: you changed your product strategy to impact a certain north star metric at your company. Are you making progress towards that?
Re-orgs are large, complex undertakings that involve a spiderweb of logistical decisions, emotions, and coordination. However, when your business reaches a point where a re-org is necessary, there are ways to approach it artfully, ensuring your organization embraces the change rather than resisting it.
One crucial aspect we haven't delved into here is modernizing the skills within your product org to support transformation. For instance, transitioning to a PLG strategy may reveal that your team lacks the skills or knowledge necessary for this shift, regardless of the org structure. This is where Reforge can be a game-changer.
As a product leader aiming to transform or reorganize your product org, consider Reforge for Teams. This tool helps upskill your team and bridge any skill gaps essential for navigating new product strategies. Embrace change with confidence, knowing your team is prepared to succeed with Reforge for Teams.
Evolving the organizational design (or, as it’s more commonly known, re-orging) usually greatly impacts the affected team. Organizational (”org”) design defines who reports to whom and who works on what. This means that re-orgs usually require the product org—and typically, its cross-functional peers—to change how they work, what they work on, and who they work with and report to. They can disrupt personal relationships, responsibilities, goals, and sometimes even job security. This can cause unsettling uncertainty and damage team morale.
Yet it is often necessary to re-org to align the org design with the product strategy. In this article, we’ll consult our experts to walk you through what a re-organization is, how to know when one is needed, how to design the new org, how to communicate the changes, and how to measure if it worked.
But, as with most complex issues in business, there’s no “silver bullet” way to go about this. Sanchan Sahai Saxena, former GM at Airbnb says, "There's never one answer for any of these things. You always have to have nuance. Organizational transitions require careful consideration of various factors, from culture to operational structure. There's no one-size-fits-all solution; each situation demands a nuanced approach tailored to the company's unique context and challenges."
Let's dive in to those nuances.
What is a Re-Org?
A re-org, sometimes called “org transformation,” is when a company restructures how a company's product teams are organized and operate. This can include transitioning from traditional functional leadership models to GM structures, establishing product operations roles, or redefining team responsibilities and processes.
For the purposes of this article, we will focus on the Product Organization, but re-organizing any part of the company has ripple effects. Ely Lerner explains, “[Org transformation]... it goes deeper than just the product org... changes are often more wide-reaching than just the product... reaching into how you structure engineering, how you structure sales, customer success, support, and so on.”
Re-orgs are pursued for a number of reasons such as improving efficiency, fostering better collaboration, modernizing the team, mapping resources to evolving strategy, and more. People and teams are arguably the most powerful strategic levers your business has, so it’s crucial to constantly evaluate if your organization design is serving your strategy.
There is nothing more important for a re-org than knowing if you need to consider one or not.
Ben Williams said, “Ultimately, a transformation implies going from one state to another state. And you have to have a solid reason for wanting to move from your current state to that envisaged state.”
In the next section we’ll explore some signals you can keep in mind when mulling over whether or not a re-org is needed.
How to Know When and If A Re-Org is Necessary
Re-orgs as a strategic lever should be used sparingly and only to align the org structure with the product strategy or to intentionally change the culture because of a problem you’ve identified.
Consider the following thoughts from our experts around some signals that it’s time:
“There's execution things like: we're moving too slowly, we're not able to keep up with the demands of our users and customers. That's one thing... Another thing that you often see is disconnects, decisions happening that are independently, potentially valid and correct for that local context but bad for the holistic product strategy.” Ely Lerner
“I inherited a 'C' team on PM and design. People were over titled and performance was subpar... I needed to completely revamp both the talent and culture... while building out a product and business strategy.” Yue Zhao
“Many companies go through this journey. In the beginning, it's a streamlined structure, but as growth occurs, complexities arise. Transitioning to a GM structure becomes inevitable when new product lines or industries are introduced, demanding accountability at a business level. It's a natural evolution in pursuit of efficiency and adaptability.” Sanchan Saxena
In Ravi Mehta’s Product Leadership course, he outlines three scenarios to determine if a re-org is necessary:
The product strategy has changed. If the product strategy has evolved, the org design needs to evolve to reflect the updated priorities.
The product strategy needs to be reassessed. A well-defined product strategy will last 1-2 years, but should generally be reassessed once a year. If this assessment suggests a change is necessary, the org design will also need to be updated.
There’s a gap between the product strategy and org design. Good org design imprints the strategic priorities right onto the org structure. A litmus test for org design considers whether the company would progress on its strategy if leadership disappeared for a year and every team did what it was defined to do. If the answer is yes, the org structure is optimal. If not, the org structure doesn’t reflect strategic priorities. Consider whether a lack of accountability, incentives, communication, or coordination is limiting the cross-functional org’s ability to deliver optimal impact. If the answer is yes, a re-org is necessary to eliminate these gaps.
Organizational design follows strategy. If your business is betting on shifting to Product-Led Growth, for example, you should consider re-orging and upskilling your team to better map to the execution of that strategy.
But beware: Product Leaders and other leaders often implement re-orgs for the wrong reasons. This widens the gap between the org design and the strategy, often leading to conflicting priorities across functions, unclear accountability for outcomes, challenging cross-functional communication, and slow, compromised decision-making that often drives lackluster product results. There are three common situations where product leaders might re-org for the wrong reason:
Re-orging as performance art. This often happens when a new, often very senior, Product Leader is hired and almost immediately changes the org structure. While this might indeed be due to an org design-strategy misalignment, it often has more to do with a desire to demonstrate action. Senior leadership may reward this behavior, especially if it coincides with a cost-cutting reduction in force. However, it signals that the company is unhealthy, which can negatively impact the morale and productivity of the remaining employees.
Re-orging to give a new product leader more responsibility. For example, a company that just made a big COO hire may re-org the product team into that executive's organization despite the executive having limited product experience. This can cause unclear accountability and collaboration, severely damaging the org's efficiency, effectiveness, and morale.
Re-orging to better manage product leader time. If it's possible to do this sort of re-org and keep the org design aligned with the product strategy, it can indeed be a good solution to give product leaders more leverage. But if the new org design widens the gap between org design and strategy, it will hinder the org’s ability to drive impact.
Another precursor for a successful re-org is getting cross-functional alignment on the path forward. Yue elaborates, “We had many conversations around this — some productive, some not. In the meantime, the team members were getting frustrated at our lack of alignment. We needed to decide. Ultimately, after many rounds of discussions on pros/cons, we surfaced it as a board of directors level conversation, and decided in favor of the pod structure. In some cases, effective and timely escalation is key to good leadership.”
Once you’ve aligned as a leadership team that a re-org is necessary, it’s time to think about what this new org should look like.
Types of Product Orgs
Designed by Ravi Mehta, the Product Organization Matrix helps product leaders see the tradeoffs and explicit decisions they need to make when considering the structure of the product org.
Based on where a team lands on the area of focus and level of accountability matrix, there are four possible product org structures:
Business Outcomes: Outcome Owner
Business Outcomes: Outcome Facilitator
Feature Development: Feature Development Owner
Feature Development: Feature Development Facilitator
It’s important to understand the difference between feature-based teams and outcome-based teams.
Feature-based teams are organized based on the product architecture. They’re held accountable for specific feature areas in the product. For example, a social product might have teams organized around friending, messaging, news feed, commenting, and groups. Feature-based teams are easy to define. The product is divided into parts, and ownership is allocated amongst teams. But they’re also difficult to master because they require product teams to map how the feature fits into the product strategy and which levers generate impact. If the team doesn’t understand the business, they might work on things that don’t drive the desired business outcomes.
Outcome-based teams are accountable for specific outcomes that drive value for the business. In an outcome-based structure, a social product might have teams for friend discovery, messaging engagement, feed engagement, and group membership. When product leaders understand the most important outcomes and clearly articulate them, outcome-based teams know precisely what they’re accountable for and can drive efficient progress against the product strategy. But this also means teams will lack strategic clarity if outcomes are too vague (e.g., “improve revenue”). This can incentivize teams to focus on short-term outcomes, often at the expense of clear UX or long-term strategic progress.
Now that you’ve learned about the different types of product org structures, let’s consider the tradeoffs between the four different product org design models:
The Outcome Owner model is optimized for quick, uncompromised decision-making. It works best for companies that understand their business levers and where product work directly maps to those levers. It can also work well for companies that have limited cross-functional staffing. In this model, PMs must balance the pursuit of outcomes with the integrity of the customer experience.
In the Outcome Facilitator model, teams are defined to work on meaningful areas of the business. Teams consist of dedicated counterparts in functions like engineering, design, user research, and data science. Each cross-functional peer is equally empowered to make decisions and held equally accountable for the results. For this model to work, cross-functional leads must be incentivized to prioritize outcomes, and an efficient process must be in place to resolve disagreements.
The Feature Owner model is easy to implement because it is straightforward to assign PM ownership based on a product's major features. This works well when PMs have significant agency and accountability, can map their feature area to outcomes that drive business impact, and feel comfortable speaking up when their feature area isn’t driving business value. It also works well when the right outcomes are not yet clear (as is the case for pre-PMF products), when outcomes change regularly, or when the PM’s judgment is frequently relied upon to determine the right business outcomes.
The Feature Facilitator model is easiest to implement but hardest to get right. It requires the PM and cross-functional leads to figure out and agree on how to use the feature to drive business impact. Feature Facilitator models can work well at companies like Apple, where qualitative goals, like achieving superb design, are baked into the culture.
While it is less common, consider whether it makes sense to mix models. In some cases, organizations might include both feature-based teams and outcome-based teams. This can make sense if these decisions are thoughtfully made and make sense for the product.
Once you develop an idea of which org structure you’d like to pursue, it’s time to start considering how you’ll communicate the changes.
Communicating the Changes
To effectively communicate a re-org, you need to develop a two-pronged messaging strategy. This should include a high-level narrative for the entire organization and detailed explanations for each employee affected by the re-org:
**High-level narrative for the entire org. **This narrative is aimed at everyone within the organization, providing a broad overview of the reasons for the re-org. It should communicate the strategic shift and explain why this re-org is beneficial for the organization. It is important to frame this narrative in positive terms to help alleviate any immediate concerns or anxieties.
Detailed explanation for each affected employee. This part of your messaging should address how each affected employee fits into the new org design. It should answer two questions: (1) Why is this re-org the right thing for the employee as an individual? and (2) How does the employee fit within the new org design?
Once you’ve crafted this messaging, you should then roll it out to employees who will be significantly impacted first, and then announce it more broadly.
Measuring if it Worked
This is an incredibly important and difficult part of any re-org. It will take a while for the dust to settle and for the impact (either good or bad) to show itself. Our experts provide a few ideas on how to know if it is working:
“Whatever mechanism you use, the equivalent of the internal NPS, really getting a pulse on how people on the team are feeling... should be the outcome of any positive transformation.” Ben Williams
“One thing that I think shouldn't be overlooked is... getting a pulse on how people on the team are feeling in terms of how directly they are able to create impact. That should be the outcome of any positive transformation.” Ely Lerner
“We documented heavily — the structure, the teams, the values, the processes, how we worked together. We implemented a product process retrospective where each quarter, we get together just to talk about the process — what’s working, what could be better, how we improve — and then assign leaders to drive the changes we wanted to see. We valued trying new ways of working, and would revisit after a quarter whether we keep or kill. The product org was an evolving product.” Yue Zhao
Their message is clear: one of the best ways to measure the success of a re-org is to get qualitative signals from the people impacted by the changes. But there are also some measurable signals that you can also keep an eye out for:
Shipping velocity: is the product team able to ship faster?
Progress towards product strategy: is the team making progress towards the outlined product strategy?
North star metrics: you changed your product strategy to impact a certain north star metric at your company. Are you making progress towards that?
Re-orgs are large, complex undertakings that involve a spiderweb of logistical decisions, emotions, and coordination. However, when your business reaches a point where a re-org is necessary, there are ways to approach it artfully, ensuring your organization embraces the change rather than resisting it.
One crucial aspect we haven't delved into here is modernizing the skills within your product org to support transformation. For instance, transitioning to a PLG strategy may reveal that your team lacks the skills or knowledge necessary for this shift, regardless of the org structure. This is where Reforge can be a game-changer.
As a product leader aiming to transform or reorganize your product org, consider Reforge for Teams. This tool helps upskill your team and bridge any skill gaps essential for navigating new product strategies. Embrace change with confidence, knowing your team is prepared to succeed with Reforge for Teams.