One product backlog and one Product Owner is not realistic

The idea of one Product Owner and one Product Backlog is realistic if done right.

The first thing to consider is the structure of the teams. Organizing teams by logical component is one option. It does have some benefits - there's a lot of depth of knowledge in how specific aspects of the system work and the team can take full ownership of that functionality. However, there are also drawbacks with dependencies and over-specialization. An alternate way to structure the team would be around features or workflows. These teams work across logical boundaries in the product to deliver value.

Something else to consider is the structure of your products. Using the example of a ride-hailing app, you could easily have at least two products: the rider app and the driver app. You may also choose to have some core functionality wrapped up as separate products - payments (collecting money from riders, distributing money to drivers) and other special algorithms that may be treated as products. In this form, each product may have separate Product Owners and product backlogs.

Even before considering the team structure, considering the product structure would go a long way. If you have multiple distinct groups of stakeholders, there may be multiple products involved and you'd want to treat them as such. There are techniques out there for managing programs and portfolios that are designed to help coordinate across teams. Once you get each Product Owner focusing on one product and its stakeholders, a single Product Owner should work with many teams. Consider frameworks such as LeSS and Nexus that have a single Product Owner for up to 9 teams working on one product.

One more thing to consider is that a Product Owner may "represent the desires of a committee in the Product Backlog". The idea of a Product Owner is to have a single, unified voice that is accountable for Product Backlog management. I've found it helpful to align analysts, user experience researchers and designers, and other product management functions behind a single Product Owner. This can let the Product Owner make the decisions but work with fewer people.

To clarify a bit the team structures I mentioned above are for a single app (Customer app). Having one product owner for the whole app is impossible believe me.

I think my real question would be: what is the boundaries of a product?

Just because everything is in a single app and tightly integrated together doesn't mean that they should be treated as a single product.

If I understand Nexus correctly, it is concerned with managing multiple teams working on the same product. What is a good alternative to manage a group of tightly integrated products?

It's almost impossible for a single PO to handle 2 teams at the same time

Why is the PO trying to "handle" teams at all? Teams ought to be self-managing. The PO ought to focus on managing the Product Backlog, and on maximizing the value of the product, irrespective of how many teams are working on it.

The Nexus framework provides guidance on a PO's accountabilities within a Nexus Integration Team, where around 3 to 9 teams work on the same product. A mere two teams shouldn't need such a framework if they can self-organize competently.

For very large and complex products, it is common to find multiple Product Owners. And if they are operating under a certain popular scaled framework, then they all report to a Product Manager. At the end of the day, you want to spend less time on business process and team structure, and more time on the product and your client strategy.

Nexus framework for scaling Scrum:



https://www.scrum.org/resources/scaling-scrum



3 to 9 teams on 1 Product Backlog with 1 Product Owner

If the 6+ parts of the product are indeed for one product, then perhaps part of the issue is how the Product Owner thinks about it. It may be useful for the Development Team to segment the application into these components, but the Product Owner should probably be thinking in terms of user workflows.

For example, users don't think in terms of registration, profile management, maps, pre-ride, in-ride, post-ride, and payment. Users think in terms of things that they want to do. For a ride-sharing app, one example is "book a ride". I would call this a "feature" or "theme". Inside of this, there are "functions" or "epics" that may be classified as required or optional, such as "register", "set pick-up location", "set destination", "confirm", "review", and "pay". Below these are "actions" or "stories" that identify different ways to carry out these functions. When you think about this, there are sets of actions that represent a single possible workflow through this function, but there may be several ways to "book a ride" that involve different combinations of actions for each function. For more about this, check out the concept of story mapping.

In my experiences, this approach also helps make sure that your products are aligned. At the theme level, you can look at the stakeholders who have an interest in that theme. If two themes have a very different set of stakeholders, perhaps they shouldn't be contained in the same product since how these stakeholders think, act, and use the product may be different.

As far as managing across products, there are different techniques that help. Cooridinated release plans with coordinated iterations underneath the release plans, product owner per product with coordination among the product owners, common cadences with teams visiting each other's events (primarily reviews). The choice of techniques depends on the situation. Having someone with a background in both program management and agile methods would be helpful to coach the different products on coordination.

To clarify a bit the team structures I mentioned above are for a single app (Customer app). Having one product owner for the whole app is impossible believe me.

I don't agree but it all depends on how you define the word product.  I have worked on many products that are similar in nature.  In fact I worked on one Web based product that had 3 distinct audiences (internal, external paying customers, external paid consultants).  We had 1 Product Owner for each of those areas.  Each was stand alone and were valuable on their own merits.  They shared a lot of functionality across them but were viewed as independently valuable. We had one Product Owner for each of the three areas with multiple teams working from the same Product Backlog.  Each of the Product Owners had people that helped them with the opportunity assessments and market research but they were not part of the Scrum Teams as their work was only used by the Product Owner. 

"Product" can be defined in a lot of ways. The Scrum Guide does not provide a definition for the word product. After reading the guide multiple times, I have decided that product is meant to represent anything that independently provides value to the stakeholder.  To further add to the mystery, stakeholder is not defined either and it also can be representative of many things.  Again, my interpretation is that a stakeholder is any entity that has a vested interest in the functionality provided by the product. 

So in your ride sharing example each of your numbered bullets would be a product in my eyes.  Each one provides independent value to one or more stakeholders.  Each one can be built and released on it's own.  Each one can benefit from individual attention by someone who is responsible for making decisions on the direction of that product. 

However, your company will refer to their Product as the overall infrastructure that contains all of that functionality as the general public would not view each piece as a product.  (In my opinion that is actually better referenced as an application.) But the company's Product could be valuable and functional without one or more of the products under construction.  In fact, a ride sharing business could be profitable without a technological solution.  Taxi companies did it for years.