15 minutes, report the moment they finish
Product manager skills assessment
Twelve written situations, about fifteen minutes, that measure how a product manager separates a request from a problem, prioritises against real constraints, and handles a stakeholder who has already decided the answer.
The gap
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 here
The CRO: “Sales lost three deals this quarter because we don't have SSO. Put it in the next sprint.”
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.
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
The kind of call they make
Situations a product manager runs into
Twelve short situations like this one, drawn from the day-to-day work of the role. The live situations 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.
What you get
A recommendation for your product manager role
You mark what this particular job can’t do without. The report opens with a clear call for that job, shows where the candidate stands on each capability you chose, and gives you three questions to ask in the interview.
Marta R. · Product Manager
Leads with both of the things 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.
Against what you already do
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. |
How it works
Three steps,
with no calls and no setup
What must they be good at?
- Spots when the brief is wrong
- Knows what the data supports
- Moves without being told
- Sweats states and edge cases
One credit per candidate, spent only when they start. The first is free (see what the packs cost), and nothing expires, so a role on hold costs nothing.
Questions
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. A PM assessed for a founder's first product hire and for a large platform team gets two different recommendations from one sitting.
One credit per candidate, spent only when they start. The first is free with no card, and credits don't expire.
Related reading
Read these before you decide
8 min
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
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
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