01
Start with the work, not the job title
Ten names can feel like a finished search. But if the hiring manager cannot explain why those people are on the list, the shortlist is still a search result. A useful review tests both the reasoning for each person and the shape of the group.
First write three to five criteria describing the work to be done. Separate requirements from preferences you would trade away. Imagine a fictional B2B software company hiring a senior product designer. The team needs someone who can simplify a complex product, work closely with engineering, and learn from customers. A previous Senior Product Designer title may be useful context; it does not prove those abilities.
- Simplifying complex workflows: look for a described problem, design decision, and outcome; a polished portfolio alone does not prove impact.
- Working across product and engineering: look for specific decisions made with partners; a well-known employer is not the evidence.
- Learning from customers: look for research or feedback shaping a decision; a 'user-centred' headline is only a claim.
02
Review each candidate with four fields
A compact record can make the next decision visible without assigning a mysterious fit score. Use four fields for every person: criterion, evidence, unknown, and next action.
Criterion names the agreed requirement that makes the person relevant. Evidence records what you observed and where, before you interpret it. Unknown states what the available information cannot answer. Next action says whether to contact, ask a question, research further, save for a later pass, or remove the person from this shortlist—and who owns that step.
For the fictional design role: Criterion—simplifying a complex B2B workflow. Evidence—a portfolio case study describes redesigning an analytics setup flow and explains design decisions. Unknown—the study does not show how success was measured or which decisions the person owned. Next action—if other constraints fit, invite a conversation and ask how the team evaluated the redesign.
The note does not declare the person qualified. It makes the reason for an approach explicit and identifies the next question. Another reviewer can agree, disagree, or suggest a better test.
03
Inspect the cohort as well as its members
A shortlist can contain ten plausible people and still be weak if they all test the same assumption. For the design role, one search hypothesis might be designers from vertical software companies. Another might be designers who made complicated internal tools usable for customers. If both relate to the work, label and compare them deliberately. Different backgrounds still need a reason tied to the role.
Scan the strongest claims on the list. Are words such as 'strategic', 'high ownership', and 'great communicator' observations, interpretations, or hopes? Replace vague praise with a project, decision, or question. If the evidence is absent, mark the point unknown rather than turning missing public information into a negative judgment.
Finally, expose the trade-offs. One person may know the domain but show little public evidence of leading a project. Another may have led similar work in a different industry. The shortlist should put that choice in front of the hiring manager instead of quietly ranking one type higher.
- Does the cohort test more than one plausible interpretation of the role?
- Which claims are observed, and which remain uncertain?
- Which trade-off would the team accept, and why?
- Does every person have an owner and a next action?
04
Run a short decision meeting
A first-pass review can fit into four steps. First, check whether seeing real profiles changed the role criteria. Second, identify people with direct evidence against priority criteria. Third, name what is missing across the cohort: perhaps a search hypothesis, role clarification, or question for an interview. Fourth, decide what happens to each person and assign an owner.
If the team cannot decide on the last step, the search may need more calibration. That is useful information to surface before sending messages with a role story the team cannot yet explain. Record the changed brief as well as the resulting names, so the next pass does not restart the same debate.
05
Make the next conversation more useful
At the end of review, a colleague should be able to answer: why these people, why now, what evidence supports an approach, what remains uncertain, and what happens next. The list may change after the first conversations. A good review makes that learning visible instead of treating the first shortlist as a final verdict.
Speiros is designed to carry role and company context through search, selection, outreach, questions, and follow-ups under the supervision you choose. Your team still owns the human conversation and hiring decision. The practical test of any sourcing workflow is whether it leaves the next person with an explanation they can use.