Product Managing Your Product Hiring

I've interviewed many different product managers, as well as helped several friends figure out how to get into the field. I've seen a consistent theme: many companies don't know what they're looking for when they start trying to hire a product manager.

People smarter and more experienced than me have taken a good stab at "what is a product manager?" I subscribe to Marty Kagan's idea from Inspired that a PM's main job is “to discover a product that is valuable, usable and feasible.” I also think product management as the intersection of tech, business, and UX is another valid take, and Ken Norton has great thoughts on what general qualities to look for when hiring a PM.

But even for PMs with the right general qualities, the actual work of product management can be very, very different, especially at different stages of company growth.

I've been recruited for product roles by small (<10 person) startups, and the first question I ask them is "Why?" In most cases, at this stage the founder should be handling product duties, and the company should spend their precious FTE slots on engineering, design, or sales.

I see most companies start to hire product somewhere between 10 and 30 people in. At that stage you have enough engineers that there are efficiencies to concentrating customer research and product design into one place, but probably too much work for the founder(s) to handle on their own.

At this stage, startups often look for somebody who can do a little bit of everything— some SQL here, some Balsamiq wireframes there, maybe some light web development, managing releases, and maybe even marketing. I've been that hire before, and as long as the company and PM know what they're getting into, I don't think there's anything wrong with that.

But even the most unicorn-y of PMs are rarely as good at UX as a dedicated, professional UX designer, rarely as good at cross-team coordination than a professional program manager, and rarely as good at data analysis as a data scientist. My ability to ship quality product that solves customer problems has grown immensely since I've started working alongside partners dedicated to these functions.

I'm not about to generalize over all of product management from the few dozen data points in my life and my friends'. I do think, though, that companies could be more reflective about why, at a given juncture, they're looking for a product person.

If product is about helping a team ship the right value to users, then the hiring question should be "Where is customer value being blocked?". Examples might be:

  • If you're constantly shipping high-quality product but it's not having the business impact you expect, hire somebody who knows customer development or product strategy (also: worry).
  • If you're constantly shipping product with high technical quality, but customers can't figure out how to use it, hire somebody strong in UX research and design.
  • If a growing engineering force has made it harder to coordinate complex projects across teams, hire somebody who can fix that— maybe a program manager role, or a PM with heavy release management experience.
  • If you don't actually know where your value is being blocked, maybe you want an early product hire with experience taking a product from your growth stage to the next, and insight into where the bottlenecks might be.

Of course, just because a PM has a strength in one of the above, doesn't mean they're a specialist— a successful product person still needs skills like deep customer empathy, critical thinking, clear communication, and leadership. But a spread of candidates will have spent more time on some facets of the role than others, and getting the right person to unblock value should be more important than fitting everybody into the exact same box. Maybe now that you have a data team, PM #4 doesn't actually need to be a SQL expert. Maybe for a certain role a hybrid UX / product role is a better fit to the teams' problems. Maybe you need a customer success person or product specialist to help make the rest of product more efficient at sourcing customer insights. Standardizing roles does have benefits, but you shouldn't prioritize a desire for tidy interview loops over actually accomplishing the end goal of the hire.

When somebody comes to a product team with something for the backlog, our eternal refrain is "What's the problem, how important is it, and what's the best way to solve it?" When hiring into product, I think it's time for us to start asking the same question.