Building a Persona Matrix Reps Will Actually Use

A typical persona doc describes someone's day, their goals, and a stock photo. None of that helps a rep on a call decide what to say next. It reads like it was written to satisfy a marketing checklist rather than to be opened mid-conversation.

The version that gets used is short enough to scan on a phone between meetings and specific enough that a rep can pull a line straight from it without editing.

Pain: the specific, named problem this role deals with, not a vague theme like "efficiency." KPI: the metric this person is measured on that the pain threatens, since a problem only motivates action when it's tied to something they're accountable for. Hook: a single sentence a rep can say or write that connects the two without sounding like a pitch.

A row that only has a pain column, with no KPI and no hook, isn't finished. It's a note for later, not something a rep can act on today.

What each row of the matrix should contain:

• Pain: a specific, named problem this role deals with, not a vague theme like efficiency, and one that has come up in a real discovery call.
• KPI: the metric this person is personally measured on that the pain threatens, since a problem only drives action when it is tied to accountability.
• Hook: one sentence a rep can say or write that connects the pain to the KPI without mentioning the product.
• Format: short enough to scan on a phone between meetings, so a rep can pull a line straight from it without editing.
• Owner: one named person who updates the rows after each quarterly review of closed-won and closed-lost deals.

Pull directly from discovery call notes and win-loss interviews, not from what seems intuitively true about a role. The pains that show up in real conversations are often narrower and stranger than the ones a team guesses at in a planning meeting.

If a pain has never actually come up in a real call, it doesn't belong in the matrix yet, no matter how logical it sounds on paper. Add it once you've heard it from an actual buyer, and note which specific deal or interview it came from, so anyone questioning the row later can trace it back to a real conversation instead of a guess.

A pain becomes urgent to a buyer when it threatens something they're personally evaluated on. A messy pipeline is a mild annoyance to a rep and a real problem to a manager whose forecast accuracy gets reviewed by leadership every month.

For each pain row, write down the specific metric the person in that role is held accountable for, and check that the pain genuinely threatens it. If you can't draw that line clearly, the pain probably isn't the right one for that particular role.

A hook is one sentence that names the pain and implies the KPI, without a product mention. For a RevOps manager, a row about broken pipeline coverage reporting might turn into: "When your coverage numbers don't match what reps actually have in play, forecast reviews turn into a guessing game."

The average B2B new-logo win rate sits around 19%¹, and a hook grounded in a real pain and a real KPI, rather than a generic value statement, is one of the more reliable ways a team actually moves that number for its own pipeline.

Revisit the matrix every quarter against the most recent closed-won and closed-lost deals. A pain that was accurate a year ago can quietly stop landing once your buyer's priorities or tooling shifts, and nobody notices until reply rates drop across the board.

Assign one person to own updates, even if it's a fifteen-minute task after each deal review, so the matrix reflects what buyers are actually saying now rather than what they were saying when it was first built. A stale matrix is worse than no matrix at all, since reps keep using hooks that quietly stopped working without anyone flagging why replies dropped.