How to hire a product manager

The problem with the roadmap as evidence

Almost every product manager interview runs on the same artefact: here's what I shipped, here's the impact. That's the wrong evidence, and the reason has nothing to do with candour.

A roadmap is the output of decisions taken by a group. It can't tell you which items this person argued for, which they argued against and lost, which they killed, or whether a founder with a spreadsheet handed them the whole thing. Two people with identical roadmaps can have had opposite jobs.

The mistake is expensive, too. On paper, a product manager who administrates a roadmap well looks exactly like one who decides what goes on it.

1. Do they interrogate the request, or write the ticket?

Requests arrive as solutions, and they arrive from people with authority. 'Sales lost three deals this quarter because we don't have SSO. Put it in the next sprint.' The whole job is contained in what happens next.

Give them that request with one piece of data attached that doesn't support it: churn concentrated somewhere else, say, or the three deals coming from one segment you don't serve. A weak candidate schedules the work. A strong one asks which deals, whether SSO was the reason or the reason given, and what else those three had in common.

You're testing whether they notice there's a question, more than whether they say no.

2. How do they size something with incomplete data?

Ask them to estimate the value of a feature they know nothing about, out loud, with no time to prepare. The estimate doesn't matter; the structure does.

Strong answers name the two or three quantities that decide it, say which one they'd go and find first, and give a range with the assumption attached.

Weak answers either produce a confident number with no derivation, or refuse to estimate until they have more data. That sounds rigorous, but in a product role it's a way of not deciding.

3. What do they say no to, and how?

Saying no is the part of the job that leaves no artefact. Nothing that was killed appears on a roadmap, so it's invisible in every conventional interview.

Put them in front of a stakeholder who has already decided the answer and won't move, and ask them to write the reply. They can fail by capitulating or by digging in. Doing it well means reframing towards what that person actually needs and proposing a cheap way to settle it with evidence.

Watch for whether the no comes with a path. 'We're not doing that' is a position. 'We're not doing that this quarter, and here's what would change my mind' is a decision.

4. What goes first when the deadline halves?

Halve the time mid-conversation and watch what they cut.

The instinct to watch for is scope versus quality. Junior product managers cut quality (ship it rougher, fix it later) because scope feels like a promise they made. Senior ones cut scope: they remove whole use cases, name what's being given up, and protect one flow end to end so the result is still measurable.

What they say matters as much as what they choose. Someone who cuts silently will surprise you later, and by then it's a trust problem rather than a planning one.

5. Which number, and by how much?

Ask which single metric they'd move and by how much.

A product manager who names one metric with a magnitude is thinking about outcomes and has accepted that they can be wrong. One who lists six is describing a dashboard, and one who says 'it depends what the business needs' has answered a different question.

Follow up with: what would you expect to get worse? Every change trades something, and someone who has run a product knows what theirs traded.

What about domain knowledge?

Assess it briefly and separately. Fifteen minutes on your market tells you whether the floor is met, and it's the easiest attribute to verify.

It's also the one that changes fastest. Product managers fail because they build the wrong thing well, or because they can't hold a position with an executive. Taking a quarter to learn a market is rarely why.

Frequently asked

How do you evaluate a product manager without a technical background yourself?

Everything above is legible to anyone who has shipped a product. Whether they question a request, what they cut, whether they can name what would change their mind: none of it requires you to assess architecture. The one part you can't judge is technical feasibility, and for that you borrow twenty minutes of an engineer's time.

Is a take-home product case worth running?

Only if you change what it asks. A case that rewards a produced artefact (a deck, a spec, a roadmap) now measures tool access and available time. One where the constraint changes partway through and the reasoning has to be defended live still works, because none of that can be prepared in advance.

What is the difference between a senior and a mid-level product manager?

What happens when the plan breaks. Years on the CV tell you little. Rule out their obvious answer and see whether there's a second one. Seniority shows up as scope decisions made out loud, with what's being sacrificed and why, more than as a longer résumé or a bigger roadmap.

Should product managers be assessed on shipping speed?

Not on its own. Speed belongs to the system they were in as much as to them: a product manager in a team with two engineers and no design partner ships slowly and may be excellent. Judgment travels between companies. Velocity mostly doesn't.