In 2012, Instagram was sold to Facebook for USD 1 Billion. The entire company had 13 people, only six of which were engineers. At Microsoft, a massively successful product I led from conception to scale to win the hearts and minds of the academic market, had 3 FTEs part-time allocated, and a group of student volunteers. A previous company I worked at, arguably one of New Zealand's best success stories that flies under the radar, a regional aviation company, hit multi million dollars of revenue and was acquired recently, had less than 20 full time staff. What this speaks to, is that throwing people at problems doesn't mean you have a better product or better product market fit. At your company, now or in the future, there will come a day where the company emphasizes "collaboration", "bringing people on the journey", and your manager tells you all about "stakeholder management", that results in the largest meeting room available being booked out and every PM, engineering manager, designer, and stragglers from sales, marketing, and maybe even legal will show up to spend the day debating the merits of your next year's roadmap, or worse, debate over minutiae language in your strategy, or specific implementation peculiarities. I'll say it now: You may win organizational brownie points and be praised for involving everyone, but your product isn't going to have any better odds at success in market. Now, we all have to work in the constraints of our organization, so more than not, you will need to grit your teeth and do these things, for the sake of your job and being invited to after work drinks, but again, don't conflate doing a good job as a PM in your organization to delivering great products to market that customers love. To drive home this point, your role as a PM is to deeply understand and advocate for your customer. Your customer does not care how many stakeholders you've engaged internally, how many legal staff were taken on the journey, how you've incorporated feedback from others in the organization. Your customer only cares about how you've added value to their lives and will pay you what they think it's worth - absolutely nothing else matters.
My approach to this problem is simple - I speak to, deeply understand, and advocate for the customer across all levels of the business. If there's big group debates, make it about the customer - let everyone bring their data and insights and interpretation of the results. If you don't understand your customer, you don't have a leg to stand on and your product will fail.
When you're building your teams, my advice is to focus on small, agile teams that have passionate, ambitious folks that operate incredibly well together, but are small and self-contained. You will of-course need legal, marketing etc - find the same traits, but have dedicated folks here that are available ad-hoc. It's critical that you have a core team that operates like a freight train. There's two reasons - first, as mentioned above, largeness will just slow you down, and second, it's more than likely you'll fail anyway, small teams reduce investment costs, sunk costs, and let you pivot fast if it does fail. It's more palatable to even get underway if a team of six fail to get product market fit, than a team of 60.
Now, some of you in deep enterprise tech may be thinking - this is all BS, our systems are complex! It takes six engineers just to change a text field! Sure, but again, your customer doesn't care what it takes you to do it, they care about the value you're giving them. Don't conflate them sticking around to you do not doing the work, it's more than likely in the enterprise space they have inertia ("this will do"), which is not a great strategy (unless ofcourse the business is in the milk it until they run phase, in which case you should be running too). Again, there's a reason why Facebook, with all its resources and might, ended up buying Instagram, and why so many acqusitions happen - it's because larger enterprises don't have the mindset and spend so much time appeasing themselves internally they forget the bigger picture. It's only natural with size. So think - if we were an outside team with the internal know-how, what would we do to be acquired by our own company?
The same can be said for process - everyone rolls their eye at processes and it's an easy target - but I will say this, processes are absolutely critical for larger organisations to ensure standardisation and a clear product development lifecycle. Larger companies will simply meltdown without it. I've also found most product managers have an uncanny ability to write a lot of paperwork. In saying all this, I will once again say - you can have the best processes in the world, write amazing PRDs, have the best Jira setups and even have Product Operations within your organisation, none of this will help you build a better product for your customer. These processes are there to help manage organisational risk, help PMs onboard better, and make sure everyone is singing off the same song sheet, but the song sheet could be wrong and that's where you come in. Your job is to make sure, from the very beginning, the actual song sheet, the customer problem, is the right one to solve. Fight all the battles, break processes if you need to. I'll leave you with this - how many great products really needed all those processes and a PRD packet to help it succeed?