A buying committee map is supposed to answer one question: if this purchase happens, who has to say yes, and in what order. Most maps answer a different question — who has an impressive title — and then decorate it with words like champion and blocker that nobody has evidence for.
The useful version is smaller and duller than the deck version, and it is built from things you can point at.
Four roles, not a hierarchy
Seniority is a poor organising principle here, because the person who stops a deal is frequently four levels below the person who starts it. The four roles worth separating:
Who owns the problem
The person whose week is worse because the problem exists. They are the only one with a reason to spend political capital on you, and if you cannot name them, you do not have a deal — you have interest.
Who owns the budget line
Not “who could afford it”. Whose specific line it comes out of. This is usually visible in how the function is organised: if engineering tooling sits under a platform group, the platform lead holds the line, whatever the CTO says in a first meeting.
Who can veto
Security, legal, procurement, data protection. They rarely appear in the first conversation and frequently decide the outcome. Their existence is usually public — a named DPO, a security page, a supplier onboarding process on the website — and finding them before the call is much cheaper than meeting them in month three.
Who will operate it
The team that lives with the thing afterwards. They have no formal authority and a total practical veto, because a tool the operators resent does not survive its first renewal.
If you cannot name who owns the problem, you do not have a deal. You have a conversation that someone is enjoying.
What is genuinely knowable in advance
| Question | Knowable before contact? | Where from |
|---|---|---|
| Does the function exist at all? | Usually yes | Team pages, job postings, conference speaker lists, filings. |
| Who leads it? | Often | Company site, announcements, public talks, regulatory filings. |
| Where does it report? | Sometimes | How postings describe the reporting line; how the org is grouped on the site. |
| Who signs at this value? | Rarely | Occasionally inferable from public procurement rules; otherwise ask. |
| Who is the champion? | No | This is a property of a relationship that does not exist yet. |
| Who will block, and why? | Partly | Security and DPO pages tell you the process. They do not tell you the person's disposition. |
Sources that hold up
- Job postings — the most under-read source there is. They name the reporting line, the tools in use, and the problem the team is being hired to solve.
- The company's own team, security and legal pages, which describe the process you will have to pass through.
- Conference and podcast appearances, where people describe their remit in their own words.
- Regulatory and corporate filings, for officers and, in some jurisdictions, for signing authority.
- Public procurement records, where the buying process itself is documented.
What is absent from that list is a professional network scraped in bulk. Beyond the terms-of-service question, in the EU processing that data for outreach requires its own lawful basis and a notice to the person — and the structural picture it gives you is available from sources that carry neither problem. Our position on what we will and will not do with personal data is on the evidence standard page.
Treat the map as perishable
Reorganisations and departures make committee maps go stale faster than almost any other research artefact. A map built in January and used in June will have at least one wrong name in it, and the wrong name will be the one you address the email to.
The practical response is to date every element and re-check the leader of the function before contact, not the whole map. That single check catches most of the damage for a fraction of the effort.
In Leads, the committee comes back attached to the company with each role sourced and dated, and the parts that could not be established come back empty rather than filled with a confident guess. An empty field is a smaller problem than a wrong one, because a rep can see it.