I like to think of it like this: one layer prioritizes which products, another layer prioritizes which users, another layer prioritizes which features, another

I like to think of it like this: one layer prioritizes which products, another layer prioritizes which users, another layer prioritizes which features, another layer chooses architecture that supports all features, another runs sprints. Consider allocating resources to an email client vs. a web browser, then figuring out how much to focus on enterprise vs. small business vs. consumer, then figuring out user stories. All require different analyses - a PM who should be asking specific customers for feedback would be ineffective if they also needed to agonize about the financial consequences (market size, biz dev team readiness to sell into that market, CoCA) of choosing those customers. And even the latter decisionmaker may be better able to focus by having a departmental budget, and letting the C Suite decide if browser dominance is something that maximizes shareholder value. As a developer these things should seem self-obvious because ideally they were anticipated a year prior, headcount was allocated, and you were recruited at the right time. It’s rarely perfect, of course. But it doesn’t have to be - people don’t need to row in sync down to the millisecond, but without a coxswain there’s no hope.