At scale, you might want to look at a Hierarchical Backlogs. This way each team can have their own manageable backlog to groom/plan but there's an overall backlog that can be utilized for things like increment planning.
Kenneth S. Rubin (author of Essential Scrum: A Practical Guide to the Most Popular Agile Process) has a good chapter about Which and How Many Backlogs. In particular, check out the section called Large Products—Hierarchical Backlogs.
Whenever possible, I prefer one product backlog even for a large product like Microsoft Office. However, we need to be practical when applying this rule. On a large product development effort to create something like a cell phone, we can have many tens or hundreds of teams whose work must all come together to create a marketable device. Trying to put the PBIs from all of these teams into one manageable product backlog isn’t practical (or necessary).
To begin with, not all of these teams work in related areas. For example, we might have seven teams that work on the audiovisual player for the phone, and another eight teams that work on the web browser for the phone. Each of these areas delivers identifiable value to the customer, and the work in each area can be organized and prioritized at a detail level somewhat independent of the other areas.
Based on these characteristics, most organizations address the large-product problem by creating hierarchical backlogs (see Figure 6.14).
At the top of the hierarchy we still have the one product backlog that describes and prioritizes the large-scale features (perhaps epics) of the product. There would also be one chief product owner, as I will discuss in Chapter 9, at this level. Each of the related feature areas then has its own backlog. So the audiovisual player area has a backlog that contains the PBIs for the seven teams that work in that area. The PBIs at the feature-area level will likely be smaller in scale (feature or story size) than the corresponding items in the product backlog. In Chapter 12 I will discuss the release train concept that is based on a three-level enterprise backlog model: the portfolio backlog (containing epics), the program backlog (containing features), and the team backlogs (containing sprintable user stories).