Customer pain points analysis: the buyer's wording, not the record of it

Almost every guide on this subject ends in the same place: four or five families of pain, money, process, support and productivity, followed by an instruction to ask customers which family they feel. Both halves are reasonable. Neither answers the question that decides whether the analysis holds, which is where the sentences came from.

That question matters because pain arrives as text, and the text is usually written by somebody other than the person with the problem. Jakob Nielsen put the general version of this bluntly in Do Not Listen to Users (August 2001), reporting a correlation of only 0.44 between what people did in measured tasks and what they said they preferred. Sales conversations sit in a worse position than usability tests, because between the buyer and your spreadsheet there is a second author with a quota.

What follows is a way to build the analysis from the other end: start with what was said, group the wording, and only then decide what to call it.

A pain written down after the call is already a translation

The record of a conversation is produced by somebody who has to do something next with it. What gets typed is the version of the problem that the next step can use, which quietly pulls the wording toward the problems your product answers and away from the ones it does not. Nothing dishonest happens. The drift is structural, and because it is structural it is predictable.

We found the same drift inside our own code, in a place where no sales team could be blamed for it. One of our tables carries a field whose name translates as the client's main pain. For a long stretch, what it held was an assessment of how the rep had performed on the call. The field was named after the buyer and filled with a judgment about the seller, and every screen that read it inherited the mix-up without anything looking broken.

The fix was not a better instruction for the same field. It was a separate generation step whose only job is to write four values from the buyer's side: the pain, a tag for it, the motivator, a tag for that. Reading the old values beside the new ones was the uncomfortable part. They were not two wordings of one finding. They were statements about two different people, sitting in the same column.

A default worth starting from, if you keep both kinds of text: write the rule for what belongs in the buyer field and what belongs in the conversation-assessment field before you build anything that reads them. Two fields you can only tell apart by reading them will be mixed inside a quarter, and the mixing is invisible until somebody compares a card against the call behind it.

Asking buyers to name their pain hands them your list back

Direct questions are worth asking, but a question that offers categories gets the categories back. This is measured, not folklore. Pew Research Center's guide to writing survey questions records a 2008 case where the economy was offered as an explicit answer option and 58% of respondents chose it, while only 35% raised it on their own when the same question was asked open. Same subject, same public, different instrument.

The mechanism is not that people lie. It is that a list tells them what kind of answer you want. Maria Rosala makes the same point for research interviews in Open-Ended vs. Closed-Ended Questions (January 2024): closed questions stop the conversation, and questions that start with did, was or is reveal what the asker is interested in and prime the answer toward it.

Carried into discovery, that means the pain menu you hand a prospect is a survey instrument, and you built it out of last year's positioning. If integration was the third item on your list and it comes back third in your analysis, you have measured your own list. The way out is cheap: in the first pass, count only what the buyer raised before anyone named a category, and keep prompted answers in a second column that never merges with the first.

Put your own category list beside what your buyers actually said.

Three records of the same problem, and only one of them is in the buyer's words

Any pain you act on has reached you in at least three forms by then, and they are good for different things. Confusing them is what produces an analysis that reads well and cannot be checked. The table below is worth keeping next to whatever tool you use to count.

The third row is where most pain analysis starts, which is why so much of it collapses under one question at a review. A label can be counted. It cannot be checked against anything. The second row is genuinely useful for forecasting and for routing, and useless as copy, because the wording in it was chosen by somebody selling.

The first row is the one you write pages and scripts from. It is also the only one that lets an argument about a pain group end, because the group either produces a sentence or it does not. The same logic applies when you build a tagging scheme on top of it, which is its own trap worth reading separately: what 424 objection labels looked like after they were grouped.

An invented example, written to show the shape rather than quote anyone. The buyer says something like: we tried this two years ago, the person who set it up left, and nobody could tell me afterward what it was doing. The note says: legacy tooling, needs migration support. The dashboard says: process. All three are true. Only one of them tells you what sentence to put on a page.

Group the wording first, name the category after

The order matters more than the taxonomy. Start from utterances, cluster them by how buyers phrase the problem, and name a cluster only once it exists. Naming first means you built bins and then went looking for things to put in them, which is how every analysis ends up confirming the positioning that produced the bins.

Three decisions carry most of the weight, and each has a default that is better than deliberating.

Pain is one input into a wider program built on recordings you already keep, and the rule below is the part of it that took us longest to get right. The second row is a rule we had to make explicit in our own system. When Spellit ClientTruth picks the conversation to show for a pain, it picks the one holding the longest client utterance on that subject, on the reasoning that this is the buyer's pain rather than the seller's phrasing of it. It sounds like a detail. In practice it changes which conversation a marketer reads, and therefore which words end up on a page.

Worth saying plainly, because the category invites the assumption: this is not interview software. No panel is recruited and no survey goes out. The material is conversations that already happened, which is a real limit as well as the point. If a problem never came up on a call, no amount of analysis of calls will find it.

Representativeness is the part people skip, and it is the same problem quality teams have with sampling. If the calls you can read are the ones that got recorded, and recording skews toward one team or one deal size, your pain groups inherit that skew. The reasoning is worked through in how sampling decides what a quality program can see, and it transfers directly.

The pain list rebuilt from buyer sentences, side by side with the one you have now.

A pain group with no sentence under it is a hypothesis

A finding and the evidence for it are two separate objects, and a system that shows the first without the second produces confident, unfalsifiable reading. We shipped exactly that. The client card in our own product displayed the main pain and the motivator as finished statements, and there was no way to get from the statement to the moment it came from.

What closed it was not a better model. It was a plain, deterministic step added to the pipeline whose single job is to attach, to each conclusion on the card, the verbatim buyer line, the lines either side of it, and the identifier of the call with a timecode. Before that step existed, the card was persuasive and impossible to check. After it, the card can be wrong in a way somebody can demonstrate, which is a better position than being unchallengeable.

The lesson generalizes past software. The first question anyone asks of a pain summary in a room with budget in it is where this came from, and the answer has to be a sentence, not a methodology. If you keep your analysis in a spreadsheet, that means a column holding the actual line and a link to the recording, filled in before the row gets a category, not after.

It also gives you an honest way to carry groups you cannot yet prove. Label them. A group marked as four mentions, no clean quote yet is useful: it tells the next person where to look. A group that silently looks identical to a well-evidenced one is worse than no group at all, because it spends the same credibility and cannot repay it.

Buyer wording changes the script before it changes anything else

The first artifact to move is the answer a rep gives. When a pain group has a dominant phrasing, the response can be written in words that echo it rather than in words that echo the category. Answering process friction and answering the sentence about the person who set the thing up and then left are two different replies to the same buyer, and only one of them sounds like it came after listening.

Pages move next, and they move cheaply. Copy written from category labels reads like every competitor's copy, because everyone owns the same four labels. Copy written from clustered utterances reads like somebody was in the room. No new collection is involved, only a different source for the headline.

The roadmap moves last and is worth the wait. The strongest signal available is a request that went unanswered on the call: the buyer asked for something and nothing came back. That is a product gap with a date and a witness attached, and it sorts itself by how many separate buyers produced it. The list it yields overlaps less with the feature requests arriving through support than most teams expect, and the places where the two disagree are the ones worth an argument.

Keeping the three in sync is a review problem rather than an analysis problem, and it belongs in whatever cadence already exists for reading conversations. If no such cadence exists, that is the thing to fix first: a review process that produces decisions rather than scores is the container the pain analysis lives in. The counting side, the part that turns conversations into comparable rows, sits in Spellit Actions.

What to do next

Take ten calls from last month where the deal is still open. For each one, write down the single sentence in which the buyer came closest to stating their problem in their own words, with the timecode. Do not categorize yet. Ten sentences in a document, nothing else.

Then open your current pain list, the one in the deck or on the positioning page, and put it beside the ten sentences. Mark each list item that at least one sentence supports. The items with nothing beside them are the ones to argue about this week, and the sentences that fit no item are the ones worth a new row.

That exercise takes under an hour and settles more than a quarter of workshop does, because it replaces opinions about buyers with a short list of things buyers said. Finding out which half of your pain list nobody ever said out loud takes one sitting.