… your product is a success in the market and more and more people are using it. New customer segments arise requiring new functionality that needs still to be delivered at market cadence. All teams strive to be able to deliver any PBI that comes along but the teams are about to infuse a new domain and they are starting to approach the boundaries of what a team can master.
✥ ✥ ✥
When the customer segments cannot be separated into separate products, then you often find that the necessary deep understanding of all those customer segments cannot be maintained within a single Scrum Team in a timely manner.
A Scrum Team should be able to add customer value on its own. Now that there are many customer segments, you might want to add more people who bring enough domain knowledge to the team so that all segments remain understood. Bigger teams are known to be slower because the team dynamics suffer. Also, the challenge of understanding multiple product parts in detail can result in demotivation.
Each product part creates value for a customer segment and requires the teams to have specific detailed knowledge about it. A typical decision might be to add multiple Product Owners with multiple Product Backlogs to reduce the complexity of having to understand too many customer segments. But then the Product Owners and their Scrum Teams will locally optimize for each for their own parts, instead of optimizing for the whole product.  It is crucial to optimize the design for economies of scope.
When you develop one product with multiple Product Owners working off their own Product Backlogs it becomes harder to coordinate changes that cut across multiple Product Owners and harder to keep working on the highest value PBIs. This is because 1: the Development Teams specialize and 2: the work at the product level does not distribute evenly across all the Development Teams’ specializations. Therefore, it is highly likely that the highest value PBIs will have some teams overloaded while other teams are left with spare capacity; as a result, not all the highest value PBIs can be picked up and the Product Owner is forced to select lower value PBIs to keep the teams with spare capacity busy.
Organizing Scrum Teams around architectural components might seem a good solution, but the problem is that a customer feature often requires an end-to-end slice across components, not a component in isolation. Component teams are also known to lead to sequential development, all kinds of delay, working on low-value PBIs, an opaque view on the progress of development and to unnecessary coordination roles.  The same kind of issues arise when you organize your teams around single functions like testing, architecture or analysis. See Cross-Functional Teams.
Every Sprint the Scrum Teams need to produce a Product Increment. Therefore, the Scrum Teams need to integrate their work and handle their dependencies. Managing dependencies across architectural components is hard with many teams. Often an otherwise unnecessary role like a project manager or external feature owner is introduced to manage, coordinate and plan multi-team dependencies.
Scale your product along Value Areas. A Value Area is a valuable product part that addresses the needs of a customer segment and cannot be separated out of the product. This way each set of Development Teams needs to understand only a subset of customer segments and each team is still capable of delivering valuable PBIs into the Product Increment.
A large product can end up with many of Value Areas; when this happens the Product Owner is not able to manage the Product Backlog on its own because of the vast amount of work and required detailed customer segment understanding. In this situation the Product Owner forms a Product Owner Team to manage the Product Backlog  across Value Areas; a Product Owner Team member typically specializes and assists the Product Owner in one Value Area. A Product Owner Team member does not own the product in any sense; the one owning the product is sometimes called the Chief Product Owner.
In a large energy company, there were the following Value Areas: I-Join, I-Pay, and We-Support. Each Value Area exists because they specifically address an area of customer value and requires specific detailed knowledge.
The I-Join area is about finding and adding new customers. The I-Pay area handled all the billing functionality and the We-Support area takes care of everything related to helpdesk and complaints.
Each Value Area has one or more Development Teams that work together in a single Sprint. A Development Team usually works within one Value Area. The Development Teams organize and coordinate their work themselves without any special coordination roles. All the Development Teams work from the same Product Backlog, have one and the same Product Owner and each team individually produce valuable PBIs that are integrated into a single Product Increment each Sprint.
✥ ✥ ✥
Organizing into Value Areas reduces functional dependencies between Development Teams because most of the functionality is separated by customer segment. The remaining dependencies are shifted towards the level of development. Development dependencies can be resolved by code management tools, continuous integration and other agile engineering practices (not tools that are intended to support or help coordinate humans interaction). The Development Teams also need to address cross-cutting concerns like architectural integrity or a common user experience of the product. Members from the Development Teams can form into communities to handle these concerns and create knowledge across all Value Areas.
Because the Development Teams start to specialize in a single Value Area they lose deep understanding about all Value Areas, but the Development Teams still work on valuable PBIs from the customers perspective while maintaining the focus on the whole product.
The Development Teams in a Value Area need to coordinate their work. You want the teams to notice when there is a need to coordinate and then coordinate with the right people in time. Therefore, decentralized and informal coordination mechanisms are preferred over centralized scheduled meetings.  A common coordination approach you can use to start with is the Scrum of Scrums.
When a new business opportunity arises that you expect to require significant capacity in the near future, add an existing high-performing Development Team to work on the business opportunity. The Development Team learns fast about the opportunity’s development risks and business potential. When the business opportunity turns out to be successful, the new team becomes a grounding team that helps the other teams get up to speed in this new domain.
Value Areas are an interim response to unanticipated spikes in demand for expertise. One can help avoid such surprises with regular use of Set-Based Design. In the long term, the teams should strive to again become Cross-Functional Teams across all areas.
 Mike Cohn. “Scaling Scrum.” In Succeeding With Agile. Reading, MA: Addison-Wesley, 2009, Chapter 17, p. 331.
 Craig Larman and Bas Vodde. “Requirements & PBIs.” In Practices for Scaling Lean & Agile Development. Reading, MA: Addison-Wesley, 2010, Chapter 7, p. 215.
 Craig Larman and Bas Vodde. “Requirement Areas.” In Scaling Lean & Agile Development. Reading, MA: Addison-Wesley, 2009, Chapter 9.
Picture from: Presentermedia.com.