The Buying Permissions Map with Engagements, Pains, and Proof

What it is

A single-page working artifact that names how a deal actually moves inside an ICP account, which roles play which parts, and what each of them needs to say yes. Replaces the demographic persona one-pager.

Definitions you will need

Buying permissions. A behavioral model of how a deal moves through an account. Four roles: who approves (formal authority to sign), who champions (does the internal selling), who blocks (can stop the deal without holding approval authority), and who must be neutralized (has political reasons to prefer a different outcome).

Engagements, pains, and proof. For each role, three questions. Engagements: what they are trying to get done in their work, regardless of whether you exist. Pains: the specific frictions, costs, and failures they encounter doing the job today. Proof: what evidence would convince them you are the answer.

Practitioner mode and executive mode. Two modes that different roles operate in. Practitioners (SecOps, detection engineers, security architects) trust peers, hands-on proof, and technical depth. Executives (CISOs, CIOs, CFOs, board) trust business cases, analyst validation, and defensible narratives.

How to use it

Build one map per ICP segment. For each of the four buying-permission roles, fill in the fields below. Where you do not know the answer, leave it blank rather than guessing — blank fields are research priorities. The map is finished when a seller could read it and know exactly what to ask, what to send, and what to push back on for each role in a real deal.

The template

For each role — approver, champion, blocker, neutralize — fill out:

1. Typical title or titles. The actual job title or titles this role most often holds in your ICP. Be specific. "Director of Security Operations" beats "security leader."
2. Mode. Practitioner or executive. Some roles are mixed; pick the dominant mode and note when it shifts.
3. Primary job. The one or two things this person is trying to get done in their quarter that this purchase touches. Stated in their language, not yours.
4. Testable pain. The specific friction, cost, or failure that creates the opening for your product. "Testable" means a buyer would either confirm or reject the framing in a discovery call. "Alert fatigue" is not testable. "My SOC analysts are triaging four hundred alerts a day, eighty percent of which are false positives, and we've lost two analysts in the last six months to burnout" is testable.
5. Required proof. What this role specifically needs to see to move from interested to convinced. Different by role and by mode.
6. Current access. Whether your sellers, marketing, or content currently reach this role at all — and if so, through what channel, with what frequency, and with what content.
7. The gap. The single biggest mismatch between what this role needs and what you currently provide.

A worked example

For a cloud security platform selling into the global enterprise segment, the champion field might look like:

How to read the output

A complete map should produce three things:

1. Clear picture of which roles you reach well and which you are missing — almost every map has at least one role with significant Current access gaps.
2. A proof inventory: across the four roles, what proof is required, and what you actually have. The gap between required and available proof is most of your content roadmap.
3. A sales enablement brief: a seller using this map should know who to ask for in discovery, what pain to probe for, what proof to send, and which role is most likely to slow the deal.

A common failure mode: the map is filled out for the approver and champion but left empty or thin for blocker and neutralize. Most security PMM functions over-invest in the approver and champion (because they want to win the deal) and under-invest in blocker and neutralize (because thinking about them is uncomfortable). The deals you lose late-stage are almost always lost in the roles you didn't map.