When should you a hire a Product Manager?
Over the past few years, a lot of founder friends have asked me “should I hire a PM?” or “when should I hire my first PM?” and I’ve continued to think about it and observe other teams.
I ended up in a unique position at Lola — you are almost never the first employee as a PM (one or more founders do Product). That’s given me the chance to see how we scaled our product organization from day one on. Sometimes scale means hiring, but sometimes it’s finding the right person internally or breaking the responsibilities up between multiple people.
Not Until You Need It
One of the biggest complaints about the Product Management discipline is that it can slow things down. Another one is that PMs just sit in meetings all day and don’t have time to help the team execute. This tends to happen when a PM team is too large, or has too many overlaps in responsibility.
The overlap can be one of the most toxic things to a Product team —
- This means that there’s no clear owner for how to make decisions, and things can get bogged down in politics.
- No clear owner means people start to worry about credit, and can start to “land grab” rather than trying to move things forward.
There’s a few good ways to avoid this.
Don’t hire a PM before there is a pain point.
Some people argue that you should hire early so they can start to plan things out and prevent product debt in the future. I’ll say the opposite — if you (and your team) think everything is fine, chances are you don’t need to hire an extra person. If the right things are getting shipped to users in a timely fashion, the PM will be in a place of “proving” why they need to be there instead of being able to jump in and immediately help the team.
That said, almost every team starts to find these pain points as it grows. They include:
- Struggling to keep track of what to build next (lack of a prioritized backlog).
- Building solutions that don’t work because no one had time to think about them (and you should have caught it).
- Shipping has slowed down due to mismatched priorities between teams or poor communication between teams.
- People on the team don’t feel a sense of “why” we’re building something.
Don’t hire a PM when there’s another (good) way to solve the problem.
Often times, you don’t necessarily need an entirely new person to solve an issue. One thing we struggled with early on was getting enough time for QA — both for pixel alignment from design, and for testing a full range of items. I was also overwhelmed. It was tempting to say we could hire a junior PM to help with some smaller specs, project management, and also give them QA.
We didn’t. Instead, we had one of our travel consultants do part time QA. This had rippling benefits. He learned good bug reporting technique (and helped other agents learn it to report issues in their tools!) plus, he became the go-to person for consultants to ask about app questions to. This solved the problem for quite a while. We did eventually move him into a Product role (no additional hiring work required).
We’ve done that a few times to solve issues — our VP of Ops did a ton of work on our travel consultant tools. Our Engineering leads do a weekly “roadmap progress” meeting that could have been a Product meeting other places I’ve worked. A lot of product pain points can be solved within the company, and give your existing employees a chance to grow their skill sets.
So then when do you hire?
This isn’t to say you should never hire in Product, and we recently hired another Product Manager onto the team. So given all that, when do you hire in Product?
PM #1 – When the Founder Stops Scaling
The first time you should hire a PM as a founder is when you stop being able to run the product team yourself. This is likely the most important Product hire — the Founder has to get someone else to completely internalize the vision. The Founder-Product relationship can be one of the most difficult (and valuable!) ones in the company.
You can see when the founder stops scaling when the pain points above start to happen, but here’s some clues that you can look for.
Founder Background
This one matters the most. It impacts both when, and also who you need to hire first.
If you, as a founder, want to keep doing Product yourself, hiring another PM may be challenging. That could be because you were a PM before, and it could be because you like it. If you’ve been a PM before, or you naturally gravitate towards this work, you’re more likely to be able to keep it up to a larger team. If you’re an experienced Product leader, you can also get away with hiring a more junior Product Manager and managing them yourself. You can wait until the team is bigger to hire another leader.
If you’ve never done it before (say, you’re an engineer and much more concerned about the technical architecture — or you’re a sales person and have never worked on a product before) you’ll probably want to hire the role sooner. You’ll probably also want to hire someone more experienced. They’ll be more likely to have seen common product pitfalls before and help you avoid them.
It’s important to define what type of Product hire you’re looking for, and how you expect to continue to interact with them. Do they make the final decision on product, or do you?
Product Complexity
Another piece is product complexity. My least favorite way to slice a Product team is “I’ll do the high level strategy and they’ll do details” — it makes it hard for the detail-level person to make good calls. It also makes it harder for the high level person to connect with the rest of the team.
Lola had the advantage of having a user facing product (the app) and an travel consultant facing product (the tools we make for them). There’s also interaction between the two that needs to be managed. This provided a nice line for how to think about the Product organization. At Kickstarter we had a similar structure — we had backers, creators, and tools for our community team.
The more complex the product, the more likely you are to be able to bring in an additional product resource to think deeply about one of the spaces — and keep the founder heavily involved in the day to day. If you do expect the product to be complex and scale quickly (thus needing to build a fuller product team), it may make sense to bring someone more senior in as the first product hire.
The Rest of the Team
The third thing to look at is the team. If the team has a large number of designers/engineers, chances are you’ll need more product support sooner. If the team is primarily sales and the product itself is simple, you’ll be able to last longer on just a founder. The experience level of the rest of the team also matters here. I’ve worked with VP of Engineering who can easily take on the role of what a junior PM would do in addition to their Engineering Management responsibilities.
PM #2 & Beyond
When you’re a company, you can often opportunistically hire “good engineers” or “good sales people” — chances are you have more work you could do, more sales you could make.
This isn’t so in Product. In Product you need to fit the person to the role. The model outlined for “when not to hire” and “the first PM” continues for subsequent Product hires. Luckily, the decision to hire the first PM is the hardest. Getting it right the first time can help with onboarding each additional hire.
Don’t forget the stuff above.
You don’t need another PM until the team you have is experiencing pain points, and you’ve tried to resolve them in another way.
Hire for a full job.
At Kickstarter, I was the ~50th employee, and the fifth PM (if you include the Head of Product). As I wrote before — it took six months from when I applied to Kickstarter until when I started. Between when I applied and when I started two other people had joined the Product team. To use one example Daniella had joined (from the community team) to work on internal tools. I wouldn’t have been the right person for the role.
For each PM hire, the job description shouldn’t be “oh we kinda need some extra help” or “here’s some features we might do” — instead, it should be about a distinct area the new PM can work within. The area can be smaller in the case of a brand new PM (for instance, my very first project was PowerPoint Broadcast Viewer for Symbian — all it did was connect to a server and show what the server told it to), but it should still be a full area. It took six months from start to finish with Kickstarter until there was an area that made sense for me — The Backer Experience.
Consider what you have so far.
As you build out a product team, you’ll start to have norms. You might find that everyone on the team is technical. You might find that no one is. You might find that everyone is very blunt. You might find that people prefer to communicate via email. The founders and first product hire tend to set the tone for the product team’s culture.
Each time you’re hiring, think about how you want to shape that culture. Do you want every PM to be technical? If not, consider hiring someone without a technical background next. You also want to think about if that PM will thrive with the culture you’ve already created.
As you add each additional PM, don’t just hire to solve the immediate job need. Also hire to make the product team more robust. Every hire should bring up the overall quality and strength of your team. Don’t make a hire until that’s true.
When should you hire a Product Manager?
It’s not a “when” that fits nicely with employee numbers¹. Instead you should do it when you can answer these four questions:
- What’s the current pain point on the product team?
- Why can’t you fix it (sustainably) in another way?
- What role will that person be playing in the product?
- How will that person interact with the founder? and/or How will that person add to the existing team — both other disciplines, and then the other product people?
(1) Okay, fine, I know you want numbers. The first one is the most important, and I would say the first PM should be no sooner than person number 10, but no later than person number 30.
