Hire a product manager who fits your team
Fifteen minutes of real work situations, with no right or wrong answers. You see how each product manager separates a request from a problem, prioritises and handles a stakeholder who has already decided, next to how your team works.
What you can’t see when you hire a product manager
A CV lists shipped features. It never shows which ones they argued against, what they killed, or whether the roadmap was theirs or handed to them.
The case starts with a request
Every case opens with a request that already contains its own answer, because that’s how requests arrive at work. What we measure starts with whether they notice.
The CRO: “Sales lost three deals this quarter because we don't have SSO. Put it in the next sprint.”
What this case shows you
- Whether they interrogate the request or write the ticket
- How they size an opportunity with incomplete data
- What they say no to, and how they say it
- How they react when the deadline halves
- Which single metric they would move, and by how much
Situations a product manager runs into
Twelve short situations like this one, drawn from the day-to-day work of the role. The live ones are confidential, because an assessment you can rehearse stops measuring anything.
Example situation
The CRO tells you sales lost three enterprise deals this quarter for the lack of SSO, and wants it in the next sprint. Engineering estimates six weeks, which is the whole sprint and half the next.
A recommendation for your product manager role
You mark what this job can’t do without. The report opens with a clear call for it, shows where the candidate stands on each capability you chose, and gives you three questions for the interview.
Marta R. · Product Manager
Leads with both of the things you named
Of what you named, reaches first for knows what the data supports. The distance here is not capability, it is how your team works.
Why these matter for a product manager
- Knows what the data supports
- And what it doesn't. A PM who takes 'three deals lost to SSO' at face value will spend the year building whatever the last loud conversation was about.
- Knows what is cheap to build
- Here it's a prioritisation skill more than an engineering one. A PM who can't tell a two-day change from a two-quarter one ends up with a wish list instead of trade-offs.
- Explains decisions outside the team
- To sales, to support, to a founder. Most of a PM's leverage is spent telling people why the thing they asked for isn't happening, in a way that keeps them.
What each format sees, and what it misses
| Format | What it shows you | What it misses |
|---|---|---|
| CV and shipped-product review | Scope, sector and the size of team they've worked in. Useful for filtering. | Attribution. A shipped feature has ten people's fingerprints on it, and the CV never says whether this person set the direction, argued against it and lost, or wrote the ticket somebody else decided. |
| Case study interview | How they structure a problem out loud, and whether they can think with someone watching. | Whether the structure is their own or rehearsed. The formats are public, the frameworks are memorised, and there's a small industry teaching people to perform this one hour. It also measures composure under interview pressure, which isn't the pressure of the job. |
| Product sense interview | Instinct, curiosity, and how they reason about users in the abstract. | A comparable answer. 'How would you improve Spotify' gets a different follow-up from every interviewer, so the transcript can't be lined up against another candidate's. |
| This assessment | How they separate a request from a problem, what they refuse and what they trade away. Twelve situations every candidate answers identically, read against the capabilities you named as essential. | Domain depth. It won't tell you whether they understand your market. That's what your own interview is for, and the report ends with three questions to spend it on. |
From open role to shortlist
Choose the role, what it should lead with and how your team works. It takes about ninety seconds.
Send it to each candidate or paste it in your job ad. There’s nothing to install and nothing to schedule.
Short, varied situations from the day-to-day of the role. No right or wrong answers, about fifteen minutes, on any device.
The report is ready when they finish: how close each person is to your profile, and questions for the interview.
New link
Other product roles
One credit per candidate, spent only when they start. The first is free (see what the packs cost), and nothing expires.
Assessing product managers, in practice
It's comparable: every candidate answers the same twelve situations, so the shortlist lines up side by side instead of being six impressions. It's also much harder to rehearse, because there's no framework to recite and no case study to polish.
Decision-making, which sits under both. The situations put a request, a constraint and a stakeholder in front of the candidate and measure what they do: whether they question the request, what they cut when the timeline halves and what they refuse.
About fifteen minutes, on any device, whenever suits them. Nothing to install, nothing to schedule, and the report reaches you the moment they finish.
They can try, and it helps them very little. There's nothing to write or polish, and a model can't know what this particular person would do. Read past the headline.
No. You describe what the role can't do without first, and the report is read against that. From one sitting, the same PM can fit a founder's first product hire and not a large platform team, or the other way round.
One credit per candidate, spent only when they start. The first is free with no card, and credits don't expire.
Read these before you decide
8 min read
How to evaluate a frontend engineer beyond the coding test
A coding test answers whether someone can build it. It doesn't answer whether they should have. That comes down to whether they spot the states a design forgot, how they respond to a spec that breaks at scale, what they cut when the date moves, and whether they name the risk they're shipping with. Those decisions make a frontend hire expensive or excellent, and none of them appear in an algorithm exercise.
Read it8 min read
How to evaluate a design engineer
Evaluate a design engineer on the decisions nobody logs: when a component should be new, a variant, or shouldn't exist at all; how they trade system consistency against shipping this week; what they do with a design that ignores the system; and which debt they choose to take on. A GitHub profile shows what they merged. Most of this role's value sits in what never got built.
Read it10 min read
How to evaluate a UX writer
Evaluate a UX writer on whether they fix the interface or just the sentence: whether they flag the broken flow behind a confusing message, how they handle a destructive action, what they do with a legal constraint they can't remove, and how they decide what not to say. A writing sample shows the final line. It never shows what the screen looked like before, or what they refused to paper over.
Read it
Hiring a product manager right now?
Invite one candidate and read their report the moment they finish. The first one is free, with no card.