Managing Large Organization Product Development

These are some of the challenges I’m encountering as a very inexperienced PM in a large company:

  • Painfully slow build-launch
  • Number of teams are involved in a chaotic manner, and the majority of the time, few individuals are aware of the proper procedures or points-of-contact to be contacted.
  • There is also a complete disconnect and a lack of “passion” for the company’s (or, at this point, even the product’s) success.
  • Many humiliating errors in development and QA that keep the release schedule moving.
  • Useless and more harmful SAFe

It really gives me the impression that the organization is somewhat impeding my development and growth due to ineffective bureaucracy and a lack of necessary skill resources. It scares me how long I’ve seen PMs without releases on this site.

Any general pointers on how to proceed here? In addition, if you ever left a large organization, what lessons did you learn from the experience?


Establish a business case to modify it if they are an issue. Ask the head of engineering what it would take to reach that higher level after demonstrating to them how you might earn $X more by delivering features Y% faster or with Z% fewer delays.

Before criticizing the current build-launch processes, try to understand any apparent inefficiencies. Large businesses often have a diverse range of skill sets, and every given worker has a very restricted scope or understanding, which is a recipe for trouble. Processes are built in large organizations to prevent errors — this is typically the case. Additionally, mistakes at large corporations have more serious repercussions. In addition to other factors, a large corporation. A large corporation has significant coffers, making you a target for lawsuits and giving you access to a customer base with more financial resources, among other factors that contribute to harsher penalties.

Competitive creativity and innovation are extremely rare in large corporations due to risk aversion and onerous processes. In order to effectively deliver and continue to develop, you should be realistic when choosing to build, buy, or collaborate for a product, version, or feature.

Since connecting teams is nobody else’s responsibility and is essential to the success of the product, it may or may not fall under the purview of a product manager. However, I can assure you that doing it won’t get you promoted and that it can take up a significant amount of your time. When there are inefficiencies and communication gaps between departments, you can either bring it up with the department management and ask them to fix it (through a process, training, or whatever), or you can come up with a systemic solution yourself in a way that won’t require constant time investment.

However, creating and maintaining an org chart of pertinent organizations and individuals is one of the first things I do at a large company. If teams are approaching you for this information, you might as well just disclose the orgchart.

Being a change-maker at a big organization is a hugely valuable skill. Convincing a department of 5 people to change a process because of a clear benefit is one thing… Convincing five departments each with 50+ people to adopt a whole new cross-department system despite major disruption and retraining is a totally different level of impact. You have to figure out so many more things to get them all to align, and take different approaches to convince all of these teams that don’t report to you.

Navigating a big organization is a skill, and understanding how big companies work may be valuable sometime down the line. (For example, you can predict Microsoft’s product strategy/cooperation based on their business unit alignment/structure and the massive internal politics associated with it.)


On the other end of the spectrum of a big company, startups exist to take on the risk of finding a market fit for a new technology/process/service/whatever.

As a result, I have concluded that big companies (with a few exceptions) generally should not build new technology and should instead acquire technology/startups and make the technology available to a wider market than the startup could.


Really good points and very much agree. I think the main reason I’m not doing these are because of another issue I had mentioned about being disinterested at work due to so many delay/issues.


Some people prefer working for small businesses or organizations to big ones. Knowing that about oneself is beneficial. However, all businesses contain the same amount of crap; it’s just dispersed among various departments, as my mentor once told me. Don’t draw the conclusion that all large organizations are evil because of this one; perhaps you were just the victim of some poor BS.


I’ve spent the majority of my five years of PM experience at startups with under 100 employees and fewer teams, but I’m currently employed at a considerably larger organisation with ten PMs and the same number of autonomous teams.

My advice would be to try your best to assist your team in finding the appropriate points of contact, develop procedures that, at the very least, work for everyone in your immediate vicinity (including how to spot and eliminate errors and bugs earlier), and ultimately foster a sense of connection and passion among your team members.

The size of the organisation will probably limit you indefinitely, but any tiny victories you have along the road will be invaluable as you attempt to advance in your PM career.


Yep. I read somewhere our job (if we’re not too specific about product focus) is basically to create processes, remove bottlenecks and align teams towards our vision.


That’s much more easily achieved if you do it without process. Too much process kills a team’s spirit.


I went from doing product at big 4 to a 200 person startup - everything you said was there plus much more

  • HiPPO backlogs and roadmaps, especially from people who didn’t know product
  • teams who had a complete lack of passion for the product
  • more emphasis on PowerPoint decks than actual builds

My advice - if you care about building great products and having the autonomy and team to do so - get out. It’s been by and far the best decision I ever made. You’ll do and learn more in the first 4 months than you ever would at a big company.


I work for a huge organisation that primarily produces products on the side. We have enormous legacy systems that we’re still adding to, the funding process is a disaster and doesn’t allow for quick modifications, and there are inefficiencies everywhere.

If you’re new to the organisation, try to stay no more than a year or two at most. Consider what other businesses are seeking in a PM, and then concentrate on developing those talents locally. For instance, having good communication abilities and people skills are essential for a project manager. Look for chances to present to different kinds of teams. Being user-centric is crucial; look for methods to interact with people, spot issues or opportunities, etc.

However, it wouldn’t harm to submit applications to other positions concurrently. especially if you don’t now see a method to enhance your PM abilities in any area. I seriously doubt that, though. I work at a completely dysfunctional organisation, as I already mentioned, but I’ve nevertheless managed to pick up some skills that will make my résumé shine. I’m currently seeking employment elsewhere since I believe my progress has reached a point where it should stop growing.


I also served as a project manager for a Fortune 100 organization, and much of my experience supports what you’re stating (perhaps with the exception of the work I was doing was theoretically interesting, cool project at least).

The biggest suggestion would be to reiterate what several other commenters have said: politics is everything in large organizations. Concentrate on developing relationships, communicate frequently, and gradually gain the respect of others by becoming a trusted resource (i.e., when nobody knows who to talk to or where to go for something, they come to you). You may gradually nudge individuals in the direction of your goals and vision, but first you need to negotiate the political landscape and build trusting relationships.

Long launch periods, etc., are normal for large organizations; don’t worry about them. Create a timeline that makes sense to you, with room for delays that will inevitably occur because big businesses are just slow. Share the timeline, regularly check your progress against the timeline, and keep all parties informed as you go.

Of course, you can always look outside the organization for opportunities and pursue them if this isn’t the experience you’re looking for (understandable if it isn’t but realize that the idealized version of what PM should be isn’t all that common, even in small/scrappy start-ups where there are different but equally annoying issues).


Through stakeholder management, you must learn how to navigate and manage those circumstances. Create connections, launch projects, etc. People tend to gather around a PM’s work in large organizations; if you can’t lead, they won’t follow you with their work. It takes time, but the majority of employers searching for corporate PMs are interested in learning how you manage up.


Really hits home, I recently made the transition from a small startup to a large public firm.

I was able to see why everything is clogged up, slow, and full of meetings thanks to two things:

  1. At a startup, the danger is in doing nothing. You are unknown, your product is terrible, etc. Iterate, ship promptly, and remain close to the consumer. The biggest danger is doing anything that undoes the success of a large organization. Don’t rock the boat; be conservative and secure a lot of political support (or “buy-in”).

  2. Employees in startups want the business to thrive since it is crucial to their own success. Employees at large corporations desire promotions because they are more closely related to their own achievement. Promotions for large corporations require both a large following and having your name attached to a significant undertaking. It is preferable to spend weeks in meetings making sure executives are aware of your existence and to deliver white elephant initiatives that are highly visible than to make minor changes to the main product.

1 Like

Been there

Sharing what I’ve learned.

I learned to consider my stakeholders as “customers” and made an effort to comprehend their needs.

When a product succeeds, there are often many factors at play, such as who receives awareness, who should be contacted first, etc. I could navigate much more quickly after this chart was clear. I constantly posed the question, “How can I help you succeed?” and occasionally I had quite frank responses.

I was able to distinguish between the success of the product and that of the stakeholders after I understood the overheads and discovered ways to manage them.

Even while most individuals desire the same thing, a successful product, they all have different perspectives on how to get there. All I had to do was learn their language.

This topic was automatically closed 180 days after the last reply. New replies are no longer allowed.