How to write an expert-search brief that gets better matches

Most teams blame the network when the shortlist disappoints. Usually the network did exactly what the brief asked. If the brief was one line, the shortlist is a one-line shortlist.

Below is the template that fixes it. Six sections, applied at the start of the project.

What an expert-search brief actually is

A brief is the artifact the sourcer searches against. Not a query, not a Slack message. It's a short structured document that names the decision, the perspectives needed, the company universe, the title taxonomy, the geography and recency constraints, and the exclusions. The sourcer's only window into your project is what you write here.

The brief shapes everything downstream: which companies get searched, which titles get filtered, which questions get pre-screened, what counts as a conflict, what "fit" even means. Get it right and the shortlist mostly lands. Get it wrong and no amount of downstream filtering saves it.

Fifteen minutes of work here sets the ceiling for the rest of the project.

The six sections of a strong brief

1. The decision the brief is informing

Start with the decision, not the topic. "Should we acquire CompanyX?" is a decision. "EV battery industry overview" is a topic. The decision tells the sourcer what perspectives matter — buyer perspective, supplier perspective, customer perspective, technical operator perspective — and how much each matters.

Write the decision as a sentence. Then write the two or three sub-questions the decision depends on. Those sub-questions become the screen.

2. The expert perspectives needed

For each sub-question, name the type of expert who would credibly answer it. Not titles — perspectives. A "former CTO at a competitor" is a perspective. A "current operator at a buyer-side company" is a perspective. A "channel partner who's worked with both" is a perspective.

This is where most briefs collapse. They name a title ("senior") and a company type ("EV manufacturer") and stop. A perspective-first brief names who has the experience that answers the question, which is what a sourcer can actually search against.

3. The company universe

List the companies whose alumni or operators would be relevant. Start with the obvious — direct competitors, named customers, named suppliers — then expand. Adjacent geographies, former employees one step removed, channel partners, regulators, competitors of the competitors.

Aim for tens of names, not hundreds. Too few and you'll get the same handful of alumni every search; too many and the sourcer can't tell what you actually care about. Annotate each entry with why — "competitor, US market," "former parent," "key supplier of cathodes" — so the rerank step downstream knows what the company represents in your decision.

4. The title and responsibility taxonomy

Title strings are noisy across companies — what "VP, Strategy" means at one firm is "Senior Manager, Strategy" at another. Spell out the responsibility you actually want exposure to: P&L ownership in a segment, deal sponsorship, technical ownership of a product area, sales coverage in a geography.

A simple format: "Roles equivalent to: VP Strategy / Director of Strategy / Senior PM with strategic remit" plus "Must have owned: P&L, product roadmap, supplier relationships." The first list expands the candidate pool; the second narrows it on substance.

5. Geography, language, and recency constraints

Make the constraints explicit. "US-based, English-speaking" is a constraint. So is "left the company no earlier than 2022." So is "speaks Mandarin if covering Greater China." Constraints kept implicit get violated; constraints written down get checked.

The recency constraint is especially worth stating. Operator memory decays fast in regulated or fast-moving categories. State the date floor explicitly — say, "left the company no earlier than 2022."

6. Exclusions

Name the conflicts you won't accept. Current employer? Past employer of a portfolio company? Anyone who's spoken on a panel with the client's CEO in the last year? Board affiliations? Equity in a specific competitor?

Exclusions belong in the brief, not in post-shortlist review. Putting them in early means the sourcer rules out conflicted candidates instead of surfacing them and waiting for you to catch the conflict. The audit trail is the same; the wasted candidate-research time isn't.

What a structured brief unlocks downstream

A brief in this shape lets any sourcer (a project manager at a network, an AI platform, or an internal research lead) do a few things they couldn't do with a one-liner:

• Decompose the work. Each sub-question becomes its own sub-search with its own company universe and screen.
• Defend rejections. When a candidate is excluded, the brief explains why (recency, geography, scope mismatch), so the rejection log becomes a usable artifact instead of a list of "didn't fit."
• Iterate cheaply. If the first shortlist misses, you don't rewrite the brief. You annotate which sub-question underperformed and the next pass refocuses on that perspective only.

That last one is the payoff. Most projects miss on the first shortlist. The ones that recover quickly recover because they can point at sub-question 2, not start over.

What changes when the brief is structured

Teams that adopt this template notice a few things over a year of projects:

• Shortlist quality variance drops. Bad shortlists are usually upstream of bad briefs. A consistent brief shape collapses the variance.
• Reuse compounds. Company universes and title taxonomies from past projects become starting points for new ones. The brief becomes a reusable asset instead of a per-project rewrite.
• Compliance becomes easier. When the brief states exclusions explicitly, the audit trail on conflict checks writes itself: "we excluded X because the brief specified it."

The template doesn't depend on the technology behind your sourcing. Run it against any network. It works better against systems that can actually act on the structure (semantic search over a company universe, screening prompts derived from sub-questions, conflict rules tied to exclusion criteria), but it doesn't require them.

The honest evaluation question for any sourcing tool is how much of the brief it actually uses, versus how much it collapses back into a keyword search.