I think product ownership is easiest to understand as a feedback loop. The role connects stakeholders and the development team, then keeps information moving in both directions.
Stakeholders/customers start with an outcome they want. The product owner turns that into a vision and an ordered backlog. The development team turns part of that backlog into working product (series of MVP). What the team delivers creates new information, which goes back to the stakeholders and changes the next decision.
Product ownership keeps outcomes, direction, development, and feedback connected through communication.
Communication is the key work
This loop depends on communication. A product owner cannot pass a request to the team and just disappear. They need to explain the outcome, hear what the team learns, pushbacks, and bring that learning/pushbacks back to the people setting direction.
The same communication helps manage expectations. Trend are useful here. They show what the team has delivered and where the current pace may lead. That is more honest than pretending scope, time, and output can all remain fixed.
Balance 3 kinds of work: build the right thing, build the thing right, and build it fast.
The product owner keeps attention on value. The development team keeps attention on quality. The working model should help both move at a useful pace. Each part carries a different risk, including business value, technical quality, and cost or schedule.
When scale, the loop basically stays the same. More squads add alignment between product owners and technical leads. If the loop breaks, adding more hierarchy will not repair it. Find where information stops moving and flatten them