Hiring your first PM: the 18-question grid

The first PM hire in an organisation is usually the riskiest one. Not because the candidates are bad — but because the organisation doesn't know exactly what it is looking for, and nobody inside is genuinely qualified to assess the person in front of them.

The classic outcome: you hire a "project manager" and call them a PM. Or a senior PM out of a big tech company who can't function without a structured team around them. Or a very technical profile who confuses the backlog with the sprint backlog, and spends their days writing tickets instead of talking to users.

Six months later, everyone is disappointed. And nobody really understands why.

What you are actually looking for

Before the questions, you have to be honest about what the role demands in your specific context. A first PM in a 15-person startup is not the same profile as a PM in an 80-person scale-up.

In a small organisation, your first PM has to be able to:

Operate in the fog with no established processes, no mature tooling stack, and often no reliable data
Move things forward without formal authority — the devs don't report to them, and the final calls usually belong to the founders
Ship fast — not in 6 months with a perfect roadmap, but in 4 weeks with a reduced scope and trade-offs they own
Learn from users directly — not through commissioned market research, but by picking up the phone

That profile is rare. And it doesn't always look like the PM big tech trains.

What you are not looking for

Let's be blunt about the wrong tracks:

An MBA with a beautiful deck on product strategy and no delivery experience at all
A "certified PM" whose only certification came out of a 2-day course
Someone who has never said no to a stakeholder, and can't explain how they would
Someone who confuses "having an opinion about the product" with "doing product management"
A candidate who can't name one hard decision they made, and what it actually cost

The grid: 6 dimensions × 3 questions

Here are the 18 questions I use, organised by dimension. Each dimension tests one critical skill. For every question, I'm looking for answers anchored in real experience — not theoretical frameworks.

Product thinking

Tell me about a time you discovered your users wanted something other than what they were asking you for. How did you find out, and what did you do?
How do you decide that a problem deserves to be solved by the product rather than by a process or some training?
Which product do you admire most right now, and why does it solve its problem well?

Prioritisation

Tell me about a time you said no to a request from an important stakeholder. How did you phrase it, and how did they react?
How do you run a backlog when everyone claims their request is urgent and top priority?
Give me an example of a feature you decided not to build, and walk me through the reasoning.

Stakeholder management

Tell me about a situation where you disagreed with your management on a product decision. How did you handle it?
How do you make sure Engineering and Design are moving in the same direction without spending your life in meetings?
You have a stakeholder who systematically goes around the prioritisation process. What do you do?

Data & measurement

How do you decide you have enough data to make a decision, and that you don't need to collect more?
Tell me about a time the data said one thing and your instinct said another. What did you do?
What was the most important metric you tracked in your last role, and why did you pick that one?

Delivery

Tell me about the last project you delivered late. What was the root cause, and what would you have done differently?
How do you define "done" for a feature? What has to be true before you can say it has shipped?
You are at the end of a sprint and it becomes clear the sprint goal won't be met. What do you do, in what order, and with whom?

Team & trust

How do you build trust with a team of developers who see you arriving as "the person who is going to create bureaucracy"?
Tell me about a time you made a bad decision that hit your team. How did you handle it afterwards?
If I asked the developers you have worked with what they think of you, what would they tell me — the good points and the ones to improve?

The 5 red flags that rule a candidate out

Not one answer anchored in something concrete. If every answer is theoretical or generic ("generally speaking, I…"), the candidate either lacks real experience or is hiding something.
No hard decision anywhere in their history. A PM who has never said no to an important stakeholder hasn't done product management yet.
All the credit, never the mistake. If the candidate takes credit for every success but had nothing to do with any of the failures, be wary.
They talk about themselves, not about users. Ask them to describe a user of their last product. If you get a PowerPoint persona rather than a real person they have met, that's a problem.
They have no questions. A good PM is curious by nature. If they have nothing to ask you about your product, your users or your challenges, they aren't invested enough.

The 3 rare green flags that make you hire fast

They have an opinion about your product. Not a polite critique — a real point of view, built up, with examples and a logic behind it. It shows they did the work before the interview.
They tell you what they can't do. Being aware of your own limits is a sign of maturity. A candidate who claims to have mastered everything is an alarm bell.
They challenged one of your assumptions. Not aggressively, but with curiosity and rigour. That is exactly what you want on your team.

The first 90 days of onboarding

Hiring is half the work. The other half is onboarding. Most first-PM failures don't happen because of the wrong candidate — they happen because of an onboarding that leaves them alone in front of an organisation they don't understand yet.

The first 30 days: observe. The next 30: propose. The last 30: deliver a first measurable result.

That rhythm is not a magic formula. It is a signal sent to the organisation: give them time to understand before demanding results. A PM who ships too fast at the start usually ships the wrong thing.

What kills first PMs during onboarding:

Being handed a roadmap to hold from week 2, without having spoken to a single user
Having no access to the data, or having to go through 3 people to get one number
Having no clear sponsor in the leadership — someone who shields them while they learn
Being judged on short-term productivity when their real job is building a deep understanding of the product and its users

If you are hiring a first PM, ask yourself these questions

Do you have a clearly designated leadership sponsor? Do you have a minimal, working level of access to your data? Are the founders ready to let go of product decisions? If all three answers aren't "yes", the PM is going to suffer — whatever their level.

Hiring your first PM is a decision that will shape your organisation's product culture for years to come. Take the time to do it properly. The 18 questions above don't guarantee the right choice — they improve your odds of not making the wrong one.

And if you aren't sure you can judge the answers: get some help. This is exactly the kind of situation where an hour with someone who has hired PMs can save you 6 months of getting it wrong.

Also worth reading — The art of saying no to a feature request: the very skill these 18 questions are trying to detect, broken down into a method.