Selling alone can get me a couple years worth of runway but I've been in two where overselling before ops/process where at a stable velocity everything choked so bad it forced the biz to pivot (not in a fun or good way).

What OP is calling a "product engineer" is a good perspective for people that don't quite get that we live in a cash ecosystem and love to write good code but a lot of people hired as product engineers haven't written any code in decades. Hiring for that title is as clear as mud. Even if I have one that'll make my day in my company I might still need a senior dev that understands this stuff but wouldn't bother calling himself a "product engineer" for fear of getting crushed by the wheel of chasing customer expectations without qualifying them.

At the end of the day no matter what decisions the "product" team makes, as the "software developer" I need to make things happen and that takes leading the narrative enough that I don't get hung out to dry. Engineering predictability and its communication is the key to all success. Something that has helped me wildly has been the Microsoft book Software Requirements (3rd Ed) [0]. The system it lays out for planning, analysis, and risk mitigation is something everyone should read if they want to be more effective. It doesn't even have to be applied dogmatically.

If I can respond with a common lexicon of a vision and scope with a well laid out requirements spec then there isn't an issue with product, c suite, and dev communicating and everyone making money. It still shocks me every time I'm in a new org how hard that is to pull off even with the instructions. If comms and velocity track then there's enough wind to fill the sales sails.

[0] https://www.amazon.com/dp/0735679665