A hiring request often begins with a short list: a job title, a few skills, a level of experience, and a request to start finding candidates. That is enough to open a conversation, but it is rarely enough to guide a good search.

A title such as “senior software engineer” can mean very different things across two companies, or even across two teams in the same company. One team may need someone who can stabilize a service that is already in production. Another may need an engineer who can design a new system with limited direction. Both may ask for the same programming languages and years of experience, yet the work they need done is not the same.

That is why teams should define role requirements before sourcing begins. The aim is not to write a longer job description. It is to agree on the work the person will own, the outcomes that matter, and the evidence that would show a candidate can deliver them.

When those details are clear, recruiters have a more useful search target, interviewers know what to assess, and candidates get a more accurate picture of the opportunity. The hiring process becomes easier to explain and more consistent from one stage to the next.

Why role requirements become vague

Role requirements often become vague for understandable reasons. A team may be replacing someone who left, responding to a new customer need, or trying to relieve pressure on an already busy group. The hiring manager knows something needs to change, but has not yet translated that need into a precise role.

The first draft then collects familiar phrases: strong communication, ownership, problem-solving, relevant industry experience, and the ability to work in a fast-paced environment. These phrases are not automatically wrong. The problem is that different people interpret them differently.

“Strong communication” might mean explaining a technical trade-off to a product manager, writing a clear incident report, presenting to customers, or keeping stakeholders informed when a delivery date changes. “Ownership” might mean taking a feature from specification to release, managing a budget, or spotting a risk before it becomes a problem. Without a concrete description, a recruiter cannot reliably tell which meaning the hiring manager intends.

There are several common sources of ambiguity:

·        The title is doing too much work. A title communicates seniority or discipline, but it rarely describes the actual scope, constraints, or expected outcomes.

·        The list mixes essentials with preferences. A requirement that is genuinely necessary sits beside a skill that would simply be convenient to have.

·        The team describes a person instead of the work. Words such as “dynamic,” “strategic,” and “hands-on” describe an impression, not a deliverable.

·        The role has changed since the request was written. A new project, manager, technology choice, or business priority may have changed what the person will actually do.

·        Stakeholders have different assumptions. The hiring manager, recruiter, future teammates, and interview panel may each have a different picture of the successful hire.

These gaps tend to surface later, when candidates are already in the process. A recruiter may screen for one interpretation, an interviewer may test another, and the hiring manager may reject a candidate for not matching an expectation that was never made explicit. The earlier the team resolves those differences, the less rework it has to manage downstream.

Start with outcomes, not a list of skills

The most useful first question is not “Which skills should we put in the job description?” It is “What needs to be different because this person joined?”

Start with the business or team need that triggered the hire. Perhaps releases are taking too long because deployment work is manual. Perhaps customer onboarding requires too much support from engineers. Perhaps a sales team needs someone who can translate technical requirements into credible solutions. Those situations point to different responsibilities, even when job titles overlap.

Turn the underlying need into a small set of outcomes. An outcome should describe a result or responsibility that can be discussed and assessed. It should be specific enough to guide a search, but not so prescriptive that it excludes every candidate who has taken a different route to the same result.

For example, “needs strong cloud skills” is a starting point, not a complete requirement. If the underlying need is reliability, a more useful outcome might be: “Improve the reliability of the production service by identifying recurring failure points, prioritizing fixes, and establishing useful monitoring.” The team can then decide which technical knowledge is essential to that work and what evidence would demonstrate it.

Use three time horizons to clarify expectations:

What must be true early on?

The first 30 to 90 days are usually about understanding the environment, building relationships, learning the existing system, and making an appropriate first contribution. Do not assume every role needs a major deliverable in the first month. For some senior roles, listening, diagnosis, and a sound plan are the right early outcomes.

Ask what a reasonable start would look like, given the team’s onboarding, access, dependencies, and level of support.

What should the person own by six months?

This horizon often makes the role more concrete. The person may be expected to own a service, lead a workstream, improve a process, manage a portfolio, or become the primary point of contact for a group of stakeholders. These expectations help distinguish a role that needs independent delivery from one that mainly supports others.

What longer-term contribution is the role meant to enable?

Some outcomes take longer than six months. A new leader may need to build a team, a product manager may need to establish a roadmap, and a specialist may need to improve a capability across several departments. Include these longer-term responsibilities without pretending that every result can be guaranteed by one employee alone.

A useful role brief separates the result the person is responsible for from the conditions they need to succeed. For instance, a person may be accountable for improving a process, but the outcome also depends on access to data, stakeholder cooperation, budget, and decisions outside their control. Clear role requirements recognize those dependencies rather than making the candidate responsible for everything.

Translate outcomes into observable evidence

Once the team has identified the outcomes, ask what a candidate would need to know or do to achieve them. This is where skills, experience, and qualifications become useful.

The distinction matters. A skill is a capability. Experience is exposure to situations in which that capability may have been used. Evidence is the information the team can examine to understand whether the candidate has demonstrated the capability at a relevant level.

Consider a role that needs someone to improve a technical support process. “Five years of experience” may be a useful signal for some roles, but it does not show whether the person has diagnosed recurring issues, improved documentation, worked with engineering teams, or measured whether a change helped. A discussion of a previous improvement, a work sample, or a detailed scenario may provide more relevant evidence.

For each outcome, ask:

·        What would competent performance look like?

·        Which knowledge or skills are needed to achieve it?

·        What experience would help the person get there?

·        What evidence could the candidate reasonably provide?

·        What would count as a strong, acceptable, or insufficient answer?

·        Which parts of the evidence can be assessed during recruitment, and which will only become visible on the job?

Avoid turning every outcome into a long test. The goal is not to demand proof of everything before hiring. It is to choose proportionate ways to understand the capabilities that matter most.

A practical example makes this clearer. Imagine a company hiring an engineering lead to improve delivery reliability. The team might define the outcome as “make delivery risks visible earlier and improve the team’s ability to release changes safely.” Relevant evidence could include a candidate explaining how they diagnosed a delivery bottleneck, the trade-offs they considered, how they involved other teams, and what they learned from the result. The team does not need to insist that every candidate used the same tools or worked in an identical environment. It needs to understand whether the candidate can reason through the work.

Separate must-have skills from preferred qualifications

One of the most important steps when you define role requirements is to distinguish between what a person needs on day one and what the team would be happy to see.

A must-have should have a clear reason. It may be required to perform a core responsibility, meet a legal or professional requirement, work safely, or operate within a real technical constraint. If the team cannot explain why a qualification is essential, it should be reconsidered.

A preferred qualification can strengthen an application without being a condition for consideration. It might shorten onboarding, provide useful domain knowledge, or make one aspect of the job easier. It should not quietly become a requirement during screening if it was not essential in the original brief.

Use a simple test for each item:

1.        Connection to the work: Which responsibility requires this?

2.        Timing: Must the person have it before joining, or can it be learned with reasonable support?

3.        Alternatives: Could a candidate demonstrate the same capability through a different technology, industry, qualification, or career path?

4.        Evidence: How will the team assess it consistently?

5.        Consequence: What meaningful risk would arise if the person did not have it?

This exercise often reveals requirements that are inherited from an old job description rather than driven by the current role. A tool may have been used by the previous employee but no longer be central to the work. A degree may be listed because it has always appeared in the template, even though the job depends more directly on demonstrated expertise. A certain number of years may be used as a proxy for seniority when the team actually needs independent decision-making, mentoring, or ownership of complex work.

That does not mean experience, degrees, certifications, or specific technologies are unimportant. It means each requirement should earn its place in the brief.

Be especially careful with long wish lists. Requiring every preferred skill can narrow the pool without improving the team’s ability to identify people who can do the job. It can also make a role look internally inconsistent: a position described as entry-level may demand years of experience across several specialisms, or a leadership role may be assessed mainly through a list of tools.

Build a role scorecard that the team can actually use

A role scorecard turns the discussion into a working reference for the recruiting process. It does not need to be complicated. A clear one-page scorecard is often more useful than a lengthy document no one revisits.

For each priority outcome, record the responsibility, the capability required, the evidence to look for, and the person responsible for assessing it. Add a short description of what strong evidence looks like. This gives the team a shared basis for screening and interviews.

A useful scorecard can include:

·        Role purpose: Why the role exists and what need it addresses.

·        Priority outcomes: Three to five results or areas of ownership that matter most.

·        Essential capabilities: The skills and knowledge needed to deliver those outcomes.

·        Preferred experience: Helpful experience that is not a strict requirement.

·        Evidence sources: Relevant work examples, structured questions, portfolios, work samples, or other proportionate assessments.

·        Evaluation criteria: What a strong, adequate, or weak demonstration looks like.

·        Constraints and dependencies: Location, schedule, regulatory requirements, tools, team structure, and resources that genuinely affect the work.

·        Decision ownership: Who assesses each criterion and who makes the final hiring decision.

The scorecard should be specific to the role, not a generic template with the title changed. It should also be short enough to use throughout the process. If the criteria cannot be explained to a candidate or interviewer in plain language, they may need further work.

Align the hiring manager and recruiting team before sourcing

A role brief is useful only if the people using it interpret it consistently. Before sourcing, the hiring manager and recruiter should review the requirements together. Include future teammates or other stakeholders when their input is necessary, but be clear about who owns the final decision.

This meeting should resolve practical questions rather than merely approve a document.

Ask the hiring manager to describe the work in a typical week. Discuss the hardest problems the person will face, the decisions they will make independently, and the situations in which they will need support. Clarify what the role does not own as well as what it does. A candidate can be a strong fit for the defined job and still be wrong for a role that has been described inaccurately.

Then review the evaluation plan. Which criteria can be assessed in the initial conversation? Which require a technical discussion or work sample? What does each interviewer own? What evidence needs to be recorded so the next person does not have to repeat the same questions?

The recruiter should also be able to explain the role without relying on the hiring manager’s shorthand. If the recruiter cannot describe the main outcomes, likely challenges, and essential requirements in their own words, the brief is probably not ready.

This alignment does not mean every stakeholder must agree on every preference. It means disagreements are made visible before candidates are assessed. Where two requirements conflict, the team should decide which one takes priority rather than leaving recruiters to guess.

Write the job description from the role definition

A job description should communicate the role clearly to a potential candidate. It is not the place to discover what the role means for the first time.

Once outcomes and criteria are agreed, the description becomes easier to write. Begin with the purpose of the position and the work the person will own. Explain the main responsibilities in concrete language. Describe essential requirements separately from preferred qualifications. Where possible, give candidates a realistic sense of the first few months and the people or functions they will work with.

Replace generic wording with details. Instead of “must thrive in a fast-paced environment,” explain what makes the work fast-moving: multiple customer priorities, weekly releases, changing requirements, or time-sensitive operational decisions. Instead of “excellent stakeholder management,” explain which stakeholders the person will work with and what they need to accomplish together.

A clear description should also be honest about constraints. If the role involves on-call responsibilities, travel, a fixed work location, or a significant amount of operational work, state that accurately. Clarity helps candidates decide whether the opportunity fits their expectations. It also reduces the chance that the job changes shape between the initial conversation and the final interview.

Do not overload the description with every imaginable skill. The job description is a candidate-facing explanation of the role. The role scorecard is the team’s working guide for evaluating evidence. They should agree with each other, but they do not need to contain the same level of detail.

A practical role-definition checklist

Use this checklist before a new role moves into sourcing. If several answers are unclear, pause and resolve them with the hiring manager.

·        Can we explain why the role is needed now?

·        Have we described the main outcomes rather than only listing skills?

·        Are the first 90 days and the first six months realistic for this role?

·        Have we identified the three to five outcomes that matter most?

·        Can we explain why each must-have requirement is essential?

·        Have we separated preferences from requirements?

·        Have we considered equivalent experience and different career paths?

·        Is there a clear way to assess each priority capability?

·        Does each interviewer have a defined area of evaluation?

·        Can the recruiter explain the role without using vague shorthand?

·        Does the job description accurately reflect the actual work?

·        Is it clear who owns the final hiring decision?

A simple way to test the brief is to ask the recruiter and hiring manager separately to describe what success looks like. Compare their answers. If they name different outcomes or different essential skills, the team has found an alignment problem worth fixing before the search begins.

How to keep role requirements useful as the process moves forward

A role scorecard should guide the process, but it should not become an excuse to ignore new information. During sourcing and interviews, the team may discover that a requirement is too broad, that an assessment does not produce useful evidence, or that the business need has changed.

Make changes deliberately. Record what changed, why it changed, and whether the adjustment applies to every candidate still in the process. Avoid changing the standard for one person simply because an interviewer liked or disliked them. If the role itself changes materially, communicate the change to affected candidates and consider whether the search needs to be recalibrated.

Keep the criteria connected across the workflow. The sourcing message should reflect the work. The initial screen should explore relevant experience. The interview should assess capabilities that matter to the role. Feedback should refer to evidence against agreed criteria rather than a general feeling of fit. This is how a clear definition becomes useful in practice instead of remaining a document created at kickoff.

A connected workflow can help teams carry the role context from one stage to the next. Talentz’s approach to hiring decisions is built around making role criteria and evidence more useful across the hiring process. Zee supports a more connected approach to the work, while the hiring team remains responsible for evaluating candidates and making the final decision.

Conclusion: Define the Work Before You Search

The quality of a search depends in part on how clearly the team has defined what it needs. A long list of skills cannot replace an agreed understanding of the work, and a polished job description cannot resolve disagreements the team has not discussed.

To define role requirements well, start with the need behind the hire. Turn that need into outcomes, identify the capabilities required to deliver them, separate must-haves from preferences, and decide what evidence will help the team evaluate candidates fairly and consistently. Then make sure the recruiter, hiring manager, and interviewers are working from the same definition.

This process takes some focused effort at the beginning, but it gives the search a clearer direction. Candidates receive a more accurate explanation of the opportunity, recruiters know what to look for, and interviewers have a stronger basis for their assessments.

The aim is not to predict every detail of a person’s future performance. It is to make the hiring decision more grounded in the actual work. Define the work first, and the search has a much better starting point.

Frequently asked questions

1. How do you define job requirements?

Start by identifying why the role is needed and what outcomes the person should deliver. Translate those outcomes into essential capabilities, distinguish must-have requirements from preferences, and decide what evidence can demonstrate each capability. Align the hiring manager and recruiter before sourcing begins.

2. What is a role scorecard?

A role scorecard is a practical summary of a position’s purpose, priority outcomes, required capabilities, evaluation criteria, and assessment ownership. It helps recruiters and interviewers use the same definition of success throughout the hiring process.

3. How do you distinguish must-have from preferred qualifications?

A must-have is necessary for a core responsibility, a legitimate constraint, or a requirement that cannot reasonably be learned after joining. A preferred qualification is useful but not essential. For every requirement, ask what work it supports, whether it is needed on day one, and whether equivalent experience could demonstrate the same capability.

4. What should a hiring manager define before sourcing?

The hiring manager should clarify why the role exists, what the person will own, what success looks like in the first few months, which capabilities are essential, what can be learned, how candidates will be evaluated, and who makes the final decision.