How to hire a product manager

The problem with the roadmap as evidence

Almost every product manager interview runs on the same artefact: here is what I shipped, here is the impact. It is the wrong evidence, and for a reason that has nothing to do with honesty.

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

And the failure mode is expensive. A product manager who administrates a roadmap well looks, on paper, 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 do not have SSO. Put it in the next sprint.' The whole job is contained in what happens next.

Give them exactly that, with one piece of data attached that does not support it — churn concentrated somewhere else, or the three deals being from one segment you do not 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 are not testing whether they say no. You are testing whether they notice there is a question.

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 does not matter; the structure does.

Strong answers name the two or three quantities that decide it, say which one they would 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 — which sounds rigorous and is, in a product role, a way of not deciding.

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

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

Put them in front of a stakeholder who has already decided the answer and will not move, and ask them to write the reply. There are two ways to fail — capitulate, or dig in — and one way to do it well: reframe towards what that person actually needs, and propose a cheap way to settle it with evidence.

Watch for whether the no comes with a path. 'We are not doing that' is a position. 'We are not doing that this quarter, and here is 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 later — because scope feels like a promise they made. Senior ones cut scope: they remove whole use cases, name what is being given up, and protect one flow end to end so the result is still measurable.

The verbal part matters as much as the choice. Someone who cuts silently will surprise you later, and by then it is a trust problem rather than a planning one.

5. Which number, and by how much?

Ask which single metric they would 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 it with: what would you expect to get worse? Every real change trades something. Someone who has run a product knows what theirs was.

What about domain knowledge?

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

It is also the one that changes fastest. Product managers fail because they build the wrong thing well, or because they cannot hold a position with an executive — not because they took a quarter to learn a market.

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 cannot judge is technical feasibility, and for that you borrow twenty minutes of an engineer rather than becoming one.

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, not years on the CV. Rule out their obvious answer and see whether there is a second one. Seniority shows up as scope decisions made out loud — what is being sacrificed and why — rather than as a longer résumé or a bigger roadmap.

Should product managers be assessed on shipping speed?

Not on its own. Speed is a property of the system they were in as much as of them — a product manager in a team with two engineers and no design partner ships slowly and may be excellent. What travels between companies is judgment; velocity mostly does not.