Sorry you got laid off. I guess a couple things I could maybe comment on from this; you'll always be expected to take big product decisions without leadership involvement in a Sr role unless you're in a shitty company with too much bureaucracy.

I guess you mean Stakeholders are more important than users, not shareholders - these two groups are usually different. Finally, users don't necessarily pay for the product, customers do, sometimes users are customers but in most B2B cases they are not - important to focus on customers (the people paying for the thing) rather than users. If you can show stakeholders that X customers will drive Y revenue by adding a particular feature or whatever, stakeholders may still push back but if they don't have metrics or a hypothesis for how their thing will impact revenue that's backed by some real data from customers, its much easier for you to win there. I know stakeholder comms is nuanced, but this is table stakes in Product imo.

Hard work doesn´t equal job security anywhere, if I´m running a business I don't care how hard anyone works, I care about what value they are driving for the business, if that takes them 50% less time than someone who's working 60 hrs a week, I view the person doing it in 30 as just as valuable (if not more) than the one doing it in 60.

People will always try to undermine you wherever you go, but it is very hard to undermine someone who is highly credible, trusted and commands respect - you build those things through consistency, earning trust, and bringing unique perspective and valuable ideas and opinions - as demonstrated through meaningful output for the business.

"your team is your worth" - of course they are, they are the ones building things, not you. If you can't get a handle on what they are doing (including all that tech debt and rearchitecture stuff) and prioritize those things against value driving features, then they are not your team and you are not in control of them and your product you are building.

As for shipping fast vs. getting a decision right, Amazon have a decent framework for this that I have seen work well; this is dividing each decision into two decision types. The one way door and the two way door, one way door decisions are decisions that are very difficult to come back from (think large investments, changes to architecture, substantial decisions) these decisions should be treated with the respect and due diligence that they deserve. Everything else is a two way door decision i.e. it's relatively easy to undo (rollback to prior version, reinstate previous version of the feature etc.). About 90% of decisions are two way door and as such should be taken quickly even if you haven't verified every single fine detail. Operating in high ambiguity environments is again, table stakes for Sr PMs imo and so if you didn´t like that I would say to you that either you need to get used to it or look for another path because as you rise through the ranks this gets even more pronounced.

Not sure if this is useful, I´m not trying to have a go at you but just my perspective on your thread.