A Practical Template for Turning a Long, Messy JD Into Search Logic You Can Actually Use
The job description lands in your inbox.
Four pages. Fifteen requirements. Several tools. A degree preference. Three different ways of describing seniority. And, somewhere inside all of that, the actual person you need to find.
The easiest thing to do is copy the requirements into a search and start adding filters.
It is also where a lot of searches go wrong.
A job description is written to explain a role. A sourcing brief has a different job: turn that role into search signals you can actually test.
The goal is not to reproduce every line of the JD inside your search. It is to decide what should actually help you find the right people, and what is just noise that made it onto the page.
This guide shows how to turn a messy job description into a compact sourcing brief you can use for manual sourcing, share with a team, or use as a cleaner starting point for AI Search.
TL;DR: Before running a search, turn the JD into a one-page sourcing brief containing:
- the actual outcome of the role
- 3-5 core signals
- equivalent skills or technologies
- a small title family
- supporting context
- real constraints
- obvious exclusions
- open questions for the hiring manager
Then test the brief against real profiles before making the search more restrictive. The job description is your source material. The sourcing brief is your search plan.
Why a job description is not a search brief
Job descriptions pass through several hands before sourcing even starts.
The hiring manager describes the ideal person. HR adds structure. Old templates contribute old requirements. Tools that one team happens to use become “required.” Nice-to-haves quietly move into the must-have section somewhere along the way.
That does not make the JD a bad document. It was just never written to answer the one question a sourcer actually needs answered: what evidence should I look for in a profile to believe this person could do the job?
That distinction matters.
Take a requirement like:
Experience with Salesforce, HubSpot, Marketo, Outreach, Salesloft, Gong, ZoomInfo and Apollo.
A search has no way of knowing that two of those eight tools might be central to the role while the rest are interchangeable parts of whatever stack the team happens to run today. Treat all eight as equally important, and a logically correct search quietly becomes an unnecessarily narrow one.
A sourcing brief forces that decision before the search begins, instead of letting the search make it by default.
The sourcing brief template
A useful sourcing brief does not need to be long. For most roles, one page covers it.
1. Role outcome
Write one sentence describing what this person actually needs to accomplish. Use this structure:
This person needs to [do what], in [what environment], at [what level of responsibility or complexity].
For example:
Turn messy product and customer data into decisions the business can act on, working closely with stakeholders across the company.
Notice what is missing: company values, benefits, generic soft skills, a list of tools. The sentence defines the work before anything else gets added to it.
2. Core signals
These are the things you would expect to see in nearly every strong candidate. Aim for a small group rather than copying the full requirement list.
For a Senior Data Analyst, that might be:
- advanced SQL for complex, ad hoc queries
- Python for data manipulation and analysis
- experience designing or reading A/B tests
- comfort presenting findings to non-technical stakeholders
A tool or technology can be a core signal, but only when the role genuinely depends on it, not just because it happened to make the list.
The useful question here is not “is this mentioned in the JD?” It is “would I reject an otherwise excellent candidate because this is missing?” If the honest answer is no, it should not behave like a hard requirement.
3. Equivalent signals
This is one of the more useful parts of a sourcing brief, and one that most JDs never spell out. Ask: what could a strong candidate have instead?
Examples:
- Tableau, Power BI or Looker, rather than one named tool
- dbt or another modern transformation and modeling workflow
- SQL depth demonstrated through the complexity of the queries, not a certificate
- Python or R for statistical analysis
You are not lowering the bar here. You are naming the capability the tool is actually standing in for, so the tool itself stops being the requirement.
4. Title family
The title on the vacancy is a starting point, not a universal market label. Instead of searching one exact title, define several that may represent similar work.
For a Data Analyst role, the family could include:
- Data Analyst
- Senior Data Analyst
- Analytics Engineer
- Business Intelligence Analyst
- Product Analyst
These titles do not need to be perfect synonyms. They need to describe people worth reviewing. For a deeper framework on this, see our guide to skills-first sourcing.
5. Supporting context
Now capture what strengthens a profile without deciding, on its own, whether that profile shows up in the search at all.
Examples:
- dbt
- some exposure to machine learning
- a BI tool preference
- e-commerce or fintech background
- experience presenting to leadership
- statistics coursework or a related certification
Supporting context still matters. The difference is that you weigh it after finding a potentially relevant person, rather than letting every detail decide in advance who gets found.
6. Real constraints
Some requirements really are fixed. Common ones:
- location
- legal right to work
- required language
- working hours
- security clearance
- mandatory certification
- on-site availability
Write these separately, then challenge each one: is this truly fixed, or are we treating a preference as a constraint? A company may prefer someone already based in a particular city but still be open to relocation. A hiring manager may ask for seven years of experience while actually caring more about whether the person has owned work of the right complexity. Those lead to different search decisions.
7. Exclusions
A good brief also names who looks relevant on paper but usually is not. This is especially useful for roles with ambiguous titles.
For a Data Analyst search, that might mean:
- profiles that are mostly dashboard building, with little ownership of the analysis itself
- data-entry or reporting-only roles
- data engineers focused on pipeline maintenance rather than analysis
- software engineers who query data occasionally but do not own the analysis
Exclusions help you recognize false positives on sight, instead of solving the problem by adding one more mandatory filter every time one shows up.
8. Open questions
Do not bury uncertainty inside the search. Write it down instead. For this role, that list might look like:
- Is Python required from day one, or can a strong SQL analyst pick it up on the job?
- Is dbt specifically required, or does comparable modeling experience count?
- Is the e-commerce or fintech background a real requirement, or a preference?
- Is a quantitative degree required, or can applied experience substitute for it?
- How much stakeholder-facing or presentation experience is actually needed?
These are good questions for a short calibration call with the hiring manager. A five-minute answer can sometimes improve a search more than another thirty minutes of adjusting filters.
From JD to sourcing brief: the 6-step process
Reading a job description line by line rarely produces a clean brief on its own. These six passes will get you there.
Step 1. Read for the work, not the wish list
Read the responsibilities first, before the requirements. Ask what this person will actually spend most of their time doing, then write the role outcome in one sentence.
If you cannot describe the work without listing tools, you probably do not understand the role well enough yet to search for it.
Step 2. Find the load-bearing requirements
Go through the JD and mark each requirement as one of four things: core, meaning the candidate genuinely cannot do the job without it; equivalent accepted, meaning the capability matters but another tool or background could demonstrate it; supporting, meaning it is useful evidence but not worth excluding someone over; or unclear, meaning it needs confirmation from the hiring manager.
This simple sort usually explains why a search built straight from the JD ends up too narrow.
Step 3. Build the title family
Start with the vacancy title, then ask what a competitor would call this person, what a smaller company might call it, what a larger one might, and whether the function is sometimes buried inside a broader title. Could the same candidate have changed job titles without their actual work changing at all?
Keep the family focused. The goal is not to collect every remotely related title. It is to stop one naming convention from defining the entire candidate pool on its own.
Step 4. Translate vague requirements into profile evidence
Some JD language is useful in an interview and close to useless during sourcing. “Strong stakeholder-management skills,” for example, might show up in a profile as cross-functional ownership, work with enterprise customers, or coordination across engineering and product teams. “Comfortable in a fast-paced environment” might show up as early-stage company experience or ownership spanning several functions.
Do not turn every soft requirement into another keyword. Use it as context for reviewing profiles instead.
Step 5. Separate constraints from preferences
Make two lists: fixed, meaning the hiring process genuinely cannot move on it, and flexible, meaning the team has a preference but could compromise for the right person.
Keep the distinction explicit. Left implicit, “preferred” requirements tend to harden into mandatory ones simply because they were sitting there as available filters.
Step 6. Test the brief against the market
Do not finish the brief in isolation. Run the initial search and look at the first 15 to 20 profiles as a group. Are the right kinds of people showing up? Which false positives keep repeating? Are strong adjacent candidates missing? Is one core signal generating most of the noise, or one constraint shrinking the market more than it needs to?
Only then adjust the search, and only to solve a problem you can actually see in the results, not because the JD still has an unused line sitting in it. For a more detailed search-review process, see our AI Candidate Search Audit.
Worked example: from 12 JD requirements to one sourcing brief
Imagine the vacancy includes:
5+ years as a Data Analyst, advanced SQL, Python for data manipulation, experience with Tableau or Power BI, strong knowledge of statistics, experience running A/B tests, familiarity with dbt, some exposure to machine learning, excellent stakeholder communication, comfortable presenting to leadership, e-commerce or fintech background preferred, and a bachelor’s degree in a quantitative field.
That is twelve separate requirements. Reproduce the list inside a search as written, and you are assuming all twelve deserve roughly equal weight. They almost certainly do not.
Here is what the sourcing brief looks like instead.
Role outcome: Turn product and customer data into decisions the business can act on, working directly with stakeholders across growth and product.
Core signals: advanced SQL for complex queries, Python for data manipulation and analysis, experience designing or reading A/B tests, comfort presenting findings to non-technical stakeholders.
Equivalent signals: Tableau, Power BI or Looker; dbt or a comparable modeling workflow; statistics demonstrated through applied work rather than a specific course or certificate.
Title family: Data Analyst, Senior Data Analyst, Analytics Engineer, Business Intelligence Analyst, Product Analyst.
Supporting context: dbt, exposure to machine learning, e-commerce or fintech background, experience presenting to leadership.
Real constraints: to be confirmed based on location, employment model and the specific team’s requirements.
Possible exclusions: dashboard-building roles with little analysis ownership, data-entry or reporting-only positions, data engineers focused on pipeline work rather than analysis, software engineers who query data occasionally without owning the analysis.
Open questions: Is Python required from day one? Is dbt specifically required, or does comparable modeling experience count? Is the e-commerce or fintech background a real requirement? Is the degree required, or can applied experience substitute?
Twelve requirements. Four real core signals. One title turned into five.
The five questions worth taking back to the hiring manager
When a JD is overloaded, you do not need to review every line together. Five questions usually get you most of the way to a working calibration:
- What would make you reject an otherwise excellent candidate immediately? This surfaces the genuine non-negotiables.
- Which tools or skills could be learned after joining? This shows which items are context rather than core signals.
- What experience could substitute for the exact requirement as written? This is where equivalent signals come from.
- What would make you interview someone even if their title looked completely different? This sharpens the title family.
- Which requirement made the list mostly because it would be nice to have? This is usually where preferences are hiding, dressed up as filters.
The answers tend to change a search more than asking, line by line, whether each JD bullet is “mandatory.”
Where AI Search fits
AI can speed up the first draft considerably. In Wandify, you can start from a job description and use AI Search to generate suggested titles, skills and keywords in seconds.
Generation should not be the final decision, though. The AI is still working from the same source document you are, so if the JD contains an inflated title, too many technologies, or assumptions dressed up as requirements, the generated search can inherit all of it.
The sourcing brief is the review layer that catches that. A practical workflow looks like this: job description, then AI-generated search draft, then sourcing brief review, then search, then profile calibration, then refinement.
In Wandify, the brief maps directly onto the search structure. True must-haves go into Main skills. Flexible signals go into Additional skills. Supporting terminology goes into Keywords. Market variations become the title family. Fixed requirements become the relevant search filters.
The point is not rebuilding everything AI generated by hand. It is deciding what actually earns a place in the final search. You can see the full workflow in our practical guide to AI Search in Wandify.
A sourcing brief should evolve
The first version does not need to be perfect, and honestly, it probably will not be.
Your first search tells you things the JD never could: how the market actually describes the role, which titles genuinely show up, which skills travel together, where the false positives keep coming from, and which supposedly mandatory requirement strong candidates keep lacking anyway.
That information belongs back in the brief. A sourcing brief is not just a document you write before searching. It becomes a record of what the market taught you while you searched.
Treat the JD as a starting hypothesis rather than the final word, and the search as the first real test of it. Then keep checking that hypothesis against real people.
Copy this sourcing brief before your next search
Role outcome: What does this person actually need to accomplish?
Core signals: What 3-5 capabilities would you expect in nearly every strong candidate?
Equivalent signals: What other tools, technologies or backgrounds could demonstrate the same capability?
Title family: What other titles could represent the same work?
Supporting context: What strengthens a profile without being mandatory?
Fixed constraints: What genuinely cannot change?
Flexible constraints: What is preferred but negotiable?
Exclusions: Which profiles repeatedly look relevant but are not?
Open questions: What still needs clarification from the hiring manager?
Calibration notes: What did the first 15-20 profiles teach you?
That is enough to turn a long job description into something a sourcing team can actually use.
Final thought
The best sourcing brief is not the one that captures every requirement. It is the one that makes the requirements that actually matter visible.
A job description tells you how the company currently describes the role. A sourcing brief turns that description into a plan you can test. And once you start reviewing real profiles, the market gets a vote too.
Have a job description ready? Turn it into a cleaner search with Wandify AI Search, review the suggested titles and skills, and refine from there.
FAQ
What is a sourcing brief? A sourcing brief is a compact, search-oriented version of a hiring requirement. It defines the role outcome, core and equivalent signals, title family, supporting context, constraints, exclusions and any open questions that still need calibration.
Is a sourcing brief the same as a job description? No. A job description describes the role for candidates and internal stakeholders. A sourcing brief translates that same information into signals you can use to find and evaluate candidates.
How long should a sourcing brief be? Usually one page. The point is not to reproduce the JD in another format, but to make the search logic explicit.
How many must-have skills should I include? There is no fixed number, but most roles reduce down to a small group of genuinely load-bearing capabilities. If your list still has a dozen mandatory signals, some of them are probably equivalent technologies, supporting context, or plain preferences.
Should I search only by the job title on the vacancy? Usually not. Build a focused title family around the work itself. Different companies often use different titles for very similar responsibilities.
What should I do with nice-to-have skills? Keep them as supporting context instead of letting each one restrict the candidate pool. They can still help with ranking and profile review once someone is already in the results.
Can AI create a sourcing brief automatically? AI Search can produce a strong first draft by pulling titles, skills and keywords out of a JD. It still needs review, because the source document may carry outdated, inflated or overly strict requirements straight through.
When should I update the sourcing brief? After the first profile review. If the search keeps returning the wrong profiles, or missing strong adjacent candidates, use that as evidence to refine the brief before adding more restrictions on top of it.