If you take industry advice at face value, hiring a Product Manager seems to be the de facto solution to 99% of startup problems.
But is it really? The reality is that such advice is rarely paired with how damn hard it is to find a legit PM, and how difficult it is for PMs, once hired, to actually crack these problems.
So before we decide to hire a PM, we need to understand the role, the people who thrive in it and the dynamics that surround them - and that’s what the focus of this piece is.
A common answer in the popular narrative to “What does a Product Manager do?” is “The Product Manager is a mini-CEO.” I think this is a great jumping-off point for understanding the role.
While the claim is true to some extent, it’s worth exploring the manner in which the CEO role is analogous to a Product Management role… and how it isn’t.
In a well run startup, the Product Manager, just like the CEO, is free to define objectives within a framework of constraints. The PM is also accountable for their delivery, again just like the CEO. The CEO’s framework of constraints is defined by the board and the market; the PM’s framework of constraints is in turn defined by the CEO to be a subset of their own. The CEO defines this framework directly in smaller startups, or indirectly through the PM org in larger ones.
In early stage startups, the scope of the product is usually too small for the CEO to delegate product direction. It just isn’t possible for the CEO to come up with a meaningful framework of constraints that is a subset of their own framework of constraints that they can use to delegate product goal-setting to prospective PM hires. In fact, one could argue that the definition of ‘early stage startup’ is one where the CEO’s framework of constraints is irreducible, leaving the CEO unable to meaningfully delegate any aspect of product direction.
In this situation, it’s meaningless to hire Product Managers. If you do, you’ve either kneecapped them by preventing them from setting direction, or you’ve just hired someone else to build your startup for you - a recipe for disaster if there ever was one.
One good reason to hire a PM in the early stages is to coach the CEO in product management. It’s important to flag that in such cases, the title and role should be that of ‘CEO Coach’, not ‘Product Manager,’ and such roles are generally structured as part-time advisory roles. Another exception is when the CEO is themselves an experienced PM, and is hiring PMs to coach them with an eye on future scaling.
If the CEO of an early stage startup is struggling with scaling up execution, hiring Product Managers for the wrong reasons can be extremely harmful; it may be more useful to explore hiring Project Managers, or setting up an Office of the CEO under a Chief of Staff.
The performance of a CEO is a complex beast, assessed through some part business metrics, some part market perception, some part media narrative and some part stakeholder popularity contest.
The performance of a PM is usually assessed through a trad HR perf review process.
The CEO takes both upside and downside exposure to business performance as well as acts of the gods. The CEO can be rewarded and punished for things they had no control over. The CEO performance assessment ‘process,’ such as it is, is representative of the highly random nature of the role. To use Taleb’s terminology, the CEO role is a classic extremistan role, and typical CEO performance assessments reflect this.
The PM takes no upside or downside exposure outside of what is normal for a startup employee, i.e a ‘normal’ quantum of stock options. However, since the nature of a product is to fail, the PM statistically tends to have far more failures on their record than successes (just like CEOs). This does not bode well when one is assessed in a trad HR perf review process. While the PM’s roles and responsibilities are similar to a CEO’s, albeit scaled down, the performance assessment process that is common in the industry does not recognise this reality.
Trad HR perf reviews assume low external randomness and high correlation of impact to skill and effort. Impact is also expected to be delivered in a linear, predictable manner, as one would expect if it was correlated with effort. Sadly, none of these assumptions are true. As a consequence, the PM role is an extremistan role assessed like a mediocristan role, which is pretty unfortunate for a PM’s chances at career progression.
An example of this is PMs being tasked to improve metrics (like retention) in a naive manner. The PM is asked to come up with a target for metric X for 4 quarters down the line. The PM is then asked to break this down into quarterly or even monthly milestones with ‘acceptable’ steps - usually a linear progression. Product levers - when they work - usually affect such metrics in a compounding fashion rather than in a linear one, with most of the improvements accruing toward the end of the period. The PM, however, is being assessed on a monthly or quarterly basis, which means they’re going to have to live with some very bad feedback until the project delivers. And that’s assuming the project isn’t shut down before that point is reached because it ‘failed to deliver promised milestones.’
Before you hire a PM, ask yourself how you will review their performance. Like, formally. This can be much harder than one would think at first glance, so if you don’t have a good answer, I would suggest you pause your hiring until you do.
One of the biggest differences between a CEO and a PM is that everyone in the organisation reports directly or indirectly into the CEO. In contrast, nobody in the organisation reports to a PM, as it is essentially an individual contributor role. Even when the PM is in a non-IC role - often called Group Product Manager - it is with a focus on coaching other PMs rather than controlling them. Only when the PM moves into a functional leadership role - something like a Director of Product - does the PM have reporting control over others. Even then, it’s only over the PMs reporting into them, never any of the numerous other functions that have to come together to ship a product.
In a nutshell, the CEO has both accountability and formal authority. The PM has accountability without formal authority.
A more subtle, and arguably more powerful, dynamic is the aura of a CEO. Members of their organisation are far more inclined to strive to fulfil the CEO’s desires, to lionise their victories and be forgiving of their failures. The same effect also applies to other execs in the org, albeit in a significantly diluted manner. The PM has no such aura - in fact they often face more resistance than other employees at a similar level of seniority would. Every decision takes 10x more effort, every failure gets 10x more attention and every success is business as usual. The PM has to expend enormous effort to generate and sustain influence among stakeholders. Good PMs make friends with their counterparts in other functions, or at least try not to make enemies of them.
The CEO, on the other hand, can be abrasive and get away with it - maybe even thrive because of it. An abrasive PM is dead in the water from Day 1.
This aura effect even seeps out into the external world. Ask yourself to list the CEOs of your favourite products; I bet you could name most. Now list the Product Managers responsible for actually delivering those same products; I bet you will struggle to name even one.
Because of these differences, the way a CEO makes decisions is fundamentally different from how a PM makes decisions at a deep, intuitive level. This means when a PM goes to a CEO with a decision, it can lead to unexpected and destabilising outcomes for the PM. The two personas think differently because their performance is judged differently, which means they approach decision making in very different ways. One of the best descriptions of dealing with this from the PM’s point of view is captured in this thread from @Shreyas.
When hiring a PM, it’s easy for an exec level hiring manager to forget that the incoming PM will not have an aura to lean on. If the incoming PM was a CEO in their previous role - common when large companies acquire smaller ones - it can take them a long time to adapt to their new reality, and they will need support and guidance through the transition.
PM roles generally aren’t fungible, just like how CEO roles aren’t. No two product management roles are the same.
Strong PMs understand that their existence is part of the accidental complexity of product development. Weak PMs think that their existence is essential to product development.
An important corollary of this is: In a theoretically ideal product org, there will be no need for Product Managers.
In the real world, however, product orgs are far from ideal. There are all these different specialisations in a tech startup that are supposed to work together to delight customers… but don’t. They fail because of all these gaps between them, which means they don’t mesh well together. There’s nothing unnatural about these gaps. Any sufficiently large team, with sufficiently diverse skill sets, will develop these gaps. It’s the nature of human orgs that this happens as teams scale up. As the PM, you have to study and understand these gaps, this negative space between specialisations and teams - and then slide in and fill them so that everyone works smoothly together to get the product out of the door.
Product Management is, in a way, a negative-space role where the real, deep, skill is choosing objectives and helping others collaborate to achieve them. Here, the ability to align stakeholders is one to live and die by. Once again there are strong parallels to the CEO role, where execution is all about building cohesive teams and delegating well. The CEO, however, has formal authority which makes (internal) alignment far easier to solve for than it is for a PM.
The nature and shape of this negative space is different in different companies, indeed, even in the same company over time. While industry wisdom does distinguish between, for example, B2B and B2C PMs, the nuance in the popular narrative stops there. The appreciation of the fluid, heterogeneous nature of the role and what it means for successfully hiring and onboarding a PM is generally missing. There are strong craft connotations to this description, and as a consequence, strength in the craft is far more important to index on over domain specialisation.
When the startups I advise bring this up, I generally advocate working backward from the hypothetical product manager’s performance reviews. “What does this person need to deliver to get a raise?” and “What, if not delivered in six months, will result in you letting this person go?” are the questions I ask to help sharpen the job description and set up the right expectations.
The non fungibility of PM roles means identifying the skills you need in a PM for a specific open position can be challenging.
The only meaningful way I’ve been able to address this when hiring is by using a simple, yet powerful, thinking tool - the negative framing. I ask which skills aren’t necessary for the PM to have for a specific open position. You can use this quite effectively for a lot of other questions like brand positioning (who isn’t the target audience?) and segmentation (who shouldn’t be in the segment?). I’m not sure why, but this framing seems to affect our subconscious biases and produces entirely different results from a positive framing.
Start by listing the skills already available in the team the prospective PM hire will join, and then drop those from the job description. You will likely discover crucial gaps in the skills that either you or your team need as you go through this process.
An entirely legitimate - and underrated - outcome of this process is deciding to upgrade a particular skill area in yourself or your team instead of hiring a PM.
Once you’ve got a list of skills that are already present, you have a basic framework in place. Now you can start adding desired skills. It’s a given that a typical tech startup Product Manager should know how to work with the following types of folks - project managers, engineers, designers, data scientists, finance, marketing, sales and upper management.
It also really helps if the PM can roll up their sleeves and step in to backfill some subset of these when necessary - personally, I feel project management (including writing software requirements), statistical analysis and design skills are non-negotiable in a PM. A competent PM also knows how to own key business metrics, including the goal setting, communication and alignment that comes out of such ownership. A common side-effect of this kind of ownership experience - and a trait to select for - is that experienced PMs are always affable, and use this to get their way. An abrasive style is, on the other hand, a huge red flag and a sign of either inexperience or incompetence.
There’s a crucial distinction to be made here between the PM having skill x and knowing how to work with people using skill x, so keep that in mind as you develop the job description. The PM cannot meaningfully be expected to personally practice each specialist craft themselves, but they are expected to understand them as a system. For example, Product Managers don’t need to know how to code, but they do need to be able to appreciate the nature of tech-debt and how it affects (and is affected by) other aspects of delivery.
Product Management is a sort of meta-craft in this regard - a craft that factors in a thorough grasp of the dynamics of several specialist crafts and their interactions with one-another.
There was a great example of this conflation of having-skill vs. knowing-how-to-work-with-skill on Twitter recently:
If you look at the replies you’ll notice a simple pattern - the PM is always doing someone else’s job. Multiple responders literally said “the PM designs the product” and “PM talks to the customer to understand the problem” without catching onto the fact that “design” is quite literally the job of the designer, as is “talking to the customer to understand the problem”.
In constrained environments shaped by budgetary or hiring limitations, it’s entirely legitimate for a PM to personally execute across different specialisations. This is also a sensible approach to a new project or stream of work - start with generalists and specialise as the team scales up. It’s not uncommon to find PMs in these situations doing analysis, design, requirements and project management themselves, and sometimes even writing code.
However, it’s important to recognise this for the compromise that it is, because it’s impossible for one person to be good at everything. Speaking to the example above, expecting a PM to design the product better than a designer would is simply unrealistic. It’s also important to recognise that beyond a certain scale, setting goals, being accountable for them and keeping everyone in the team pulling together to achieve those goals is a full-time endeavour, leaving room for little else.
A final comment on skills: A consequence of all of these points is that there is no such thing as a junior Product Manager. You can’t operate effectively as a PM until you can do all of this. The popular APM title given to juniors in the field should be read as Aspiring Product Manager, not Associate Product Manager because that is the right way to think about PM progression. Most junior PM positions are in reality either project manager or analyst positions, so if you discover that to be the case, you may want to change your hiring goals appropriately.
As you may have concluded by now, the PM role is a rather thankless one.
As a PM, none of the people and teams that you bring together through your negative-space-filling-magic reports to you, so you can’t order them to do anything. You, the PM, definitely report to someone who is definitely ordering you to get shit done. Your performance reviews are thankless - if by some miracle things come together, you were just doing your job. If the numbers go up, it was the market, or marketing, or sales that made it happen. If the numbers don’t go up, it was your efforts that were lacking.
Consistently scoring a ‘High Performer’ or equivalent rating over several review cycles is well nigh impossible.
It takes a special kind of person to thrive in this kind of a role. The best PMs I’ve worked with are all masochists at some level - willing to deal with extreme levels of organisational ingratitude for the satisfaction of seeing a product make a difference to the customer. Many (though not all) were ex-entrepreneurs. PMs have to demonstrate extreme professional courage by routinely upsetting the powers that be in order to ensure the product succeeds. Many aspiring PMs I talk to say they want to become PMs because they lack the courage to startup. I find this stance hilarious because unless you spend your career entirely in peacetime - which would require tremendous amounts of luck - a core requirement of the role is routinely putting your next perf review or two on the line, indeed being willing to get fired. That’s a significant amount of courage we’re talking about.
Courage is at the heart of Product Management. When hiring PMs, look for a history of courageous decisions. Once you’ve hired them, try not to penalise them for making courageous decisions.
The PMs you see on social media who act as though they’ve got this sexy job with a lot of power and freedom are either over-the-top employer branding types, or children playing at product management.
So now that we know the kind of persona we’re looking for, let’s look at setting them up for success, haha. I love that phrase, so polished and business-y.
There are good reasons to hire PMs, and we’ve talked about a couple already - delegating goal setting and accountability as the CEO’s framework of constraints scales, and negative-space-filling to keep delivery on track as teams scale.
This section, however, is about bad reasons to hire PMs.
Most PMs are hired to solve problems, but are never equipped and empowered with the resources and tools to solve them. This leaves them kneecapped from the get go. To begin with, and re-iterating my point from the previous section - PMs become necessary because the product team isn’t pulling together to deliver. That’s a polite way of saying someone is failing to do their job. In other words, PMs get hired to address problems stemming from organisational pathologies, or worse, leadership pathologies… and usually the organisation and leadership is in denial of said pathology existing.
The most common kind of pathology stems from one or more skill functions in the product org being sub-par, with leadership being either unaware or in active denial. The worst part about this is there are some powerful biases at play that make it hard to see some of these things even when they’re right in front of us.
Where am I going with this? PMs need power to address organisational pathologies if they’re going to fix problems. The most important ability a PM needs in order to succeed is to be able to strongly influence hiring and firing across skill groups. These are the two most direct levers to address organisational pathologies stemming from under-skilled specialists.
Instead, what usually happens is the PM isn’t empowered to do shit-all about hiring/firing, and ends up having to personally backfill across one or more roles, most usually design and project management (if engineering is sub-par, it usually manifests through the hiring of an Engineer Manager). Now you have a product manager handling your design and running your projects but hey since it produces better results than having your sub-par designers design and sub-par project managers project manage, nobody thinks twice about it.
Any legit PM is going to suss out this situation fairly quickly. You’ll see them take steps to try to influence hiring to fix things, and they will often come to you for help. If they fail, they’ll bail on you because their lives are already tough enough and they don’t need the incompetence of others added to their plate.
There’s a dark corollary to this that you should be wary of. Sub-par PMs routinely use this exact dynamic to extend their runway by shifting the blame to engineering, design or just about anyone else to justify their continued existence on payroll. If you can’t assess the performance of the various skill functions effectively, you are vulnerable to such games. C’est la vie. You’ve been warned.
The most common failure mode of PM hiring is hiring a solipsist. Such PMs don’t know anything about how execution plays out on the shop floor and how various groups have to be coordinated to deliver value to the customer. They have low agency, low accountability, low influence and everything that goes wrong is someone else’s fault. Given that legit PMs can also end up with things going wrong for no fault of theirs, how do we tell the difference between the legit PMs and the solipsistic ones?
The answer, I believe, is to hire for agency and then assess on execution.
All good PMs demonstrate very high agency, a trait they share with CEOs. The interview process should be designed to tease out instances where the candidate set direction keeping in mind the practical realities of day-to-day delivery. Shop floor war-stories are hard to forge through interview prep, and all legit PMs can regale you for hours with theirs.
When hiring line PMs, you should also watch out for candidates who favour adding layers of managerial indirection that take them away from on-the-shop-floor execution. A classic example of this is the PM who cannot work directly with the engineers on their team without an Engineering Manager to mediate, or who like to throw PRDs over a wall at the rest of the team and wash their hands off of all downstream execution.
It’s worth calling out that even competent PMs in an organisation with deep rooted pathologies may have no option but to create layers of indirection to shield themselves from adverse performance reviews. If your engineers suck and the PM has no levers to fix this, then they have no option but to shield themselves by passing the buck to an EM. To reiterate a point from the previous section, if you can’t judge the quality of your engineers (or any other skill function for that matter), you can’t tell whether your PMs have a real problem or are simply passing the buck.
Once hired, the only way I know of to detect solipsism is to include execution metrics in every line PM’s objectives. There are many such metrics, but here are three that I think apply to almost any type of startup team:
There are other reasons why execution metrics should be an intrinsic part of any startup’s goal setting process, but that deserves it’s own full-length essay to do justice.
I’ve left the tough one for last. The most egregious failure to set-up-for-success is also the most painful to address. Sometimes, as an exec, when you’re advised to hire a Product Manager, the real problem that the PM is being hired to solve is… you.
I’ve been that exec, and likely will be again. You could be also.
If you’re smart and perceptive, you’ve figured this out and will apply the reverse-spiderman rule to carve out a piece of your power in proportion to the piece of your responsibilities to hand-off to the incoming PM. Once the PM is hired, you invest time in being coached by them on the skills that you lacked - a common example of this that came up on the Twitter thread above was learning product prioritisation.
So think this one through, because if you are the source of the problems you are hiring a PM to solve and you are oblivious to this, then it’s going to be… interesting. If you are a founder, then doubly so.
Hiring a CPO is a great example of this class of problem, and one that has come up several times both at places I’ve worked and among the startups I advise. The business has scaled successfully and the CEO is now too busy to get into the weeds on product every day. Co-founders and Advisors convince the CEO to solve the problem by hiring a CPO, and of course only the best will do. Since the best CPOs are visionary CPOs, a visionary CPO is hired… and then the CEO grants them all of their product execution responsibilities, but continues to decide what the product is.
Carve the vision out of the CPO role and you more-or-less get a Chief of Staff, which is a very different kind of person, role and problem statement. As you can probably imagine, this doesn’t end well.
Hiring someone to report to you that has to fix problems caused by you is a delicate business at the best of times. Ego is the biggest challenge to overcome here, followed by the willingness to let go.
In conclusion, here is a helpful summary of key points in checklist-tree form for easy use.
I’m grateful to everyone listed for taking the time to give me detailed, thoughtful feedback.