This is great advice for a single-team product.
I generally deal with organizations that have complex products in an expansive digital platform. I know that some in the Agile community will respond, “But that is the problem: you should create lots of small independent products”. Well, tell that to Amazon, or Google. Their products are not independent. In fact, Google has invested massively in automated on-demand cross-product integration testing. They realize that in their very complex digital platform, there are lots of interdependencies that cannot be designed away. And to do so would fragment the platform and create a terrible disorganized user experience.
So the question is what to do for complex products that involve many teams, and which have cross-product logical dependencies. In that situation, “great” teams typically work at a feature level, not at a business goal level; and they are empowered by an automated integration test setup that makes it possible to work at a feature level, since any change usually logically impacts other products. (DDD fans — like myself — sometimes say that indicates a poor DDD model, but that is not true. The services in well designed bounded contexts are usually logically interdependent, and adding any new feature usually affects multiple services.)
Working at a feature level means that your goal is the feature. Your goal is not a business goal, because the product owner has decided that a feature is worth trying in order to achieve a business goal: if customers don’t like it, the PO will pivot and remove it. The teams’ goal is to implement the feature, and implement the metrics that will inform the PO. The PO is not sitting with the team, brainstorming about business goals.
Now for a small startup, with a single product and a single team, the PO can spend all their time with the team. But if you have an expansive digital platform, the PO is a busy person with operational responsibility, and many teams, and will only be able to give you a slice of their time every day, or perhaps every other day. So it is not like you are all gathered around brainstorming about how to conquer the market. That is a startup’s experience, but not once you grow. It just doesn’t scale. I am not saying that it can never happen: it is just not the norm, even for “great teams”, when you are dealing with multiple complex deep-stack products.