You are lucky to have a high-speed delivery train already running. All you need is to help it going the right direction.
You could involve engineering in the product discovery work - show them how you identify the most relevant problems and ask their help in defining solutions and implement. You also might need data, analytics, a prototype, user research with demos, discussion on feasibility with engineers. Join forces with them on road mapping, making both technical debt items and new features visible.
After a release (prioritized by them or by you), do the verification of the outcome, show what you did and the customer results.
In general, this could help to show the value of the product work to your organization and build up good cooperation with engineering.
I wouldn’t try to slow them down or claim full prioritization mandate if you don’t have the capacity to keep the current delivery speed, if prioritization done by engineering does not create any harm for your customers or the service you provide. Don’t let your ego frustrate you, instead see what’s best for the customers. A prioritization done by someone else is possibly better than no prioritization and no delivery.
Your description shows possible signs of “we and them”, and functional silos in your organization. You could try to form a cross-functional team with product, design, and engineers, and see if you can deliver confirmed better outcomes that way.
In my opinion, you are measured in the wrong way. If the product is measured on the number of features, then your company risks turning into a feature factory.
You could try to educate your stakeholders, and get in an alternative, outcome-based metric. If you could run a full cycle with verification at the end with customer impact, then there is a chance they will slowly turn from output to outcome metrics.
In the meantime, you could use agile for your own prioritization as well. For every sprint, show your stakeholders what items you plan to work on and what needs to wait. Show if your work items are scoped down enough, and your time is used efficiently. Have demos and show the result of the work.
Sounds like a tough battle, also might be a concern for your professional development - not gaining experience with outcome-focused product management.
You’re in a dangerous place to be, based on my previous experience.
Engineering leading a product is a sure way to be a full-blown feature-factory, instead of an actual empowered product team.
Leadership tolerating such a fiasco is a big warning sign, too. I’ve been part of some companies where some “key” technical guys were intangibles even by the leadership / -C-level team because they feared they might leave.
This is a bad setup & a bad product organization.
Things to consider:
Make a solid business case & propose a new setup in which you are all working together as a product team.
Get the leadership buy-in to apply the new setup & processes.
If either of the above bullets fails, consider a new opportunity in some other place.
The reason why I want to highlight this: I’ve been there. I hoped it will get better. I went the extra mile.
It rarely gets any better & you’ll eventually be drained of energy and make a move.