The PMs at my employer don't have a magic business oracle to tell them what to build. Instead the business has some vague goals, and maybe areas it wants to emp

The PMs at my employer don't have a magic business oracle to tell them what to build. Instead the business has some vague goals, and maybe areas it wants to emphasize at the moment. A PM's job is to come up with ideas for products that will serve the goals in accordance with the priorities. They work with designers to mock up what the products might look like, analysts to forecast what the impact might be, legal and policy to understand the risk profile and constraints, user research to understand the customer needs and preferences, support and operations to map out the associated ground game. This culminates in a Product Requirements Document. They get very rough estimates from engineers, then sit down with the other PMs and business leaders and fight it out for engineering weeks. If the PRD is funded, they'll sit in sprint planning and demos, etc. to oversee the fulfillment of their vision. (The product's tech lead is responsible for architecture and implementation, the PM for its observable behavior and fielding). They'll participate in the design of test cases, rollout plans, experimentation, marketing materials, press demos, etc. They'll be on video calls at all hours of the night working with regional stakeholders around the world to clear the way to rollout in those markets. Then at the next six-month planning cycle, rinse and repeat. It is very much their own wishlist of features, although to get engineering weeks they theoretically need an evidence-based argument for why those features are the best use of time. Maybe we're talking about the difference between PM at a product company and PM in internal IT?