Must-Have vs Nice-to-Have Requirements: How to Decide

A must-have requirement is something you would reject a candidate for lacking and could not teach within the first few weeks; a nice-to-have helps but can be learned or offset. To decide, test each line in your job description template by asking whether you would still interview someone without it, and keep must-haves to five or six.

Why this split decides your shortlist

The requirements section of a job description looks like the least important part, but it quietly controls who gets hired. Every must-have is a gate. If you write ten gates, many strong people fail one of them on paper and never reach an interview. If you write them vaguely, reviewers apply their own private standards and your screening becomes inconsistent. If you use software that scores CVs against the requirements, the list literally drives the ranking. Yet most requirement lists are assembled by habit: copied from the last posting, from a competitor, or from a job description generator that adds whatever is common for the title. Nobody asks which lines are truly necessary. This guide gives you a plain test for each line, a scoring sheet to rank your list, a worked example with invented numbers, a table of common categories and how to treat them, and a list of mistakes. The aim is a short, honest list that you can defend to a candidate, a manager and yourself. For role-specific starting points, browse /job-description-template, and for how screening uses the list, see /ai-resume-screening.

Definitions that you can actually apply

Definitions help only if they lead to the same answer when two people apply them. Use these. A must-have is a skill, experience or condition that the person needs on day one, that you cannot teach in the first month or two without hurting the work, and without which you would not interview them. A nice-to-have is a skill or experience that would make the person faster or more rounded, but that they can acquire, borrow from a colleague or work without. A condition such as working hours, location, a licence or right to work is a separate category: it is a must-have in effect, but it should be stated as a condition so people can self-select, and rules about it differ by country. Training time matters. If a skill takes a smart person two weeks to learn, it is probably not a must-have, however useful. If it takes a year of practice, it might be. Also separate skills from proxies. A degree, a job title or a number of years are proxies for skills, so where you can, state the skill itself and what evidence would show it, such as a sample of work or a described project.

The one-question test for every line

Take each requirement and ask: if a candidate lacked this but was strong on everything else, would I still interview them? If the answer is no, it is a must-have. If yes, it is a nice-to-have or should be deleted. Then apply three follow-up questions. Can we teach it in the first month? If yes, it drops to nice-to-have. Can we assess it from a CV, a sample, a test or an interview question? If not, it is not a usable requirement, because you cannot check it fairly. Is it linked to a real duty in the job description? If not, delete it. A final check is the swap test: imagine your best current employee in a similar role applying today. Would they meet every must-have as written? If your star would fail your list, the list is wrong. This single question does most of the work. Run it with the hiring manager in a ten-minute conversation and mark each line M, N or X for delete. Disagreements between people are useful data, because they reveal that the role is not as clear as it looked. Resolve them before you post, not at the shortlist stage.

Categories and how to treat each

Different kinds of requirement need different handling. The table gives a starting point, and the right answer always depends on your role.

Notice that most of the cells point away from credentials and toward evidence. That is deliberate. A list built on observable skills is easier to assess fairly and widens your pool. Where the law requires a specific qualification, such as a professional licence, state it as a condition and do not soften it, and check local rules, since they differ.

Worked example: a bookkeeper role

This example uses invented details. A small property management firm drafts requirements for a bookkeeper. First draft, 14 lines: degree in accounting, five years experience, expert in three accounting packages, strong Excel, payroll experience, property industry experience, VAT returns, month-end close, bank reconciliation, supplier payments, excellent communication, attention to detail, ability to work independently, full driving licence. Apply the one-question test with the owner. Reconciliation, month-end close and supplier payments are daily work, so they are must-haves. Strong spreadsheet skills are needed, must-have. Communication is needed but, once evidenced in a short written task, can be a must-have in the interview stage. VAT returns are required but can be learned if the person knows the basics, so nice-to-have. Payroll is handled by an outside provider, so delete. Property industry experience: nice-to-have. Three named packages: the firm uses one, so name it and treat familiarity with any similar package as enough. Degree and five years: delete, replaced by evidence of having done month-end close. Driving licence: only needed for rare site visits, so delete or state as a condition. Result: five must-haves, three nice-to-haves. The pool of plausible candidates roughly widens, and every line can be checked.

Score and rank your list

Use this sheet for each requirement. Score 0 to 2 per column. A line is a must-have only if it scores 2 on the first column and at least 1 on the others. Columns scoring low suggest a rewrite or a delete.

The first three rows are labelled examples with invented scores. Fill the last rows with your own lines, add more as needed, and then sort. Keep the top five or six as must-haves, move middle scorers to nice-to-have and delete the rest. If the hiring manager and you score a line differently, discuss that line only, using the training-time test. The sheet takes about fifteen minutes and makes later screening far more consistent because everyone is working from the same written standard.

How the split affects screening and scoring

Once the lists exist, they steer everything downstream. For manual screening, they give reviewers a common checklist: a candidate missing a must-have is set aside with a recorded reason, while missing nice-to-haves only affects ranking among those who qualify. For software that scores CVs, the weight you give each list matters, so a long list of must-haves can make nearly everyone look weak and a list stuffed with nice-to-haves can make everyone look similar. Either way, a person should review the shortlist and the borderline cases. Be careful with absence on a CV: a candidate may have a skill they did not write down, so use a phone screen or a short task to confirm before rejecting for something you can verify quickly. Keep notes of why people were progressed or not, since consistent written criteria help you explain decisions. Rules about automated screening and record keeping differ by country, so check local law. Finally, review your lists after each hire: which must-haves predicted success, and which were never used? Prune accordingly.

Common mistakes

The most frequent error is promoting everything to must-have because it feels safer, which shrinks the pool and loses strong people. The second is copying requirements from another company, which commits you to a standard that fits their needs. The third is using years of experience or a degree as a proxy without any reason, which can also exclude capable people and, in some places, raise fairness concerns that differ by country. The fourth is listing soft skills with no way to assess them. The fifth is writing must-haves that the current team members do not meet themselves. The sixth is changing the list halfway through screening, which makes earlier decisions inconsistent. The seventh is treating nice-to-haves as hidden must-haves at interview, rejecting people for lacking something the post called optional. The eighth is letting a job description generator add requirements and not checking them. Keep a short written record of the final list and the date, and apply it to everyone in the same way.

Where Rezumz fits

Rezumz is an AI hiring workspace for small and mid-size hiring teams. When you create a job and paste the description, Rezumz lists the must-have and nice-to-have skills it found so you can check and correct them, and CV scores compare each candidate against that list, with the evidence shown. The JD Enhancer at /jd-enhancer can tighten a draft first. Rezumz does not decide for you which requirements are fair or lawful, and AI output is decision support that you review. It does not post to job boards with one click and is not an HRIS or payroll tool. It suits small and mid-size teams, with the Team plan for four or more recruiters, and it does not suit large enterprises needing deep HRIS or payroll integrations. Prices: free plan with 2 free candidate analyses; $29 a month, $199 a year or $499 lifetime (limited); Team is $79 a month or $699 a year for up to 10 teammates. See the live demo at /demo, plans at /pricing and the guide at /applicant-tracking-system.

When this split does not fit

The must-have and nice-to-have split is not a universal answer. For roles regulated by licence, such as some health, legal, financial or safety jobs, certain qualifications are legal conditions and not matters of preference, so follow the rules in your country. For very high-volume, entry-level hiring, you may use almost no skill requirements and instead screen on availability, conditions and a short trial. For senior leadership roles, requirements often cannot be reduced to a short list, and judgement in interviews matters more than gates on paper. And for internal moves, you may already know the candidate and weigh potential differently. In every case, the underlying idea still helps: decide in advance, in writing, what is truly necessary, and be able to explain why. If you cannot explain a requirement in one sentence, it should not be a gate. A practical habit is to keep a short log beside the final list, recording for each must-have the reason it is there and who agreed. When a hiring manager later asks to add a requirement mid-search, ask which existing one it replaces. That keeps the list short and keeps the screening fair for everyone already in the pipeline. After the hire, note which requirements the new person actually needed in their first quarter, and carry that learning into the next description. Over time, the log becomes your own evidence base, far more reliable than any borrowed list, and it makes onboarding plans easier to write because the real priorities are already written down.