How to Write a Job Description for a Role You Have Never Hired Before

To write a job description for a role you have never hired before, do not start from a job description template. Start from the work: interview the people who depend on this hire, list first-year outcomes, turn them into duties and requirements, and test the draft with two outsiders. A job description generator can speed up the wording afterwards.

Why a new role is harder than a repeat hire

When you hire for a role you have filled before, you have a ghost to copy. You know what the last person did, where they struggled, what the manager wished they had known, and which interview questions told you the truth. A new role has none of that. You are guessing at the work, and the temptation is to fill the gap with a job description template pulled from the internet or a long list of skills borrowed from a similar job at a bigger company. That is how teams end up advertising a role that does not exist: five unrelated specialisms, ten years of experience in a tool that is four years old, and a title nobody can compare to the market. The result is a post that attracts the wrong people, repels the right ones and gives you nothing to score candidates against. The fix is to treat the description as the output of a short discovery process, not as a document you fill in. This guide walks through that process in order, with a worked example and a word-for-word skeleton you can reuse. For the wider picture of how a description feeds the rest of hiring, see /recruitment-software and our library of role guides at /job-description-template.

Step one: write down why the role exists

Before any duties, write two or three sentences that answer a single question: what is going wrong or not happening today that this person will fix or make possible? Examples of the shape: Customers wait too long for answers because the founders handle support between meetings. Or: We win projects but lose weeks to invoicing and scheduling because no one owns operations. This reason is the spine of the whole description. If you cannot write it, you are not ready to hire, and no template will help. Share the reason with the person who will manage the hire and with one person who will work alongside them, and ask whether they agree. Disagreement here is valuable, because it is far cheaper to discover it on paper than in the third interview. Keep the reason in plain words and avoid labels such as strategic or dynamic. A good reason names a problem, who feels it and roughly how often. It should fit in a short paragraph that could open the finished post.

Step two: interview the work, not the market

Next, collect facts from the people who understand the work. Talk to the manager, one or two future colleagues and, if possible, someone who does a similar job elsewhere in your network. Ask the same short list of questions each time. What would a great first week look like? What should be true after ninety days? What should be true after a year? What tasks will take most of the person's time? What decisions will they make alone and what needs approval? Who will they work with daily? What would make you regret the hire? What tools do they need on day one and which can they learn? Write answers as raw notes, then group them. You will usually see three to six themes. Those themes become your duties. Notice which items people repeat, because repetition signals priority. Do not copy market job ads at this stage. Looking at similar posts is useful later to check naming and pay norms, but if you read them first, their lists will quietly replace what you actually learned. The interview notes are your evidence, and the description should be traceable back to them.

Step three: turn outcomes into duties and requirements

Now convert notes into the parts of the description. Outcomes become the section on what success looks like. Daily and weekly tasks become duties, written as short verb-led lines. Then ask for each duty: what must a person already be able to do to start it, and what can be taught in the first month? The first group becomes must-have requirements and the second becomes nice-to-have or is left out. This matters because your must-haves will drive screening, whether by hand or by software, so every one should be something you would genuinely reject a candidate for lacking. A useful test for each line is: if a candidate did not have this, would I still interview them? If yes, it is a nice-to-have. Keep the must-have list to the five or six items that truly gate the work. For how to decide that split in detail, see our guide on must-have versus nice-to-have requirements in this blog. Resist adding qualifications as a way to signal seniority. Years of experience are a weak proxy for capability, and a short list of observable skills is easier to assess fairly.

A word-for-word skeleton you can reuse

Use this structure and replace the bracketed parts with your own facts. Title: use the plain market name for the work, not an invented one. Opening: [Company] is [one sentence about what you do and how big the team is]. We are hiring our first [role] because [the reason from step one]. What you will do: [five to eight verb-led duties, most important first]. What success looks like: [two or three outcomes at 90 days and 12 months]. What you need: [five or six must-haves, written as skills or evidence, not years]. Nice to have: [two or three items that help but can be taught]. Working arrangement: [location, hours, travel, tools]. Pay and benefits: [range or salary where you can say it, plus key benefits]. How we hire: [stages, rough timeline, who decides]. How to apply: [one clear action and contact]. Closing line: [a sentence that invites people with non-standard backgrounds to apply if they can show the must-haves]. Fill every bracket from your interview notes. If a bracket has no real answer, that is a signal that something is undecided, and it is better to find that out now.

Worked example: a first operations coordinator

This example uses invented details to show the process. A ten-person design studio has never had an operations role. Reason: Project start dates slip because invoicing, contracts and scheduling sit with the two founders. Interview notes: the founders spend about six hours a week on invoicing and about four on scheduling, with contracts done ad hoc. Colleagues say they would value one place to ask about deadlines. A freelance friend in operations says the job is mostly follow-up and systems. Themes: billing, scheduling, contracts, being the single contact for project logistics. Duties: send and chase invoices, maintain the project calendar, prepare contracts from approved templates, run a weekly status note. Must-haves: clear written communication, comfort with spreadsheets, evidence of handling deadlines for several people at once. Nice-to-have: experience with a project tool, basic bookkeeping. Outcomes: invoices sent within two days of milestones by month three, and no project starting without a signed contract by month six. Notice what is missing: no degree requirement, no invented seniority. The description now says what the job is, and it is easy to score a candidate against it.

Compare your options for getting a first draft

You do not have to write every line from a blank page. The table compares common starting points for a new role. Treat it as general guidance, because quality varies widely within each option.

The strongest approach combines the first row with one of the middle rows: gather facts yourself, then use a template or generator to polish structure and wording. Feeding a generator your reason, duties and must-haves gives far better output than asking it to write a job description for a coordinator. If you want to see how a role guide is structured, the library at /job-description-template shows the typical sections, and you can compare your draft against one.

Score your draft before you post it

Run the draft through this checklist, giving each line a score of 0 for no, 1 for partly and 2 for yes. A total of 16 or more out of 20 is ready to test; below 12 means go back to your interview notes.

Then do an outside test. Give the draft to two people who do not work with you and ask each to explain back, in their own words, what the person will do on a typical Tuesday and what they would need to apply. If their answers differ from your intent, rewrite until they match. This test takes twenty minutes and removes the most common failure, where the writer understands the text only because they already know the job.

Common mistakes with a first-time description

The first mistake is borrowing a long requirement list from a larger company and treating it as a minimum. A second is combining two jobs into one, such as support and sales, because you only have budget for one person, then pretending a single candidate will excel at both. If you must combine, say which half matters more. A third is using years of experience as a requirement without saying what the years should have produced. A fourth is hiding the pay, which reduces applications from the people you most want to reach and wastes the time of those who cannot afford the role. A fifth is vague culture language, such as fast-paced or self-starter, which says nothing checkable. A sixth is copying a title that implies seniority you do not intend. A seventh is skipping the outside test. Finally, many teams never revisit the description after the first quarter, so the role drifts and the next hire starts from a stale document. Put a date in your calendar to rewrite it using what the first person actually did, so the second hire in the role is no longer a first.

Where Rezumz fits

Rezumz is an AI hiring workspace for small and mid-size hiring teams. For this task, it offers the JD Enhancer at /jd-enhancer, which tightens a draft you have already written, and a job setup step where you paste the description and Rezumz lists the must-have and nice-to-have skills it found so you can check them before scoring CVs. Scoring compares each CV to those requirements, so a clear description directly improves your shortlist. What it does not do is discover the work for you: the interviews in step two are yours, and AI output is decision support that you review. It also does not publish to job boards with one click. It suits small and mid-size teams, with the Team plan for four or more recruiters. It is not the right fit for large enterprises needing deep HRIS or payroll connections. Pricing: a free plan includes 2 free candidate analyses; paid is $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, the overview at /pricing and our guide to /applicant-tracking-system.

When not to write a description yet

Sometimes the right move is to pause. If the manager and the founders cannot agree on the reason for the role, no wording will rescue the hire, and you should resolve that first. If the work is really a project that ends in three months, consider a contractor and a short scope document instead of a permanent description. If the role depends on a budget that is not approved, a post will only create candidates you cannot hire. And if you are tempted to write the description as a wish list for a person who does everything, step back and ask whether two part-time roles or an outside provider would fit better. A job description is a promise to candidates about the work and to your team about the standard you will use. When you cannot make that promise honestly, delay the post. When you can, the process above gives you a document that holds up in screening, in interviews and in the first review of the new hire.