Startup Founder => BigCo PM #

Many of the best founders I know have transitioned into PM roles at large tech companies. Ultimately they have become extremely successful, but the transition was often unnecessarily turbulent because they didn’t know how to recognize the warning signs soon enough. Below is a decoder ring for founders considering making this leap.

The key distinction to understand is that the PM role BigCo PM roles break down into “what to build” and “how to get it built in the context of the company”. Startup founders are usually quite good at the “what to build” part of the job. Starting their companies, they have obsessed over talking to users, identifying a MVP, interating to product market fit, designing a business model, obsessing over metrics, and strategically growing the business. This is the most valuable part of the PM skillset, and the hardest to train, so startup founders are often great candidates for PM roles.

However, the other part of the PM job is to know “how to get the product built in the context of the company”. Startup founders usually don’t have much experience operating in large companies, so this part of the job can have a steep learning curve. How to get a product built is highly company dependent. Each company has a different process for getting buy-in from stakeholders, building credibility, garnering resources, and getting code out the door. Great companies should help new people learn and navigate this process, but sadly many companies don’t. Below are some key phrases that might be a red flag something is amiss:

1/ Cross-cutting concerns are career limiting

As a founder, you have visibility and control over the entire product suite of your company. Therefore, if the most important thing to work on touches multiple products with multiple DRIs, it isn’t a problem, you can coordinate changes across these stakeholders to get it done.

Not so in a BigCo! Big companies structure their management to have vertical product teams working on independent initiatives that they can make progress toward, and be held accountable for, independently. Each team can have a roadmap they control and can be measured by the features they ship and the metrics they control.

When you work on a cross-cutting concern, you are trying to get many teams to work together with very high coordination effort. The actual features you are coordinating are built, shipped, and credited to other teams. This is extremely difficult for middle management to evaluate - who should get the credit, the team that built the feature, or the person who did the coordination?

This is not an irrational approach by big companies. Explicitly choosing to tradeoff speed of progress on autonomous teams, at the expense of consistency between products, is a rational choice for a CEO chasing venture scale returns. However, the problem is that this tradeoff is not explicitly communicated most of the time to the PM, and therefore doing the “right thing for the customer” can be career suicide.

Note: Sometimes there are people at large companies who get to manage a consistent product experience across all products, but they are usually extremely tenured employees who have the credibility and relationship with the CEO to have the trust to act in this function. However, a new PM needs to establish credibility by shipping a bunch of vertical products first before earning this trust.

1a/ Product vs feature

A special case of (1) is when management repeadly asks you, “Is this a product or a feature”? As a founder, it will seem strange that someone is agonizing over a seemingly meaningless question - after all, you are building the functionality that the user wants, so who cares whether you call it a feature or a product? BEWARE YOU ARE IN A DANGER ZONE. You need to fit into a mental model of a vertical product team that can be held independently accountable for metrics that you solely contribute to.

2/ Incidents are career limiting

Incidents are not supposed to be career limiting, it is supposed to be the mechanism for employees to be able to raise the visibility of crisis to everyone’s attention so that the company can circle around and fix the problem. Unfortunately, the reality is that if you are constantly pulling the fire drill, people start to associate your PM work with the part of the code that seems to always be causing emergencies and stress to the company. Even if all the problems pre-date your involvement, and you are saving the company from existential risk, the perception will eventually catch up to you.

3/ Your engineers must love you

Your product doesn’t get built unless an engineer writes the code. If engineers aren’t completely bought into your plan, they can completely kill progress by simply asking for never-ending clarification.

4/ Your engineers’ boss, adjacent peers, and other misc people must love you

It is not enough to get buy-in from your product team. You must also get buy-in from your engineering manager counterpart, their boss, and all the other adjacent peers who can veto progress toward shipping your vision.

5/ You are held accountable for a team you can’t fire

In a startup, you can replace an employee who doesn’t believe in the mission with someone who does. Not so at a BigCo - you inherit a team with a variety of career motivations, and you need to find a way to get them to go along with your product vision through soft influence. And if you don’t, nothing will ship.

6/ Buy-in has a half life

Remember that person you talked to two weeks ago, discussed their objection, and agreed on a path? Well, since then doubts have probably crept back in. Or they forgot to update others they changed their mind. Anyway, you need to constantly revisit buy-in, or get it signed in blood.

7/ Relationships are everything

Many PMs spend more than 20% of their time doing “coffee chats” to build relationships. To a startup founder, this seems extremely weird - why not use that time to build, we wonder? The reason is that when you need a favor, it is much easier if you have a relationship with the person, so constantly cultivating those relationships becomes a superpower.