One product one backlog one owner!

Our org loves to split parts of the codebase between teams and then give them a PO and backlog. 

Are they value streams worth maximizing through a backlog of work which the supposed PO can clearly account for?

Try following the money. Right now, who is accountable for the investments being made, including budget and spend and whether those investments are justified?

A product should have one Product Owner and one Product Backlog. However, how you define product is up to you (or, more accurately, the organization). I can definitely see how a large codebase could contain multiple distinct products, for better or worse. Your view of products and your view of technical architecture may influence each other, but there's no single truth for how to view products and architectures.

This statement is in the 2020 version of the Scrum Guide section that describes the Product Backlog.

A product is a vehicle to deliver value. It has a clear boundary, known stakeholders, well-defined users or customers. A product could be a service, a physical product, or something more abstract.

Products do not have to be customer facing. A product could be internally used.  My go-to definition for a Product is anything that something or someone can derive value from using.  For example, a backend system that provides an ability to send email could be considered a product if many other systems utilize it for standardization of email handling. However, that is only my opinion.  I have worked in companies that chose to use that definition and others that did not.  In the end it is up to the organization to decide how to define their products. 

A product should have one Product Owner and one Product Backlog.

I agree with @Thomas' statement.  But I will add that one Product Owner could be responsible for multiple products if they are related and the individual is capable of dedicating enough time to each one. 



 

One of my favorite topics to talk :) Sadly, there is no single answer to that. To great previous comments, I can add that I like to think about product definition in a way that it can, or even should, have at least two views:

• Customer / users point of view
• Producer point of view

IMHO omitting this mind exercise may result in lots of problems down the line. Most of us could challenge ourselves with trying to define for example a "car" as a product from those two views - which from a customer's point of view is quite easy to do. But try it with these different lenses, and you quickly find how many possible sub-products there may be.



The following money is great advice from Ian, I would add to that something that bothers me since I read Team Topologies - do your product / sub-products definitions increase or decrease the cognitive overload of teams? Do those definitions helps with teams' autonomy within defined boundaries? etc.



Recently Joe Justice shared an interesting insight into SpaceX Starship production. Personally, I tried to tackle with this topic a little in this medium post, maybe you will find there something helpful :)