Hiring product managers

One of the trickiest things to do is hire product managers in tech companies. Having put in place a successful product team at Unruly and worked extensively with numerous teams large and small I thought I’d note down my thoughts on how I approach it.

Definition of a product manager

The number one issue with the job role of product is its ambiguous and flexible definition. By its very nature, a product job requires a lot of cross functional skills. It’s really important to be clear on where exactly the product function fits in across your organisation:

- CEOs/entrepreneurs often identify that taking on a product management role frees them up to focus on other aspects of the business. It helps to be very clear on what the areas the CEO wants to delegate and move on to are, as this will help identify what kind of product manager you are hiring for.

- In a technical orientated company, product will be required to have a certain level of technical skill. This can range from a broad outline of what the development team(s) are working on to the capability to prototype new features/products and pair with developers as the need arises. Be clear what kind of level of technical proficiency your company requires. Technical skill doesn’t define technical management skill either, so be clear about what development processes you’ll expect the product managers to take on. If the company is using a broken Kanban process, it’s important to recognise from the start that this is the first objective the new product manager is to take on. Just as important is the need to be clear on what is required from a business perspective - if the product function falls more on the ROI definition / measurement side, then you may lean towards more financially orientated skill sets.

- Critical to a product role is the ability to highlight good ideas and keep them bubbling up in communication across the company while downplaying or limiting the impact of bad ideas. Product is uniquely positioned within an organisation to ensure strategic focus is maintained, and the biggest part of that is making sure that all areas of the business are helped to focus on the best ideas. A big part of product for me is the ability to rapidly ascertain the value of a given idea, and feed that back to the organisation in a constructive way.

Job spec

To produce a good job spec, take the questions answered above and roll them into a high level document that highlights the key aspects of the role.

It’s somewhat cliched to specify excellent communication skills on any job spec, but with product communication is everything. The candidate will be cross-functional by definition, so highlighting the high amount of communication (versus, say, days of coding) is really important in weeding out full-time coders who may want something new but are generally poor communicators, and/or people who prefer to work in isolation to deliver work.

Taking the technical requirements very seriously and highlighting them at length in the specification is especially critical - product can be seen as a business development role with only a cursory glance towards technology. Being ‘passionate about technology’ can mean an avid reader of mashable and a fan of trying the latest apps, versus hands on coding experience in multiple languages so that they can communicate with developers at their pace.

Screening

I usually looked for a few key indicators on CVs/profiles:

Multi language skill
We hired at the technical end for most of our product managers, and a good indicator of overall technical compotence is having worked on a variety of technologies. Once a candidate shows good to excellent competency in two or more languages, then it’s a good indicator that they can pick up any languages and approaches relatively easily.

Hacking and tinkering
While we never looked for active github repositiories for product managers, I did look extensively for evidence of a desire to tinker and probe with various technologies. If they’re interested in product at a web/mobile tech business, then there should be evidence of numerous web sites built, apps prototyped, multiple OS installs at home and more. If they’re not interested in it outside of work, it’s unlikely they’ll be as passionate in work.

Surrounding skills
Particularly if the candidate’s previous experience is as a coder, then it is critical to look at the additional functions they performed in their roles. Writing documentation, giving demos and doing internal/external training are all indicators of someone who can be capable outside of coding full time. Interfacing with external facing clients/stakeholders on an ongoing basis is also a good indicator. In depth knowledge of other business functions, such as sales, operations, design are all great skills. Ideal candidates for product are often polymaths and generalists to varying degree.

Interviewing
The following is the list of criteria I evaluated candidates on:

Communication and attitude
It must be excellent. From the moment candidates met me in reception I was evaluating their ability to communicate. Product managers are required to interface with all kinds of internal and external stakeholders, they should be immediately able to deal with meeting new people. Nervousness is fine, but it’s still extremely important that they come across well in the short time an interview allows.

Technical skill
Since Unruly is a web/mobile technology company, candidates were screened for HTML/CSS/Javascript amongst others - given how basic a set of knowledge it is to grasp it’s a good initial indicator of skill. I would start off with asking if they can hand write the basic structure of a HTML page, and then build on that, eventually asking them if they can work out and rewrite some jQuery code. The critical thing here is not to make sure they know jQuery, but with a laptop in the room, can they quickly ascertain how to find out the answer and execute it quickly. Candidates who googled answers and ask the right questions were far more interesting than those who stared at the text editor in fear.

Depending on the technical level, we also added in tests like basic grepping/sorting of text files. Again, candidates didn’t have to know this off-hand, but they had to be able to work through it logically. We would do this with a senior developer at a workstation where possible.

I always asked for summaries of other work/personal projects - being able to succinctly describe different technical systems they developed or contributed to at a level I understood was a good indicator of their abilities.

Scenarios
I usually had at least three scenarios on hand which I gave to the candiate to read and then asked them to talk through how they would deal with the situation.

Communication example

It’s Monday morning on your first day in the office and your phone rings. It’s the head of sales and he says that a client has asked for feature X as part of project Y and needs to know if we’ll be able to implement it by Friday ahead of his project launch the following Monday. He says he’ll be able to secure $100,000 extra for the deal if we can get a quick answer. Unfortunately, the entire product and development teams are off-site at a training day so they are not around to ask advice. What steps do you take immediately and during the week?

Common sense is key here. I was always surprised by the amount of candidates who immediately told the head of sales they’d get the work done by Friday and he’d be back in touch with the details. Key points:

  • How do they deal with the phone call? What do they tell the head of sales they’re going to do? Do they set expectation correctly both in terms of answering the question (they can’t) and when they will be able to answer?
  • Do they think of asking for additional information? Do they ask about the deal size overall, what is meant by a ‘quick answer’, what the overall impact of the project is? Do they check just how unchangable these dates are? I usually had answers on hand to these types of questions.
  • What do they do when they get off the phone? Again, common sense: They should immediately be trying to contact people who can help them. Do they ask who else is in the office who may be able to help them? How far do they go?
  • If the teams who can help are off-site and uncontactable, how do they deal with that? Do they go back to the head of sales to explain what’s happening?

I usually followed this up, hopefully once the candidate had admitted that they can’t really deal with the issue the same day, by asking the candidate to explain what they’d do the next day when the development team was available? Key points:

  • Looking for awareness that this project may be one of many (they need to ascertain that), and the end result may be in fact a ‘no’.
  • Identifying the key people they need to ask. This is not specific to the company, but just about their willingness to say they’d talk to anyone they could find to help. Some candidates end up saying they’ll talk to the client directly, but it’s very important to ascertain why they’d want to do that, and who they’d inform before doing so.

Other scenarios:

  • Minimum Viable Product (MVP) definition and scoping of a new product to be sold on the company web site - Seeing how a candidate goes about specifying an MVP is really interesting
  • Compare the relevant merits of two product roadmaps - given a huge amount of effort is required to create product b OR c based on product a - how do they evaluate which one to go for?

Key things to look for

Some are obvious, some not so:

  • Interest - the candidate should be full of good questions about the role. Since product can be defined so broadly, they should be very eager to clarify all aspects of the role and what their potential contribution will be
  • Desire for ownership - Good product managers end up owning their products. Not necessarily in the sense of dictating their features or roadmap (though this may be the case), but in terms of understanding them in exhaustive detail and liasing with every stake holder.
  • Desire/evidence of autonomy and leadership - A good candidate should be very capable in a team, but also want the autonomy to make their own decisions and determine their own work load. Look for evidence of being a self-starter and creating value by themselves.
  • Comfortable with rapid change - Product roles often operate in a state of flux as products are created, maintained and killed. Just how big a part of their role this issue represents is something that should be made very clear to the candidate and they should be asked how they feel about it.
  • Entrepreneurial flair - There’s a lot of cross over between entrepreneurs and good product managers. It can seem like a catch 22, but it’s a good thing if they express the desire to start their own business in the future.
  • Kindness - At it’s very heart, for me, product is defined as a function which succeeds or fails based on its ability to bring people along with it. Whether thats making sure a development team understands the business case for a less exciting feature, or taking the time to explain at length why a set of features won’t be implemented that would benefit another department, the product manager must be kind. If the product manager ends up as the villain, then there work becomes difficult at best, or irrelevant at worst.

A candidate for product should be someone who you feel confident that if they were sent to an important client/stakeholder with no prep and no warning on their first day, they would deal with it professionally and learn as much as possible from it.

Compromise

Given that the ultimate product manager is a warm hearted polymath spanning all relevant areas of a business, it may end up feeling impossible to hire a particular candidate. This is where the team element of product becomes important. Candidates will always sit somewhere on multiple axises of the various relevant skills and experience. By making sure common sense and kindness are present across the board, it means you can hire individuals whose skills will make them valuable, and as a team cover off all of the aspects of the product spectrum. If you are hiring a first product manager, then it’s really important to remember that compromise will always be present to a certain degree.