Hiring product managers is hard, especially if it’s a job you’ve haven’t done yourself.

Roles and titles can differ by company which makes evaluating experience tricky. Being a great startup PM requires a blend of domain expertise, product expertise, and startup expertise. It’s not easy to find someone with all those traits, so we wanted to write a guide to help founders hire fantastic product managers for their business.

"A players attract A players. B players attract C players." <text-author>- Steve Jobs<text-author>

"Hire for strengths, not lack of weaknesses." <text-author>- Ben Horowitz<text-author>

Defining product Management:

There are a bunch of different ways to define product management. We don’t need to agree on one single definition, but here’s how I see it:

"The product manager is responsible for the quality of decisions that the team makes about what to build, how to build it and how to make it successful."

A PM can make every decision for the team, but that’s generally bad product management. They should instead make sure the team understands the business context (e.g. cost base, wider strategy, market conditions) and their users, so they can make decisions together.

These decisions are about what problems to solve, how to solve them, how to test the solution and how you tell customers about it. Some of these tasks will be taken on by other specialisations over time (e.g. product marketing), but generally speaking the PM in a startup is responsible for making sure this system works.

It’s critical to get startup product management right because of the outsized impact a product team can have. If they’re not firing on all cylinders, the opportunity cost can be enormous, so we want to support you in getting these hires right.

📖 Further reading:

• “Good product manager, bad product manger” by Marc Andreeson
• “Great PMs and Good PMs” by Shreyas Doshi
• “A CEO’s guide to Product” by AFK Partners

‍

Product job titles:

Understanding PM job titles is hard for a few reasons. Here, I’ll try to give some clarity about how to assess a candidate’s capabilities, and what title you might therefore use.

Product owner vs product manager vs project manager

The difference between “product owner” and “product manager” is largely stylistic. “Product owner” is more common in the US, and typically means more junior product manager. It also can refer to a specific role within Scrum processes, so “product manager” is more commonly understood.

A “project manager” is someone who will assign work and make sure it’s running on schedule. This is not product management, per our definition above. Project management can be a part of product management, but I would not consider that a project manager would necessarily have product management expertise.

Seniority

At a large company, the PM ladder might be:

• Chief Product Officer
• VP Product
• Product Director
• Head of Product
• ‍
  ——————————————

• Senior PM
• PM
• Junior/Associate PM

Above the line are management and below the line are individual contributors (ICs).

Some organisations have “Principal” and “Staff” PM, which typically means they’re very high performing ICs that don’t want to go on a management path.

“Product Lead” is a weird one. Sometimes it means “Senior PM”or it can mean “Head of Product”.

Smaller companies might skip out some levels of seniority. For example a ‘Head of Product’ might be the only PM and therefore an IC. In other companies, the ‘Senior PM’ is really acting as VP.

For simplicity, I generally break it down into four questions:

1. Do they manage ICs?
2. Do they manage people that manage ICs?
3. Have they led non-product functions (like research and product design)?
4. Are they on the leadership team?

This will help you to gauge what they have and haven’t done to understand their fit for your needs.

‍

What skills to look for in a PM:

This is a huge area on its own, and is very subjective. Here are the basic things I look for in PMs:

• Communication – can they deliver a message in a way that their audience cares about and understands? Matt Parish from TrueLayer points out that in early stage B2B, a PM will likely need to go out and talk to clients, so the ability to sell is a big plus.
• Ability to simplify – all product decisions are complex, so can they identify and focus on only the important bits? Can they turn that into a simple decision? The smartest people make things feel very simple, so keep an eye out for anyone who makes things feel complex.
• Prioritisation – can they let some fires burn while they focus on others? Do they see the value of choosing just one or two things to work on?
• Working well with others – can they get people on side? Can they listen before speaking? Are they broadly likeable? Building product is a team sport.
• High agency – do they take ownership of getting stuff done? If they’re met with a challenge, do they find a way through or give up?
• Product sense – do they have good intuition for what users will like? Can they communicate this in a way that gets people on side (e.g. “users will expect this common pattern” rather than “I prefer it this way”)?

There are other things that they need the capacity to achieve, but don’t need as a starting point to perform well on the job. These are:

• Domain expertise – are they curious, and will they care about the industry they’re building for?
• Business acumen – do they understand that they’re building a business, and a great product is a means to an end for that? Keep an eye out for people with an active distaste for business or an unwillingness to learn about it.
• Leadership – this is when “working well with others” becomes a strength. PMs need to lead cross-functional teams without formal authority. They must do the same for senior leaders throughout the business. They don’t need it to get started, but it’s necessary to really thrive.
• Technical skills – PMs do not need to code, but they do need to understand how code works. A strong understanding gives them more credibility with engineers. Above all, they should not be scared of technology.

💡 Author’s opinion:

It can be hard to identify this blend of skills, especially if you’ve never worked with product managers before. I have some basic, headline questions that I think about when making hiring decisions for a PM role.

When choosing what to work on, will this candidate:

1. Identify problems that are important to the business and our customers?
2. Be able to make decisions without having full data or the perfect answer?
3. Take user and colleague requests as input rather than just a to-do list?
4. Get to an 80% optimal outcome quickly and optimise for action?

If the answer is “yes” to at least three of those, then you’ve got a candidate that you should deeply consider.

📖 Further reading:

• A thread on agency by Shreyas Doshi
• How to Develop Product Sense by Jules Walter
• How to interview PMs by Lenny Rachitsky (paid)
• “My favourite PM interview questions” by Lenny Rachitsky (paid)

‍

How much to pay:

There’s no right answer here. As product people don’t know each other’s salaries, there isn’t really a “market rate”. Otta have a salary calculator that can give you a steer. Ravio is trying to answer this question, but I haven’t used them yet.

Generally I recommend making an internal benchmark, going to market with that, and having the flexibility to negotiate upwards if you need to.

It’s become table stakes for all good product folks to receive share options as part of their package. The amount will depend on the company stage and how much it’s been de-risked. When talking through equity, you should talk in current real terms (e.g. €25k), ownership terms (e.g. 0.1%), and potential returns (e.g. if exit of €1bn, these options will be worth between €X and €Y.).

I personally don’t recommend paying product people bonuses. These kind of incentives can encourage over-optimising for a single metric, at the expense of the business. To give a hyperbolic example, I was once in the room where a team discussed removing the company phone number from the website, to reduce customer contacts.

📖 Further reading:

• AngelList tool to calculate market rate salaries
• Index Ventures share options calculator
• Balderton’s guide to employee equity

‍

How to write a job description and advert:

One of the most important parts of the job advert is the company description. Make the opening sentence and paragraph punchy and exciting. This is often missed.

When it comes to responsibilities, I recommend being straightforward rather than making a very, very long list of everything they might be doing.

I also recommend having a clear picture in your mind of who you’re looking for, but keeping that off the job description. If you say “at least 5 years experience”, you’ll cut off a perfect candidate that has only 4.

With PM roles, you should look for the most exceptional people rather than the most experienced. In early-stage companies I have generally seen low correlation between high-performing product people and years experience. Stronger correlation comes from high agency, passionate people, which are annoyingly harder to see from a CV.

Domain vs product expertise

One big question when hiring PMs is whether to optimise for product expertise (i.e. how to build products) or domain (i.e. sector expertise).

A good product manager will need both, and I believe domain expertise is much easier to acquire on the job. You can learn about an industry by exploring it and talking to customers. Product expertise comes only from many years of training.

Almost by definition, people building innovative products won’t have done it before. No one had built Twitter before Twitter. Domain expertise definitely has it’s value, but I don’t generally optimise for it when hiring.

Note that not everyone would agree on my preference for product expertise over domain expertise here. It’s a subjective view, so treat it as such.

‍

How to find great product people:

It’s best to create a fairly large funnel to hire a great PM. Here is some research done by Lenny Rachitsky (ex-AirBnB PM) and Ashby, the recruitment platform. It shows roughly how much drop-off you can expect at each stage of the product hiring funnel:

Where to post the job advert

Otta is the most popular platform in the UK for tech jobs right now, and is well worth posting on. Their content team will add a bit of a blurb about why your company is great to join, which can help you to stand out.

Others include:

• ‍Unicorn Hunt (don’t think very popular now though)‍
• Lenny’s Job Board (more US-focussed)‍
• Mind The Product (slightly more US-focussed, and traditional companies)‍
• AngelList Jobs (I haven’t used this before)‍
• ProductHunt Jobs (I haven’t used this, US-focussed

Generally you want to get the word out, so I recommend posting anywhere you can. LinkedIn is probably useful, although many PMs will avoid it and other large jobs sites due to noise. Noise comes from the wide range of company types on there, and “product manager” filters pick up many irrelevant results (e.g. “marketing manager for a beauty product”).

Using your network

The best product people get hired through their network. As mentioned before, Product Management is over-demanded and under-supplied, so experienced product people generally don’t need to sift through lots of adverts and applications.

Also, as PMing can be so varied at different companies, recommendations are a useful signal.

Utilise your network as much as you can. Ask your PM connections to share your posts on socials, and offer a reward if they bring you the winning candidate.

If your PM network is weak, speak to people in adjacent functions – product design, engineering, user research.

Your network is by far your strongest asset in finding a great PM.

Approach people directly

PMs – especially the best ones – are used to having recruiters in their inbox. Recruiters are easy to ignore.

Messages from founders are rarer, more flattering, and harder to ignore. I always recommend taking the time to see if you can bring candidates in yourself.

Make a list of great product companies that you admire. Use LinkedIn to find product people that work there currently, or have done previously. Message them and see if they’ll talk to you about the role.

If you need an intro, you can always say that you’re hiring a PM, and would love their thoughts on the role, and see if they know anyone that might be a good fit. I’ve found PMs happy to help give advice and introduce their friends, even if they’re not receptive to a sales pitch.

Recruiters

Recruiters can be a useful tool here too. I personally haven’t used them much, and I find they don’t understand product as well as they should. But they can bring you a bunch of good candidates.

Few & Far are the best agency that I’ve worked with. They make a big effort to understand product, and are well respected by product folks.

‍

How to scan CVs:

What makes a good CV is very subjective. Every company and role is different. Here's the list of things that I normally keep an eye out for.

Positive signals:

• Well-rounded experience. Has performed successfully in different industries / markets. As well as showing an ability to learn, there are crossover skills and experiences that can be very useful.
• Has learned about product somewhere “good”. Product management is a weird, ill-defined job. Because of this, I look for experience where they’ve built a great product, or learned from strong people.
• Ex-founders. Founders know how to work with people, have strong leadership skills, and can make prioritisation decisions. They make great product people (and vice-versa).
• Got promoted internally. If they’re trusted enough to get promoted or manage two teams simultaneously, that’s a fantastic sign that they were respected and performing well.
• Worked on core product. Companies typically give their best performers the most important features. The more core the team’s focus, the more highly regarded they are (typically).
• Experience at early-stage and scaling. Each stage is wildly different in terms of product team needs. Exposure at both stages will make sure the PM knows how to be scrappy and plan for success.
• Side-projects. But it can also be a very strong signal that the person is passionate and curious. Product management is about continuous learning and it’s useful to look for a signal of that. Don’t discount people without side-projects though, as people with extra responsibilities (e.g. carers, parents) will have much less time for side-projects.
• Technical skills. They don’t need to code to be a PM. But they shouldn’t scared of code and the more tech knowledge they have, the better. Knowing how to code can be a real asset.

Negative signals:

• Non-incremental external promotions can be a bad sign. If someone is a PM for a year, then suddenly VP Product it probably means that they were hired by someone inexperienced. They won’t have had time to learn the foundations and might be over-optimising for job title.

Neutral/ignore:

• Certifications. I don’t know any good PM who had one. It’s not a bad sign at all, but I view it as entirely unnecessary.
• External promotions. Due to the supply/demand imbalance, PMs are always getting offers of promotions to go elsewhere. Internal promotions are a much, much better signal of performance.
• Job hopping. PMing is different at each company. It’s entirely reasonable for a PM to join a startup and decide a few months later that it’s not for them. As long as they have some proof of consistent performance, I don’t worry about short stints.
• Big company experience is useful to a point, but can lead to bad habits. PMs at 5k+ employee companies will own a tiny part of the product, and their ownership/agency will be severely diluted.

‍

How to interview a product manager:

Generally, there’s a few parts to this process.

Skills:

This needs to be conducted by someone with product experience, or the person currently owning product. You want to understand that they can make prioritisation decisions, know how to talk to customers, can use data, work with design etc.

I like to make sure engineers have an opportunity to be a part of the process, and this is a good time for that.

Some good questions include:

• Pick a high-impact project that your team decided to work on. How did you decide that it should get your attention?
• How do you weigh up whether to focus on fixing bugs vs shipping new features?
• What would you improve about our product?
• Which product had a great user experience? What makes it great?
• You wake up one morning to find out that no one is using your product. How do you debug what the issue might be?

Culture:

This is to test if they will be able to think and act in accordance with company values. Product is a very important position to get right, and having someone who can play well with others is critical.

I like to involve people from marketing, design or research here, if the company is big enough. Otherwise, fold it into the regular founder interviews.

Some good questions include:

• Tell me about a time you disagreed with someone on your team and how you resolved it.
• You have a big idea of how to change the product that will affect every department. How do you go about convincing people it’s the right thing to do?
• You have the option to work on a feature that will grow the business but might upset customers. How do you reconcile the two?

Scenario:

❗ Warning:

Take-home tasks can have a bad reputation. Some companies have used them as a way to get free work in the past, which has everyone’s back up about them. Conversely, they are a very useful way to better understand a candidates thinking.

If you want to minimise friction, I recommend giving at least a week to complete a take-home task, and set clear expectations on the time it should take. If this is more than a few hours, consider paying candidates for their time.

The most important thing here is to be respectful of candidates time, reply promptly, and give them clear feedback on their work.

Ultimately, it’s very, very hard to assess someone’s product ability from a regular interview. Asking them to walk you through a scenario is a useful way to see their ability to do the job, and also how they communicate and persuade. It’s a useful time to put unexpected things to them to see how they react.

I recommend leaving the scenario until last as it’s quite a big ask for both you and them. I normally like to provide the candidate with the scenario ahead of time and make the hiring manager available to answer clarifying questions over email.

A scenario might be a small question “what would you change about our landing page?” or it might be big “what should we change about our product?”.

There are a few different ‘types’ of scenario that you can try.

Hypothetical for your company: A made up challenge that you could realistically face. This would let you understand what they know about your industry and the specific challenges you might face.

Real for your company: Talk through a challenge that you’re actively working on. This lets you see what they’d be like to brainstorm with. Matt Parish points out that if you don’t come from a product background yourself, these tasks are easiest to evaluate.

Hypothetical for another company: Give them a company or ask them to think of one. This can be useful as it is neutral (you know the same amount as them about it).

Totally hypothetical: You can test them on something completely abstract, to see how they handle challenges. I believe that Monzo used to ask designers to design a toaster from scratch to see how they approached problems.

Example 1 (from Monzo)

We’re considering launching our product in the United States at some point this year. Talk us through:

• How we should structure our product teams given this major new market focus?
• How much should we build a new product vs using the existing tech?
• We’re considering launching ourselves, or with a partner instead. What are the pros and cons of each approach, and what would you recommend?

Example 2: (from Deliveroo)

We get feedback from customers that the delivery experience isn’t great for them, including customer support. Talk us through:

• How we should think about whether to buy solutions, or build them ourselves?
• How we find out the root cause of our problems?
• If this problem is urgent, how would you get the team running to solve it quickly?

Example 3: (from Wise)

We’re heavily prioritising growth, but growth has stalled in the last few months.

• How would you diagnose the root cause for growth stalling?
• What do you think our growth levers are?
• How would you approach product work to get us growing again?

Example 4: (from Meta)

You want to build a product to help people to find a dentist.

• Who would you build this for?
• How would you approach understanding the problem better?
• What might an MVP look like?
• How would you measure success?

Example 5:

We want to improve conversion in our overall product flow.

• How would you find different opportunities?
• What would you prioritise, given what you know right now?
• What would your strategy be to maximise gains over 6 months?

‍

It’s important to note that you’re not looking for them to get the right answers. There’s no way they’ll guess those. Instead, you’re looking for:

• Clear communication and structured thinking.
• They’re keen to talk to customers and look at existing data.
• They want to ship quickly to test things out.
• They include engineers and the whole team along the journey.
• They have a clear understanding of tradeoffs about different decisions, rather than just trying to find the perfect one.

📖 Further reading:

• FB product sense interviews