Why Your People Search Returns the Wrong People, and How to Rewrite the Query
There is a specific kind of frustration that comes from a search tool doing exactly what you asked. You typed a request, you got fifty results, and every one of them is technically correct and practically useless. The instinct is to blame the tool. Usually the request is at fault.
Natural-language search changed what a query is. On a filter-based platform you pick from what the form offers, so the tool's schema does your thinking. On an AI people search platform you write the request yourself, which means the quality of your description now sets the ceiling on the quality of the results. That is a real skill, and almost nobody was taught it.
Filters describe records; a good query describes a person
A filter set is a description of database columns: title contains, headcount between, country equals. It can only express what someone decided to store. The person you are actually looking for is not a row of columns, though. They are a role plus a situation plus a piece of timing.
VP of Engineering, 200-500 employees, United States
That query returns thousands of people, ranked by nothing in particular. It describes a shape, not a person. Compare it to a description of the same target that includes the situation:
VP of Engineering at US companies that raised a Series B in the last year and are hiring backend engineers now
Same role, same rough company profile, but the second version carries two time-bound signals. Those signals are what turn a list into a shortlist, and they are exactly what a filter form cannot express.
Three rewrites that change the result set
Add the trigger, not just the target. Most searches describe a steady state when what you want is a change of state. "Head of Growth at e-commerce brands" is a category. "Head of Growth at e-commerce brands who moved into the role in the last six months" is a moment, and a new owner rebuilding a stack is a materially different prospect from one who signed a three-year contract last spring.
Replace adjectives with evidence. Words like "senior," "innovative," or "technical" are unfalsifiable and the model will happily invent a justification for anything. Say what would count as proof instead: open-source contributions in a specific language, conference talks in a named year, a published paper, a documented migration. Evidence is checkable. Adjectives are decoration.
Say what disqualifies someone. Search requests are almost always written as pure inclusion, and the exclusions live in your head. Write them down. Not currently at an agency. Not a consultant. Not someone who already churned out of your product. Every unstated exclusion becomes results you have to hand-filter later, which is the work you were trying to avoid.
When the results look confident and wrong
Any system that ranks people will sometimes produce a match that looks great and is not. This is the failure mode worth designing around, because a confidently wrong result costs more than an obviously bad one: you act on it.
Two habits keep it in check.
First, insist on stated reasoning. A result that shows why it matched is auditable, and a match score attached to an explanation can be argued with in a way a bare number cannot. If a platform tells you someone scored 94 and will not say on what basis, you are being asked to trust a black box with your outreach budget.
Second, check the freshest field rather than the flashiest one. Job titles decay. People change companies, get promoted, take a sabbatical, or move into a function that no longer needs what you sell. A profile that has not been refreshed in six months is a historical document, and the failure will not announce itself, because a stale title looks identical to a current one.
Judge a search engine on recall, not on its demo
Most evaluations of search tools test precision: are the results returned any good? That is the easier half, and it is the half a curated demo is designed to win. The harder and more valuable question is recall: of everyone who genuinely matched, how many did the tool surface at all?
Recall is where breadth of sources decides the outcome. If a platform indexes only one professional network, then everyone whose relevant presence lives on a code host, a funding database, a podcast, a conference roster, or a creator platform is invisible to it, and you will never know what you missed. Missing results are silent by nature, which is why the coverage question deserves more scrutiny than the accuracy question.
A practical way to test it: take five people you already know should match, from five different corners of the web, and see how many the tool finds. If it returns three of five, that is your recall estimate, and it is a far better predictor of value than the polished result set in any product tour.
The workflow that actually holds up
Treat a people search request the way you would treat a research brief. Describe the role, the situation, and the timing. State your evidence standard and your exclusions. Read the reasoning behind the top results rather than the scores. Verify contact details before sending anything, because a bounced message costs sender reputation across every campaign you run afterwards.
Then, and this is the step teams skip, rewrite the query once. The first result set is diagnostic information about your description, not just a list. Reading it tells you which assumption was too loose, and one revision usually improves the set more than any amount of downstream filtering.
Search stopped being a form to fill in. It is a description you write, and it rewards precision the way any research brief does. Platforms built on that assumption, Lessie among them, are worth trying mainly because they force the discipline on you.
