by KEN NORTON
It's been a while since I was hiring at a
startup, and recruiting at a startup is very
different from hiring at a big company. At
Yahoo! Search, it seemed like we were
constantly hiring. I did an average of 5-8
interviews a week. It was a never-ending
drumbeat of resumes, interviews, and offer
letters. Now, I wasn't always the hiring
manager. I only hired a handful of product
managers in my time there. But somebody
was always hiring a product manager and I
was usually on the interview team. The first
thing you notice at a big company is the
amount of specialization. At a startup,
everyone does a little of everything, so you
need strong generalists. More importantly,
it's hard to predict the future, so you need
people who can adapt. You might think
you're hiring somebody to work on
something specific, but that something
might change in a few months. It doesn't
work that way at big companies. Usually
when you're hiring you have avery specific
role in mind, and the likelihood that that
responsibility will change is low. Lots of
people were hired at Yahoo! that probably
wouldn't have been appropriate at a startup.
I recall a lot of post-interview conversations
that went something like this - "well, I'm not
sure they're the perfect candidate, but they
do seem suited for this very specific role, so
let's hire them." That may work fine at a big
company, but it's deadly thinking at a
startup.
I started my career as an engineer and
advanced pretty quickly into engineering
management. During the bubble, I probably
hired over one hundred engineers. I learned
a lot about hiring, mostly by making
mistakes. When I transitioned to product
management I was able to apply some of my
experience hiring technical people, but I also
learned a whole new set of lessons. Last
week a friend called to say he needed to hire
a product manager and wanted my advice. I
realized there's not a lot of good information
out there about interviewing PMs (there's not
a lot of good information about product
management in general). More to the point,
there's not a lot about what you should look
for in a product manager no matter what kind
of environment you're in - startup or big
company. So I thought I'd pull together
some of what I learned.
Remember friend, nobody asked
you to show up
Product management may be the one job
that the organization would get along fine
without (at least for a good while). Without
engineers, nothing would get built. Without
sales people, nothing is sold. Without
designers, the product looks like crap. But in
a world without PMs, everyone simply fills in
the gap and goes on with their lives. It's
important to remember that - as a PM, you're
expendable. Now, in the long run great
product management usually makes the
difference between winning and losing, but
you have to prove it. Product management
also combines elements of lots of other
specialties - engineering, design, marketing,
sales, business development. Product
management is a weird discipline full of
oddballs and rejects that never quite fit in
anywhere else. For my part, I loved the
technical challenges of engineering but
despised the coding. I liked solving
problems, but I hated having other people
tell me what to do. I wanted to be a part of
the strategic decisions, I wanted to own the
product. Marketing appealed to my creativity,
but I knew I'd dislike being too far away from
the technology. Engineers respected me, but
knew my heart was elsewhere and generally
thought I was too "marketing-ish." People
like me naturally gravitate to product
management.
1. Hire all the smart people
So what do I look for in a PM? Most
importantly, raw intellectual horsepower. I'll
take a wickedly smart, inexperienced PM
over one of average intellect and years of
experience any day. Product management is
fundamentally about thinking on your feet,
staying one step ahead of your competitors,
and being able to project yourself into the
minds of your colleagues and your
customers. I usually ask an interview
candidate a series of analytical questions to
gauge intelligence and problem-solving
ability. Generally I'll ask questions until I'm
sure the candidate is smarter than me. For
some reason, lots of people I know are
reluctant to do that. They argue that it's
insulting to the candidate. I think the right
candidate will relish the challenge. In fact,
that's the first test - how do they react when
I say "I'd like to pose some theoretical
problems, is that okay?" The best of the
bunch are usually bouncing out of their
chairs with excitement. The super smart
sometimes counter with questions of their
own.
2. Strong technical background
Some managers I've known insist on hiring
only PMs with computer science degrees.
I'm not as snobby - maybe it's my own
liberal arts undergraduate education - but I
do tend to favor people who've been in
technical roles. Having a solid engineering
background gives a PM two critical tools -
the ability to relate to engineers and a grasp
of the technical details driving the product. It
depends on the product of course - a PM
working on low-level developer APIs is
bound to need more technical chops than
one working on the front-end of a personals
web site. But the basic principle applies -
product managers with technical
backgrounds will have more success
conveying product requirements to
engineers and relaying complicated details
to non-technical colleagues and customers.
That said, there are pitfalls you need to
avoid. Most importantly, a PM who's a former
engineer needs to realize that he or she is
just that - a former engineer. PMs who come
from engineering and still try to take charge
of technical decisions and implementation
details will crash spectacularly. For that
reason, I like hiring technical people who've
already made the move to product
management at a previous job. They've
already gone through the challenging
adaptation period and by checking
references you can get a feel for how well
they've evolved. I won't bore with you with
interview questions to evaluate technical
competency. They depend on the skill set
and there are hundreds of web sites that
give good tips for hiring engineers. Instead,
here are some good questions for gauging
how well a technical PM has adapted to the
role and their ability to work with engineers:
Why did you decide to move from
engineering to product management?
What is the biggest advantage of having a
technical background?
What is the biggest disadvantage ?
What was the biggest lesson you learned
when you moved from engineering to
product management?
What do you wish you'd known when you
were an engineer?
How do you earn the respect of the
engineering team?
3. "Spidey-sense" product instincts
and creativity
This next category is highly subjective,
difficult to evaluate, and extraordinarily
important. I am a strong believer that certain
people are born with innate product
instincts. These people just know what
makes a great product. They're not always
right, but their instincts usually point in the
right direction. They tend to be passionate
advocates of a point of view, sometimes to
the chagrin of their colleagues. I've had the
good fortune to work with a good number of
these people, and it's an essential trait in
product managers. And it can be tuned, but
it can't be learned. Product management,
especially in highly dynamic environments
like the web, involves lots of small
decisions. Sure, there's a lot of big thinking
and strategy. But it's the little decisions
where a great PM distances him or herself
from a decent one. You know they've got the
"spidey-sense" product instinct when they
suggest approaches that nobody on the
team has thought of, but immediately strike
everyone as obvious when they hear them.
Evaluating product instinct in an interview is
challenging at best. But it can be done. One
thing I always do is check to see if the
candidate has accomplished the following
tasks during a one-hour interview:
Independently echoed some of my own
concerns about my product - if you're a
good PM, you've got a bunch of things
that worry you about your own product.
Maybe they're UI shortcomings, missing
features, or architecture flaws that need to
be addressed. They're things you know
need to be fixed. At least some of these
should be obvious to an intelligent
outsider with strong product instincts. I
look for that moment in the interview
when I smile, nod, and say "yeah, I know -
that's been driving us crazy too."
Taught me something new about my
product - it could be an obvious
improvement that I'd never considered, a
new idea for positioning against a
competitor, or a problem they encountered
that needs to be addressed. When I learn
something from a candidate, I know two
things: (1) they're not afraid to speak
critically, and (2) they're probably smarter
than me. I want both in a product
manager.
Turned me on to something new and
interesting - people with great product
instincts tend to notice great products
before everyone else. If I'm interviewing a
top-notch candidate, I usually walk away
having discovered something new and
innovative.
Here are some good questions for judging
product instincts:
Tell me about a great product you've
encountered recently. Why do you like it?
[By the way, it drives me crazy when
candidates name one of my products in
an interview. I had a hard time hiring
anybody at Yahoo! who told me the
coolest product they'd come across
recently was Yahoo! Good grief.]
What's made [insert product here]
successful? [I usually pick a popular
product, like the iPod or eBay, that's won
over consumers handily in a crowded
market.]
What do you dislike about my product?
How would you improve it?
What problems are we going to encounter
in a year? Two years? Ten years?
How do you know a product is well
designed?
What's one of the best ideas you've ever
had?
What is one of the worst?
How do you know when to cut corners to
get a product out the door?
What lessons have you learned about user
interface design?
How do you decide what not to build?
What was your biggest product mistake?
What aspects of product management do
you find the least interesting and why?
Do you consider yourself creative?
4. Leadership that's earned
Product managers are usually leaders in
their organizations. But they typically don't
have direct line authority over others. That
means they earn their authority and lead by
influence. Leadership and interpersonal
skills are critical for product management.
There are a thousand books about
leadership, so I won't turn this post into a
treatise on the subject (most of the books
are crap anyway). I find reference checks to
be the most effective way to measure
leadership skills, especially references that
involve peers and individual contributors
who worked with - but did not report to - the
candidate. But here are a few questions I've
used in the past:
Is consensus always a good thing?
What's the difference between
management and leadership?
What kinds of people do you like to work
with?
What types of people have you found it
difficult to work with?
Tell me about a time when a team didn't
gel. Why do you think that happened, and
what have you learned?
How do you get a team to commit to a
schedule?
What would somebody do to lose your
confidence?
Do you manage people from different
functions differently? If so, how?
What have you learned about saying no?
Who has the ultimate accountability for
shipping a product?
Have you ever been in a situation where
your team has let you down and you've
had to take the blame?
How has your tolerance for mistakes
changed over the years?
Which do you like first, the good news or
the bad news?
What's your approach to hiring?
5. Ability to channel multiple
points-of-view
Being a product manager requires wearing
multiple hats. I often joke that much of the
time your job is to be the advocate for
whoever isn't currently in the room - the
customer, engineering, sales, executives,
marketing. That means you need to be
capable of doing other people's jobs, but
smart enough to know not to. Great PMs
know how to channel different points-of-
view. They play devil's advocate a lot. They
tend to be unsatisfied with simple answers.
In one conversation they might tell you the
requirements don't seem technically feasible
and in the next breath ask how any of this
will make sense to the salespeople. There's
one obvious way to evaluate a candidate's
ability to think through a problem from
multiple angles - gets lots of people in the
interview process. I always insist that at a
minimum, representatives from engineering,
design, and marketing meet a potential PM
candidate. Depending on the specific role,
this list can grow - pre-sales engineering,
support, developer relations, business
development, legal, or customers
themselves. Ultimately anyone who will be
working with this person should meet them.
Note that I didn't say everyone needs to
meet them. One carefully selected
representative of each key function will
suffice. And it also doesn't mean everybody
has to give a thumbs-up - it's hard to build
consensus in an interview process as the
list of interviewers grows, so consider the
feedback appropriately. But nobody will be
able to judge how well a product manager
understands the sales process like a
salesperson. I also strongly recommend that
you give specific instructions to the
interviewers, like "I'd like you to see how
well this person would understand the
issues you face in channel development, and
how well they'd support you in the field.
"Here are some specific questions that I use
(these are just examples, feel free to replace
the functional names):
How have you learned to work with sales?
What is the best way to interface with
customers?
What makes marketing tick?
How do you know when design is on the
right track?
How should a product manager support
business development?
What have you learned about managing
up?
What's the best way to work with the
executives?
6. Give me someone who's shipped
something
This last characteristic may be the easiest to
evaluate. Unless the position is very junior,
I'll usually hire product managers who've
actually shipped a product. I mean from start
to finish, concept to launch. Nothing is a
better indication of someone's ability to ship
great products than having done it before.
Past performance is an indication of future
success. Even better, it gives something
tangible to evaluate in a sea of intangibles.
When checking references, I always make
sure to talk to important colleagues from a
previous project, especially the PM's
manager and their engineering and sales or
marketing counterparts. (Incidentally, these
rules are ordered for a reason, and as I
mentioned under #1 I'll still take a brilliantly
smart PM over a dimmer experienced one
even if the former hasn't shipped before).
Note: I wrote this in 2005 when I was at
JotSpot. Google acquired JotSpot in 2006.
Since then, I've had the opportunity to work
with some marvelous PMs and have
performed 200+ PM interviews. I'm sure that
my opinions have evolved, but the
intervening years have only further reinforced
the characteristics of great PMs. I
occasionally set out to update this essay but
I always decide to leave it as is. (--Ken,
February 2013)
No comments:
Post a Comment