The best way to interview Product Managers

I've run a lot of PM and product design interviews. Most optimise for hypotheticals: “What would you build?” or “How would you approach X?”

They test theory in a frictionless world. Real product work isn't frictionless. It's messy. Constrained. Political. Full of trade-offs something that becomes clear when you study how product development roles and responsibilities actually break down across a team.

The strongest signal I've found is simpler.

The Task

Ask the candidate to complete a short take-home: Write a one-page summary of a real problem you personally solved.

Constraints:

• One real problem they worked on
• One page
• One hour
• Any format
• Must be readable

No template, fake case study or prescribed sections.

Why This Works

One page and one hour force prioritisation. Candidates must reveal:

• Which problem they choose
• How they frame it
• What they believe matters
• What they personally owned
• How they structure thinking under constraint

What they include (and omit) is part of the signal. Live interviews favour confidence and fluency. One-pagers favour clarity and judgment. Quieter PMs often outperform here.

What Strong One-Pagers Contain

Across levels, strong submissions tend to include:

• Clear context
• Sharp problem framing
• Explicit ownership (“I did”, not “we aligned”)
• Options considered
• Trade-offs made
• Decisions taken
• Outcomes (with numbers where possible)
• Learnings
• Clean structure
• Easy scanning

They feel intentional.

Common Weak Patterns

Red flags show up quickly:

• Over-indexing on process
• “We aligned with stakeholders”
• “We spoke to customers”
• “The team decided…”

Process isn't bad. Using it to avoid decisions is.

Other weak patterns. You can spot this in minutes.

• No clear problem statement
• Vague ownership
• No measurable outcome
• No trade-offs
• No connection to strategy
• Dense wall of text
• Buzzwords over substance

How the Interview Runs After

The one-pager becomes the main point. There is no need for hypotheticals.

• Why this problem?
• How was it discovered?
• What was at stake?
• What options did you reject?
• What constraints mattered?
• What trade-offs did you accept?
• What would you change?
• Did it actually move the needle?

It becomes obvious:

• What they owned
• What they influenced
• What they observed

Because it's grounded in real work, it's hard to fake.

Adjusting for Level

The method stays constant. Expectations change.

• Junior PM: Execution clarity. Delivery ownership. Learning velocity
• Mid-level PM: Discovery rigor, Trade-offs, Cross-functional leadership
• Senior / Lead PM: Strategic framing, Leverage, Commercial outcomes, Organisational influence

Why Writing Works

Writing is part of the job. PMs spend their time explaining decisions, aligning stakeholders, shaping narratives, making trade-offs visible and creating clarity in ambiguity.

If someone can't clearly explain work they owned on one page, they'll struggle to lead it across an organisation.

Why It Respects Everyone's Time

No multi-day take-homes, artificial case studies or marathon loops. Just Show me something real you've already done. It minimises effort. It maximises signal.

And in my experience, it gets you closer to the right hire, faster.

Check out "How to Interview a Product Manager" Cheat Sheet