Startup PM vs Enterprise PM: What are the expectations?
While I enjoy my role as a Product Manager, I have realised that the company you work in plays a huge factor in what your expectations tend to be. Ambiguity is high in smaller companies, whereas larger companies are more structured. Both have their pros and cons, and choosing one over the other is more of a personal preference.
If you’re looking for a new PM role and you want some clarity on what kind of company to join (in terms of size), then you’re in the right place. I’ve worked at companies where I joined as the first PM, and at large organisations that had fixed ways of working — and I was hoping I could dissect this and pass on the information for anyone who’d like to know the difference.
These are the factors I’ll consider:
- Onboarding time
- Outside-role expectations
- Projects vs. metrics
- People you work with (or people you need to convince)
- What you say vs. how you say it
- How close you are to users and data
- What documentation is actually for
- What you own (and what you get to work with)
There are more factors that come in to place, but these are the ones that I currently feel play a major role in the differences between the two based on my experience.
1. Onboarding time
Most startups don’t have a proper onboarding procedure. If there is some structure in place, your manager would have created an onboarding plan that is specific to you. You’ll probably have one week where you meet the team, understand business goals, get access to all the tools, learn the ways of working, and find out where the coffee machine is (or, if you’re working remotely, whether having your camera on for video calls is an expectation or not). After this, you’ll mostly get started with your first task. The smaller the startup, the bigger the task — this is something I’ve noticed generally.
You may also end up starting with very little context, so asking questions while you’re working on something is expected. You’ll have to do this a lot more regularly than you’d expect.
For enterprises, you’ll mostly have a much longer starting period — a month at least. If these companies have their own IT team, expect even longer. But the good thing is that you at least learn what the company is about, and you get accustomed to it slowly.
At one of the startups, I shipped my first feature in 3 weeks — it wasn’t just a feature but an entire product. At one of the relatively faster large organisations, I had only created my first user story in 3 weeks, which was a small improvement in an existing product. It took another 3 weeks to go live.
2. Outside-role expectations
At startups, at some point, you will end up taking up other roles as well. Startups are usually understaffed even if they have a lot of funding. I’ve had to do design and QA work at some of the startups I’ve worked at. Especially with AI today, this isn’t too much of a challenge — but if you lack these skills, it may make it tough to start. It’s best to get this expectation cleared up from the beginning. If you can’t design (which is completely okay), just let your manager know, and they’ll figure something out.
Testing the product is something that may be expected from you as well. One of the advantages of having a QA is that they will test every small thing. As a PM, if you spend your time testing every tiny detail, you won’t have time to do your other tasks. At one of the startups, we only hired our first QA a year after I joined.
As organisations get larger, there are dedicated people for each role. This is good because it lets you focus on the product expectations and your goals.
However, having to test your product and working closely with engineers helps you understand what you may have missed during discovery or when creating the PRD. Ideally you shouldn’t have to, but if we’re being practical, that isn’t always the case.
It really depends on the org, though.
3. Projects vs. Metrics
This is the difference I’d flag hardest, because it changes what your job actually is.
At larger orgs, I always reported to a Senior PM or someone higher in the product hierarchy. In these orgs, I was always given a project to do. They usually have something in mind, and you need to try to build that. This, of course, means you have to get on board with their ideas, and then try building it.
At startups, if you’re reporting to a founder, your goals are most likely related to metrics. In this case, you can focus on how to improve based on metrics, and the stuff you build is based on your ideas.
That sounds like the startup version is obviously better, and I don’t think it is. They’re both hard, just in different ways.
Building someone else’s vision takes a kind of discipline. You’ll often disagree with parts of it. You’ll see a simpler way to solve the same problem, and you’ll still have to build the version that was handed to you, because a decision was already made somewhere above you and reopening it costs more than it’s worth. Getting good at this means learning to make the right calls inside boundaries you didn’t draw — and being honest with yourself about when a disagreement is worth escalating versus when you’re just attached to your own idea.
Owning a metric is a different kind of hard. Nobody tells you what to build. If the number doesn’t move, that’s on you, and there’s no vision document to point at. You have to generate the ideas, pick which one to try, and then sit with the fact that most of what you try won’t work. That last part is what people underestimate. It’s not the freedom that’s difficult — it’s the failure rate that comes with it.
Which brings up something worth saying here: failure looks different in each place. At a startup, a feature that flops is usually treated as an insight. You learn from this, and move on to the next bet. But keep in mind, you will have to eventually build something that works.
Get Joshan Babu’s stories in your inbox
Join Medium for free to get updates from this writer.
At a larger org, a launch that misses the targets gets a whole meeting with an audience that can be hard to navigate through. On the other hand, if it’s a small miss, then there’s a chance that this could get buried under a lot of the other new developments happening throughout the company, so you can just quietly tuck this under the rug (umm… not saying I have, though).
4. People you work with
At startups, the person I needed to convince was usually just the founder. The marketing and sales teams would be on board quite early because they’re easy to reach out to, and all our goals are usually quite aligned.
At enterprises, you’re usually working closely with the product, design and/or engineering teams. This means when you are building a major product, you now need to talk to a bunch of new stakeholders. Sometimes, you may not even know who to talk to, and you need to email a bunch of people to figure out the right person. In most cases, these different departments have different goals. Somehow you’ll have to convince them that the feature you want to build will help them as well. This is where “Stakeholder Management” comes in as a PM skill. Company politics can be a bitch, and you may need to play some cards right to get what you want.
5. What you say vs. how you say it
This one overlaps with the point above, and I’m keeping it separate anyway, because they’re two different skills. The last one was about how many people have to say yes. This one is about what actually makes them say it.
When it comes to enterprise, having the knack to talk to people plays a big part, and you may need to bring out your inner salesperson. Using the right words and being careful not to digress from the topic is a helpful skill as well. Suggestions help, but everyone has ideas — you need to know when you’re collecting ideas versus when you need to convince a different party that the idea you’re working on was well-researched.
For startups, you’ll need to do the same. But based on personal experience, the content of what you say matters more. This may come from a place of bias, but I’ve realised that having just an Excel sheet and showing how a feature could help users and move business goals is more than enough. In enterprises, you may need a PPT. You may need to be flashy to get recognised. I personally hate PPTs, but that’s how companies work sometimes.
6. How close you are to users and data
At startups, you may not have a lot of data. So talking to users is a lot more expected. And this is exactly what the PM role is all about, right? Talk to users → understand their pain points → build a solution. Yes, I know there are a lot more steps in between, but talking to your users is what will always help you understand what the market is saying.
The lack of data can be challenging as well. You may end up talking to the wrong user. Sometimes the decisions you make are backed by very limited data and a few user snippets — and sometimes it’s just gut feeling. It’s very difficult to say whether this could backfire at an early stage, but taking risks at startups is usually encouraged.
At enterprises, you’re blessed with a lot of data. If the company has been running for quite some time, you’ll have access to a lot of user data. While I haven’t personally experienced this, I also know that larger companies have UX teams that talk to users regularly and share this data with product teams. As a PM, this saves time and puts valuable information at your fingertips to make decisions. But yeah, you miss out on the core thing about product management — building for users, which is best achieved by talking to users.
7. What documentation is actually for
This is what I think is interesting, honestly.
At the startup, documentation mattered so that the other person knew what they had to do. I wrote PRDs and user stories because those were handed to devs and they would build what was in the docs. And since everyone had context on everything, not every user story needed to be 100% clear. I could get development started even if design or content wasn’t ready, or if some edge cases hadn’t been cleared up yet.
At larger companies, you may need to be more detailed. You may not get to work as closely with the engineer as you’d like. The good thing about this is that you think about all the edge cases and requirements before it reaches the dev team.
You’ll also have to create documents for other teams like marketing, sales, or support, so they know what actions they may have to take or what to be prepared for with any major feature change.
Also, one more key observation that I really want to call out: At one of the large companies I had worked at, documentation mattered so that there was accountability. If there’s a document, there’s a trail. People from different departments or managerial levels can refer to them. It also shows that you’ve done work. I personally think you should be judged on the outcome of the project or goal you were working on — but sometimes, at larger orgs, the outcome is the output, which ends up being the docs you create. This is why you may hear PMs talk about the number of PRDs they have created. This is a useless metric because it doesn’t talk about the value you have created.
Startups also have PRDs and user stories, but you are always going to be judged for the value you create. Sometimes, you may not create a PRD and just Slack a developer to build something (before you attack me with pitchforks, I know this is bad practice), and that’s fine because what matters is if this actually helps the user.
8. What you own
At larger companies, you’re mostly working on one small thing, especially if you’re junior. You do grow with seniority — you get more involved in strategy and start looking at the product as a whole — but you may end up getting further away from users. Working on smaller parts means you may only get visibility into that part and whatever it touches.
I’ve seen PMs in large organisations be unaware of other initiatives being worked on in their own company. Working on smaller features also means you’re moving really small metrics. You may not even know how important that metric is, but your manager will always tell you it’s important.
At startups, if you’re junior, you’re either going to be working with a senior PM on a particular feature, or you may get your own product to work on — but it may have less importance to the overall business goals. Either way, you’re still aware of the other products in the company, and it’s easier to keep track of what’s happening across the organisation. Working on your own product gives you a lot more ownership and better ways to show your results. But that also means if you fail, it’s more visible.
A few caveats
This is my experience working in different organisations and hearing from other people I’ve worked with. It’s a handful of companies in specific industries, so someone who’s worked at a large company with a better product culture than the ones I’ve seen would probably push back on parts of this.
If I’m being really honest, there are certain criteria that will always beat the importance of company size:
- Team culture
- Your reporting manager (and sometimes even your manager’s manager)
They both point to the same thing — the people in the organisation.
A great culture will help you settle in quickly. It also helps to know if the culture suits you and your ways of working.
Personal advice: Stay away from companies that say “we are a family” bullshit. This is marketing speak and doesn’t mean anything. Once things get hard in the company, they’ll let you go because they are not obliged to take care of you. Which family would just throw you on the streets once things get tough?
Your reporting manager matters because they shape how you’ll get to work. If you’re someone who works independently, it’s good to have a manager who supports that. A manager who backs you will help you grow in the company. And sometimes, their manager also matters. If they have a shitty manager, then your manager may also have a shitty demeanour. That can suck, and so it’s worth considering.
So which one should you pick?
Based on my personal experience, I do tend towards startups. I like the ambiguity and the higher ownership. I also prefer working with founders, since this gives me direct access to what their vision is.
Enterprises are also great — generally you get a good work-life balance, there’s a structured growth plan, and they know what they’re building, so the constraints are more fixed.
But honestly, to each their own.
