Hiring for product: what actually matters

Most PM hiring is broken. Companies copy generic interview processes, ask "tell me about a time when..." questions, and end up with people who can talk about product but can't actually do it.

The problem starts with not knowing what you actually need.

I've written before about the 5Ds - the idea that every PM should have an angle in Design, Development, Delivery, Domain, or Data. You don't need a unicorn. You need someone whose strengths match what your team actually lacks.

That framework should drive your hiring. Here's how.

What you probably need (and don't)

At early-stage or rebuilding companies, you typically need:

• An independent operator who can acquire domain knowledge without handholding
• Someone comfortable making bold decisions with limited information
• A person who can collaborate deeply with engineers and designers

You usually don't need:

• A pure delivery manager whose main superpower is pushing tickets around
• A domain specialist who can only execute within tight guardrails

If you're in a startup or rebuilding phase, bias toward technical, problem-oriented PMs over "project managers in disguise."

Domain vs technical expertise

Here's a controversial take: domain knowledge is nice-to-have. The ability to navigate ambiguity and ship valuable product is must-have.

Prefer:

• Strong technical/process skills (Development, Data, Delivery Ds)
• Ability to work closely with engineers
• Comfort designing experiments and metrics

Treat as optional:

• Deep domain expertise, unless your space is truly esoteric

You want someone who can learn your domain, not someone who only works when the domain is handed to them.

Rethink the interview: use workshop-based assessment

Standard PM interviews have two problems:

1. They're easy to game with rote, blog-post answers
2. They don't show what it's like to actually work with the person

A better approach: run a live workshop that simulates real collaboration.

The format

Pre-work (async): Send the candidate a concise but rich packet:

• ~10 pages of product and domain context (what you do, the problem space, key user types)
• Summaries of user interviews, maybe links to 1-1.5 hours of raw videos

Make it clear the goal isn't a polished deck - it's to prepare for a productive collaborative session.

The workshop (60-80 minutes): Give them a simple mandate:

"Run a workshop with us that ends with a clearly specified product idea: a defined problem, proposed solution, and how we'd deliver and measure it."

Structure it roughly as:

1. Problem exploration (~20 min) - Identify and prioritize user problems from the research
2. Solution ideation (~20 min) - Generate directions, narrow down, make trade-offs explicit
3. Delivery & metrics (~20 min) - Scope, sequencing, success metrics, unknowns

What the workshop actually tests

The value isn't the "correct answer." It's how they work.

Ability to structure ambiguity

Strong candidates:

• Propose a structure for the session upfront
• Reframe messy input into coherent problem statements
• Bring metrics into the conversation naturally

Weak signals:

• Dive straight into UI ideas or feature lists
• Ignore or under-specify what success looks like
• Struggle to prioritize competing problems

Product thinking vs textbook recitation

You want candidates who think in product terms - users, constraints, trade-offs, sequencing, feedback loops. Not people who repeat frameworks without grounding them in your context.

Look for:

• How they make trade-offs ("Given our constraints, I'd drop X to ship Y earlier")
• How they incorporate real user data
• Whether they turn vague goals into actionable plans

Collaboration

A PM's job is often to get the best from others, not broadcast their own brilliance.

Positive signs:

• They ask good, targeted questions
• They invite you into the thinking
• They can both lead and listen

Negative signs:

• They bulldoze the conversation
• They get defensive when challenged
• They can't adjust when new information appears

Comfort with incomplete information

Look for someone who:

• Can move forward without perfect data
• Knows which decisions are reversible vs require alignment
• Can articulate "what we know vs what we'd need to validate"

If they freeze without exhaustive data, they're a poor fit for fast-moving environments.

The PM profile that works well

From experience, effective product teams often have:

• A PM with a technical or engineering background (strong in the Development D)
• Engineering-minded collaborators
• Engineers treated as co-creators, not ticket-takers

This combination moves faster, handles re-architecture better, and makes more grounded trade-offs.

No dedicated delivery manager required

In this model, the JIRA board is an engineering artifact. Engineers own its accuracy. There's no separate role whose main job is pushing tickets around.

Delivery emerges from:

• Clear goals and constraints (set with the PM)
• Collaborative planning
• Engineers owning their workflow

Screening before the workshop

Don't make the workshop the first gate. Pre-filter with:

1. Talent screen - Basic alignment on experience, salary, location
2. Hiring manager conversation (~45 min) - Explore their philosophy of product, how they collaborate
3. Async work samples - Portfolios, write-ups, shipped products

Quick filter: Would anyone actually want to use the things they've shipped?

Cultural fit with engineering

After the workshop, ensure the PM and engineers can actually work together. Arrange mutual fit conversations focusing on:

• How they handle disagreement
• How they talk about constraints
• Whether they see engineering as partners or an execution function

If engineers don't feel they can trust the PM, that's a serious red flag.

Putting it together

When hiring for product:

1. Clarify your stage-specific needs - Which of the 5Ds do you actually need depth in?
2. Design a workshop reflecting real work - Use your real user interviews and product context
3. Define "good" upfront - Structure, collaboration, product thinking, comfort with ambiguity
4. Align your team - Everyone should understand why you're prioritizing product thinking over delivery admin

This won't give you perfect certainty. But it will show you how candidates actually think and collaborate under realistic constraints - which is far more predictive than another round of behavioural questions.