To my mind, a product manager is judged against a single metric: the success of his/her product. Saying that “a product manager’s raison d’etre is to define requirements…for a successful product” is another way to say that.

This could indeed mean discovering a problem and defining a solution, but it could also mean defining a better solution to a well-known problem, or even making a well-known solution easier to use, or finding a way to make an existing solution cheaper, etc.

Also, many products don’t solve problems per se. I’ve got a theory that the value of a product to an enterprise can be measured in dollars, but the value of a consumer product can sometimes be measured in another currency: happiness. Thus some valuable products don’t solve problems as much as they increase happiness (directly or by reducing the onerousness of a task).

That’s probably the topic of a post, though

I do like the idea of putting Engineering in change control; except for the fact that they tend to use the “dependency” loophole a lot.

That sentence reflected my present circumstances more than a philosophical point of view.

Perhaps a slight edit:
“A product manager’s raison d’etre is to define a product for design to design and specify and then engineering to build.”