How to Think About Making Your First Product Hire

Collections: Founder Field Guide

When the NextView team works with founders and portfolio companies, we focus on being helpful in the four areas that matter to seed-stage companies: building great products, getting lots of customers, attracting great talent, and not running out of money.

One of the biggest decisions founders have to make happens to fall into two of those buckets: making the first product hire. There’s a lot to figure out. When should they bring on a product hire? How senior should she be? What kind of background should she have? To whom should she report?

If you’re building products that have aspirations to redesign the Everyday Economy, these are even more important considerations. The potential impact of your products can be huge and mass-market.

It’s especially important to create a culture of building for everyday users, starting with your first product hire.

As someone who joined Blue Apron as the first product hire and helped scaled the product, design, and analytics teams through hyper-growth and IPO, I want to share some learnings both from my personal experience and from conversations around this topic with founders.

When to Hire Your First Product Manager

Compared to other functions, the timing for your first product hire is often less obvious. The role is by definition multi-disciplinary and thus feels less specialized. As a result, many early-stage startups decide to get by with others “wearing the PM hat” — usually one of the founders (the CEO or someone who has a product background), the non-founder CTO/VP of Engineering (or just the early engineers), or sometimes the head of Marketing.

Things might just be humming along fine for a while with the above setup, but once you start observing the following signs, you should start building a talent pipeline for the first product hire:

1. You’re unsure whether the team is executing on the highest impact product initiatives.

A PM is responsible for creating and prioritizing product initiatives through her understanding of 1) the users and their needs, 2) the business objectives, 3) technical possibilities. Developing depth in all three areas requires bandwidth, and at some point, you will find that whoever is wearing the PM hat is no longer able to do so at a high quality because she has “another day job.” At that point, you need to bring someone on whose full-time job is to be responsible for uncovering the highest-impact product initiatives and running a rigorous prioritization process that properly evaluates impact vs. effort.

2. The team’s velocity drops and what you’re shipping feels like a Frankenstein.

As the company’s headcount grows without a PM, you will start noticing everyone (yes, EVERYONE) feels like they should have a say about the product experience — from the font to the color of the button to the backend logic. It’s not a bad thing to have a culture where there’s collective sense of ownership, and it’s very important to make sure the voice of the relevant stakeholders is heard. You need a PM who can “herd the cats” effectively and apply judgement on incorporating the opinions and feedback without sacrificing the integrity of the user experience.

3. What’s shipped lacks polish and completeness.

Missing edge cases. Sloppy user-facing copy. Forgotten trigger email that’s critical to the user journey. These are just a few small, but important examples of how the quality of your product could suffer when there’s no one fully responsible for the end-to-end product experience.

4. You aren’t continually iterating.

Related to the above, when you don’t have a directly responsible individual (“DRI”) who’s tasked with driving the product forward, the organization can quickly fall into the trap of shipping one-off features. Shipping V1s is important, but it’s a huge missed opportunity if you can’t use what you learn from user feedback and product performance metrics to ship V2, V3 and beyond.

The Qualities of a Great First Product Hire

Due to the cross-functional nature of their job, PMs can often come from different backgrounds and have different experiences. That said, there are certain qualities that’ll help your first PM succeed in the nascent stage of company- and product-building:

1. Seniority and experience level.

How senior you go for your first product hire depends on whether the company will be in a place to accelerate its product development well beyond the bandwidth of one single PM in the next 3–6 months.

If you need build out a product team soon, you should aim for someone who has seen the movie before. She should be able to roll up her sleeves to execute before a team is in place and step into the leadership role to build out a team quickly.

Otherwise, your best bet is to find a solid senior PM who has managed large scopes and shipped a diverse variety of product experiences. She should be able to hit the ground running without senior product guidance. Bonus if you can find someone who demonstrates the capacity to scale with the company, as this person might become your best Head of Product candidate 18 months from now.

2. Do-it-all without hand-holding.

Regardless of the seniority level, your first product hire will be walking into the wild-wild-west the moment she steps into the office — there likely isn’t a roadmap, sprint planning, standard QA/UAT process, decision-making mechanism across stakeholders, etc.

To succeed, this person needs to have the attitude and aptitude of doing it all without needing instructions.

She’ll need them both while helping the company figure out how the product team should work and constantly unblocking herself to ship products at a high velocity with few resources.

3. Flexibility.

I sometimes describe the job of a PM as “filling in the white space” — the job description changes based on what your teammates (engineers, designers, analysts) are good at and like to do. This is especially true at early-stage startups when the team is less complete.

When I first started as a PM at Blue Apron, there was no product design team, no dedicated analytics resources, and no engineering managers — so I quickly learned to double as a UX designer in the way I spec’d out the product, write my own SQL queries to get answers, and review technical architectural decisions with our engineers. As we started to build out more specialized functional teams, the PMs were able to focus on filling up different part of the white space.

Given the pace of change at early-stage companies, the ability and willingness to wax and wane as the white space changes is key for any PM to succeed — but it’s especially important for your first PM. Not only will this adaptability help them succeed in the months after they join, but it’ll also set the standard for future PMs that come on board.