Hiring the Team as a Product Leader
15 March 2020 ‧ 11 min read
One of the crucial areas of responsibility for product leaders is hiring to build up the team. For an overview, read my high-level article on product leadership responsibilities, or continue reading for a deep dive on team building.
Building up a high performing team gives product leaders leverage to deliver on the product direction. It's perhaps intuitively clear, but a product leader alone will never be able to achieve as much as one with a great team. This makes building the team such a crucial aspect of product leadership. What makes this aspect particularly challenging is the uncertainty and ambiguity that's inherent to product development. It's often impossible up front to know what ideas will turn out successful or not, so a team of capable executers isn't enough—the team needs to be empathetic to understand the real customer needs, creative to design solutions for the needs, capable at technology and execution to deliver the solution, and analytical and business minded to make the product viable from a business perspective.
The first step to building a great team as a product leader is of course recruiting the right people. Recruiting consists of determining team composition, sourcing candidates and building a candidate pool to draw from, the actual hiring process (from application through to accepting an offer), as well as onboarding new people onto the team. These processes sound like HR processes, and a good HR and recruiting team can help run these processes effectively as well as provide leverage for the product leader on some tasks, but I believe that in a people- and soft skill-focused environment like product development, leaders must be deeply involved in the process.
In this article, I will cover the following aspects of building up a product development team:
- Team Composition and Roles
- Hiring Process
- Onboarding
- Building a Talent Pool
In follow-up articles, I will dive more deeply into developing the team that's already there, as well as building up the product culture.
Team composition and roles
Who constitutes the "product development team" or "product teams", and what are the roles involved? And which parts of this team do we consider product leaders responsible for?
The answer to these questions, of course, is a multi-layered “it depends”. It depends on the pre-existing role definitions in the company, the organization structure and reporting lines, the available talent in the company and in the market, as well as the product including its customer value proposition, technology, and business model.
As examples, a company making developer tools will likely need fewer designers than one making consumer apps. A company with heavy machine learning components will likely consider data scientists as parts of the product development team. A technically complex product will often require more engineers per product manager / designer than a simpler one. Some companies have dedicated data analysts, user researchers, product copywriters, or localization specialists as part of the product development team, others don't. QA, ops, and infrastructure can be organized quite differently as well.
Since these questions are so dependent on the product and company, there are no best practice answers for them. Product leaders still need to think through these questions and decide what is the “right” answer in their circumstances.
As a general best practice, the atomic organizational unit of high-performing product development teams is a cross-functional, autonomous product team with some degree of self-organization. This team should be between 3 and 8 people (“two pizza team”) and contain as many of the critical capabilities for product discovery and delivery as possible. Typically, this means at least a product manager, a product designer, and a few engineers. Since engineering leadership is often considered separate from product leadership, for the rest of this article I will focus mostly on the product-specific (non-engineering) roles, although a lot of the advice would still hold for engineering roles as well.
Once the desired team composition has been established, another important set of decisions is around how the roles are delineated. This is especially important at interfaces between the different disciplines. Some examples: are product managers or designers expected to have (deeper) expertise in UX? Should designers be able to help code the front-end? Who owns breaking down larger tasks into smaller tasks for delivery, product managers or engineers? How are architectural decisions between frontend and backend made?
There are some interesting aspects to these questions. Firstly, they depend on the availability of talent (in the company and in the marketplace). You can't expect designers to be able to help with coding the front-end interface if you don't have or can't hire designers who can (or want to) code, for example. Secondly, these role requirements should be blurry: since you want teams to self-organize to some extent, it doesn't really matter if in every team these delineations are drawn the exact same way. However, thinking about these delineations still makes sense because they inform what you will be looking for in your recruiting process. In addition, it helps correctly set expectations and avoid “blind spots” where you are simply missing an intersectional skill on the team.
Hiring Process
In terms of the hiring process, there are a few things that I believe are critical. It starts with a clear job description—not just the one that is posted on the website, but an internal one as well. It should be clear how the new person is desired to fit in with the team in terms of skills, seniority, etc. This may have to be adjusted upon hiring, of course, since you hardly ever find the candidate that matches the profile perfectly, but it serves as a common frame of reference.
From this job description, as well as from company culture and values, a set of evaluation criteria should be derived—ideally, a manageable number, less than 10 or so. I like explaining these with a few bullets and sharing with the entire interview team.
Then, the interview process itself should be set up. How involved (and time consuming for everyone involved) the process is depends on the available talent, the urgency to fill the position, as well as the seniority. As a general process, I like one to two phone screens / interviews (at least one going in depth with hiring manager or peer), followed by either a take home task or portfolio review, followed by an (onsite or video) half to full day interview loop. During the full interview loop, the candidate should meet peers, cross-functional team members including engineers, and leaders.
Interviews are typically a mix of case studies (“design / improve product X”), behavioral interviews (“tell me about a time when you did X”) and hypothetical interviews (“how would you do X”). Take home tasks are mostly case studies with the benefit of more time for the candidate to think through their responses (after all, in actual day to day product work, we don't design products on the spot in hour-long whiteboard sessions). They have the disadvantage though of being a potential time sink (time waster) for candidates, and some candidates feel as though they are being asked to do free work (especially if the take home task is a case study about the company's product). In reality, that's hardly ever a risk—after all, if a candidate with no context can come up with a better solution than the company could after a few hours work, then either the candidate is an instant hire or the company was doing something really wrong. However, to avoid that, it could be wise to use a case study that's unrelated to your own product.
Different companies have different intensity of their full interview loop. When I interviewed at Yammer, I spent a full day there (and was pretty much dead at the end of the day). In interview loops that I have designed, I have tended to make them a bit shorter, maximum three to three and a half hours, so that candidates don't feel completely drained half way through the day. It's also good practice to let the candidate know in advance roughly how the day will unfold, although of course last-minute changes are sometimes unavoidable.
It's great to start the interview day with a candidate presentation—of their take home task, if there was one, or of some past work (“portfolio review”). Starting off with something that the candidate can prepare for and is familiar with can help them feel more confident and get over the interview nervousness.
After the presentation, follow up with smaller interviews with one or two interviewers each. Each interview should focus on specific evaluation criteria, so that at the end of the day, all criteria have been covered in at least one interview.
One comment on “culture fit” and culture fit interviews: it is of course important to understand whether the candidate would be able to collaborate well with the rest of the team. However, culture fit interviews have the risk of being anti-diversity filters: they filter out anyone who is too different from the interviewers (in terms of behaviors, but that can often be correlated with differences in upbringing and cultural background). Now, we all know that the technology industry has a diversity problem, so it's already a challenge at the outset. This is not just the case because of some arbitrary goals to increase diversity, it's also due to very selfish business reasons: it has been shown time and again that more diverse teams perform better (although they feel less comfortable which is why the “could I imagine working with this person” criterion is not a great predictor). For these reasons, I like to use three questions to assess the equivalent of “culture fit”:
- Is this person an asshole? Assholes undermine the dynamics of any team they're on, so don't hire them.
- Does this person subscribe to our (company / team) values? By anchoring the evaluation to the values, you remove personal bias.
- Would the person add something to the team? This is an actively diversity-increasing question. The contribution could be in terms of skill (“she is a great illustrator, and none of our existing designers are”) but also in terms of background and perspective (“he doesn't have a college degree because he had to work in his parents' shop from an early age, then taught himself to code”).
After the interviews, collect feedback from the interviewers. In my experience, it works well to collect a structured form from each interviewer along the evaluation criteria, and then have a debrief discussion (20-30 minutes) with all interviewers on the day of the interviews or the next day. In the debrief discussion, walk through the evaluations, discussing especially where peoples' opinions differed or where there seemed to be a strength or a weakness of the candidate. No decision is made in this meeting (although sometimes it is pretty obvious how the decision will pan out), the hiring manager or other decision maker decides based on the input collected after the discussion.
It's also good practice (unless the HR or legal teams object to that) to give specific and actionable feedback to candidates who you spoke to in person but who didn't get an offer. The feedback should be clear about what the candidate should work on. A formula that I've found works well is: "While we were impressed by your X, we were looking for more evidence of Y." The wording "we were looking for more evidence" makes it clear that you are only judging the candidate's interview performance, not the candidate as a person—after all, the interviews are really all you have at this point.
Onboarding
After hiring a new team member, product leaders have to ensure a smooth and comprehensive onboarding process. I'm not talking about the administrative aspects here (getting a computer, signing contracts and forms, and getting access to office and tools), but about the product specific topics.
The onboarding firstly needs to cover the product direction. The new hire needs to understand (and ideally be able to reference back to) the product vision and strategy, and understand the currently applicable goals and high-level roadmap. Since this information is a lot to take in at once, it makes sense to share the material in advance and perhaps also stagger the discussion over multiple days so the higher levels of the product direction can sink in first.
Secondly, the new team member needs to be introduced to the relevant processes and tools, for example discovery and delivery processes, or design and project management tools. This introduction doesn't have to be super formal, but should at least cover required artifacts (what kind of documentation is required), mandatory tools and how to get access, and recurring meetings and milestones.
Next, the onboarding should cover the product and its historical context. Of course, new team members should be expected to thoroughly investigate the product themselves. One good practice here is to have anyone joining the team present a teardown of the product—things they liked, didn't like, didn't understand, were wondering about—after a couple of weeks. This incentivizes the new joiner to dive deep into the product, but also helps the broader team, since someone looking at the product with fresh eyes always sees issues that everyone else has long learned to live with. Product leaders should also provide historic context: what were critical decisions taken over the course of the product's life so far, and why were they taken that way? How can the new joiner find what was tried in the past?
In addition to the product itself, the onboarding should also cover the customers. What do we know about them? What resources and research are available about them? How does the product team talk to them? All of these are critical for a new joiner to start improving the product for the customers.
Next, the onboarding should cover technology and data. Depending on the product and the team setup, this onboarding could be deeper or more shallow, but I believe it is crucial that everyone on a product team has at least a general understanding of the overall architecture of the system and constraints stemming from it, is aware of what data is collected and how it can be accessed, and knows what the critical metrics that are being tracked are.
Lastly, the new team member should be introduced to key people. This includes of course the team they will directly work with, but also stakeholders across the business that might be helpful to their work. Product development is a team sport and requires working across functional and team boundaries, and helping the new team member build a network in the company will make them immediately more effective.
Building a talent pool
To go from simply “hiring” to “recruiting”, product leaders should also think about how they can build up a talent pool. Ideally, they have a capable recruiter on the HR team that can help, but there are still some concerns here that are more product specific.
Firstly, product leaders should think about employer branding from a product perspective. Networking, hosting product-related events and meetups, or giving talks at conferences all can help make talented people more interested in joining the team.
Another way to improve employer branding as a product team is to talk and write openly about the product development philosophy and methodology as well as product development values. Being transparent about how product development is done both helps build the brand and of the team, gives back to the community, and helps pre-filter applicants who agree with your principles and values. As an added benefit, writing about these in a way that can be understood by the general public will often help further clarify the thinking which will benefit the existing team of the company. Two companies that are particularly good at this approach are Basecamp and Intercom.
There is an additional aspect that is relevant specifically for product management roles. There is no degree for product management, so everyone in product management comes from a different background. This means that product leaders should decide if they consider lateral hires (meaning hiring candidates without product management experience) into product management roles.
There are several potential ways to do this: the lowest risk is often to allow internal transfers, often of engineers or designers, into the product management role. These candidates have the advantage that they already understand the product, processes, and organizational context, so they will only have to learn the more PM specific parts of the job. The risk is that they might get "stuck" in their old roles—the former engineer might be tempted to "just write a few lines of code", the former designer to "just create a few mockups". This behavior can help unblock the team in some instances, but can lead to role confusion and neglecting the remaining product management responsibilities in many others.
A somewhat higher risk is to hire external applicants without product management experience. These candidates need to show very high potential for this to work, and their onboarding should be expected to take a few months, not weeks—after all, they have to learn the job and the context of a new product and organization. It should be absolutely ensured in these cases that the new hire has appropriate support—by their manager, but perhaps also through assigned buddies and mentors as well as formal training. The bigger and more mature the product development organization is, the more likely would it have this capacity.
The ultimate stage of this would be formal PM training programs like Google's APM (associate product manager) program, which hires high-potential candidates out of college and then puts them through a structured training and job rotation program to build up all the skills necessary for a product manager. Only bigger tech companies have the scale and capacity to run programs like that.
Hiring, especially when an initially promising candidate is taken through the entire process only to get rejected at the end, can cost a lot of a product leader's time. However, the time to get this process right is well invested. Not hiring is never a good alternative in the long term if the product is growing, eventually the product leader will desperately need more leverage through a bigger team and starting a hiring process only then will be too late. Running a sloppy hiring process will lead to bad hires and hurt team morale. So it's best to get it right from the beginning.
I hope this article was helpful. If it was, feel free to follow me on Twitter where I share thoughts and articles on product management and leadership.