How many must-have requirements should a role have?

What a must-have actually does

A must-have is not a preference expressed strongly. It is an instruction to reject anyone who does not have it, and most hiring briefs are written without anybody saying that part out loud. The requirement gets added in a meeting because it sounds sensible, and three weeks later the shortlist is thin and nobody can point at which line caused it.

The test is simple and worth applying literally. If a candidate is outstanding on everything else and lacks this one thing, do you want to see them? If the answer is yes, even reluctantly, it is not a must-have.

Why they compound

Requirements do not add up, they multiply. Suppose each of your hard requirements excludes three candidates in ten. One requirement leaves seventy per cent of the pool, which sounds fine. Two leave forty-nine. By five you are working with seventeen people out of every hundred you paid to find.

The damage is worse than the arithmetic suggests, because exclusions are not independent. The candidate who has the niche tool experience is often the one who lacks the domain background, and the one with both usually wants more money than the role pays. Stacking requirements selects for a profile that may not exist in your market at your budget.

The fifth requirement rarely raises your bar. It removes people who would have cleared it.

Four, and what to do with the rest

We recommend four or fewer, and pushing everything else into preferences. The platform enforces every must-have you list as its own hard check, so the discipline is yours to keep: checks the AI adds on its own are capped at four, but yours are not. A candidate whose result on a must-have is failed, or still unknown, is never moved forward automatically; a person decides. Keeping the list short is not a limit on what you care about. A preference still ranks candidates, still shows up in the score, and still tells you who is stronger. It just does not throw anyone out.

The requirement nobody admits is optional

In most briefs we see, the tool requirement is the one doing the damage. It feels concrete, which is why it survives the conversation that trims everything else, and it is almost always the least predictive line in the whole brief. Someone who has built the same system twice in two adjacent stacks will be productive in yours faster than someone who has used yours once without building anything demanding on it.

Location is the second one. It is often written as a hard requirement when what the hiring manager means is that they would rather not fund a move. Those are different statements, and only one of them should be rejecting candidates automatically.

Common mistakes

• Writing the wish list as the brief. The job description is a marketing document and the scoring criteria are an operational one. They should not be the same list.
• Adding a requirement to fix a bad shortlist. If the pool is weak, the usual cause is a mistargeted search rather than a permissive filter. Tightening the gate shrinks the pool without improving what is in it.
• Treating silence as failure. A profile that does not mention something has not told you the person lacks it. Any system that scores those the same way will quietly discard good candidates, and you will never see the ones it discarded.
• Never revisiting the list. Requirements written before you saw the market are guesses. Once you have seen fifty real profiles you know which line is unrealistic.

A working method

1. Write every requirement down, without ranking them. Expect eight to twelve.
2. For each one ask the outstanding-candidate question: if they were exceptional everywhere else and missing this, would you look? Every yes moves to preferences.
3. If more than four survive, rank them and take the top four. The rest are preferences, and they still influence who reaches the top of your list.
4. Look at the first twenty candidates before deciding your brief was right. If a requirement is knocking out people you would happily interview, it was a preference all along.

A brief with four hard requirements and eight preferences will nearly always produce a better shortlist than one with twelve requirements, because the second one is not really a brief. It is a description of somebody who does not exist.