How to Hire a Product Manager: Brief, Scorecard and Interviews
A practical guide to hiring a product manager: defining the role and level, writing the brief, a scorecard, an interview loop with a product case, references and the first 90 days.
To hire a product manager well, decide what the role must achieve in its first year, then pick the type and level that fits. Write a brief and scorecard first. Run a structured interview loop with a product case built from your own problems, check references deeply and plan the first 90 days before the offer goes out.
Most searches skip at least two of those steps, and end with a panel that disagrees about what good looks like. This guide walks through each step the way we run them with hiring managers.
Start with the outcome, not the job description
Before you think about candidates, answer one question: what will be different in twelve months if this hire goes well? Write the answer in two or three sentences. "Activation for new accounts improves and the onboarding roadmap is owned by one person" is useful. "Drive product excellence" is not.
That outcome shows whether you need someone to discover a new problem space, optimise a working funnel or bring order to a shared platform. It also shows what the PM will not own.
Pick the level honestly
Level is about scope and ambiguity, not years of experience.
- Product manager: owns a clearly defined product area, works with one engineering team and turns goals into a roadmap.
- Senior product manager: owns a larger or messier area, sets goals with leadership and handles trade-offs across teams without escalating every decision.
- Group PM or head of product: sets product direction, manages other PMs and works with the leadership team on strategy and planning.
A common mistake is hiring a head of product when the company needs a senior PM who will sit with engineers every day, or the reverse.
Product manager types: growth, platform and AI or data
The same title covers very different work, and the type of PM shapes what you test for.
| PM type | What the work looks like | What to test for |
|---|---|---|
| Growth PM | Funnels, activation, retention, pricing pages, many small experiments | Experiment design, reading data honestly, speed of iteration |
| Core product PM | Features for a defined user, discovery and delivery end to end | User research, prioritisation, working with design and engineering |
| Platform or technical PM | APIs, internal platforms, developer tools, shared services | Technical depth, thinking about internal customers, managing dependencies |
| AI or data PM | AI features, models, data products, evaluation and quality | Defining success for uncertain outputs, evaluation sets, data quality, explaining risk |
AI product roles deserve a note. A PM for an AI feature has to define what "good" means when outputs vary, work with engineers on evaluation sets and decide when a model is ready for users. If you are building agents or copilots, our guide to building enterprise AI agents for production covers the delivery side these PMs will live in.
Write a one-page role brief
The brief is what you, the hiring manager and the panel agree on before the search starts. Keep it to one page:
- The outcome: what the role must achieve in year one.
- The product area: users, current state, key metrics and the team the PM will work with.
- Level and reporting line: who they report to and who, if anyone, reports to them.
- Must haves: three or four capabilities the person cannot succeed without.
- Nice to haves: things that help but should not decide the hire.
- What the role is not: for example, not a project manager, not owner of the design team.
- Interview plan and decision maker: who interviews, what each person tests and who makes the final call.
The "what the role is not" line stops candidates being rejected for skills the job never needed.
Build a scorecard before the first interview
A scorecard turns the brief into criteria every interviewer uses. Each criterion has a short description of strong evidence and a single owner on the panel, so nobody tests the same thing twice and nothing goes untested.
Here is a scorecard we would start from for a senior PM. Adjust it to your role.
| Criterion | Strong evidence looks like | Tested in |
|---|---|---|
| Problem framing | Clarifies the user, the goal and the constraint before proposing solutions | Product case |
| Prioritisation | Makes a clear call, explains what was dropped and why | Product case, hiring manager interview |
| Use of data | Picks sensible metrics, admits what the data cannot show | Analytics or data interview |
| Working with engineering | Can describe technical trade-offs they made with engineers, in specifics | Engineering lead interview |
| User understanding | Talks about real conversations with users and what changed as a result | Hiring manager interview |
| Communication | Writes and speaks clearly, adapts to the audience | Written exercise, all interviews |
| Ownership | Describes outcomes they were accountable for, including failures | References, hiring manager interview |
Rate each criterion on a simple scale, note the evidence and submit feedback before the panel meets, so the loudest voice in the debrief does not set everyone's view.
Run a structured interview loop with a product case
A good loop is short, consistent and tied to the scorecard. Four or five conversations is usually enough.
- Screening conversation: motivation, career story, a first check on the must haves.
- Hiring manager interview: past work in depth. Pick two projects and go several layers down: what was the problem, what did they decide, what happened, what would they change.
- Product case: the centre of the loop (more below).
- Engineering and design interviews: how the candidate works with the people who build the product.
- Leadership or values conversation: for senior roles, how they handle disagreement and set direction.
Designing the product case
Generic cases test how well someone has practised generic cases. Build yours from a real problem in your product, simplified and with confidential details removed.
Give the candidate a short brief, some realistic data and a clear question, such as "activation fell for one segment last quarter; what would you investigate first?" Then discuss it live. Watch how they frame the problem, what they ask, how they choose and whether they update their view on new information.
Keep take-home work short. Strong candidates drop out of processes that ask for a weekend of unpaid work.
Red flags to watch for
None of these is decisive on its own, but each deserves a follow-up question.
- Frameworks without substance. Fluent with prioritisation models but vague about any real decision they made.
- "We" with no "I". Credit for team results without being able to say what they personally did.
- No user contact. Cannot describe a recent conversation with a user or what they learnt from it.
- Output, not outcomes. Talks about features shipped rather than what changed for users or the business.
- Blame. Every failed project was someone else's fault: engineering, sales, leadership.
Check references properly
References are where you test the hard claims. A five-minute call that confirms dates is not a reference check.
Speak to at least two people who worked closely with the candidate, ideally a former manager and an engineering partner. Ask for specifics: "Tell me about a decision they made that you disagreed with." "Would you hire them again, and why?" Listen for hesitation as much as praise.
Onboard for the first 90 days
The hire is not done when the offer is signed. Agree a first 90 days plan with the hiring manager before the person starts.
- First 30 days: meet users, sales, support and every engineer on the team. Learn the metrics and the history of past decisions. Ship nothing big.
- Days 30 to 60: take ownership of the roadmap for their area, run a first discovery cycle and agree goals for the next quarter.
- Days 60 to 90: deliver a first meaningful change and present what they have learnt and what they propose next.
Check in every week for the first month. Early product hires usually fail because expectations were never made explicit.
When to use a recruitment partner
If you have a strong network, a clear brief and experienced interviewers, run the search yourself. A partner earns its place when the role is senior or specialised (an AI product lead, a head of product), when nobody on your side has hired for it before, or when the people you want are not applying. Choose one whose assessors have built and run products themselves, who will challenge your brief and who sends written notes on every candidate, not just CVs. The SaaS and technology teams we work with often need exactly this mix of product and technical judgement.
Frequently asked questions
How long does it take to hire a product manager?
A product manager search typically takes several weeks from brief to accepted offer, plus the candidate's notice period. Senior and specialist roles take longer, and an unclear brief is the most common cause of delay.
What should a product manager interview include?
A screening call, a deep conversation about past work, a product case based on your own problems and interviews with the engineering and design partners the PM will work with. Every interview should map to a criterion on the scorecard, and feedback should be written before the panel meets.
What is a good product case for a PM interview?
A simplified version of a real problem from your product, with some data and a clear question. It should take an hour or so to discuss live, not a weekend. Look for how the candidate frames the problem, asks questions and makes a decision, not for a polished presentation.
Should I hire a senior PM or a head of product first?
If you need someone to own a product area and work daily with engineers, hire a strong senior PM. If you need someone to set product strategy, build a team of PMs and work with leadership on planning, hire a head of product. Writing down the year one outcome usually makes the answer clear.
What makes an AI product manager different?
AI product managers must define success when outputs are uncertain, work with evaluation sets, understand data quality and explain risk to customers and stakeholders. Test for these directly with a case about an AI feature, rather than assuming general product experience carries over.
How Sunday Labs can help
Sunday Labs runs product manager hiring for technology companies, from senior PMs to heads of product, including PMs for AI and data products. We agree the role brief and scorecard with you upfront, and candidates are assessed by people who have built and led product and engineering teams, using structured interviews, product cases and deep references. A founder reviews every search each week. If you are planning a product hire, start a conversation.
