Pain Points, Use Cases & Voice of Customer

Once you know who your customers are, the next questions are what’s hurting them and what they’re trying to get done. Three terms carry that conversation: a pain point (what’s wrong), a use case (what they’re trying to accomplish), and voice of customer (their own words about both). They feed each other, and good teams keep all three in view at once.

A pain point is a specific, felt problem

A pain point is a concrete frustration a customer experiences while trying to get something done. The key word is specific. “Our product should be better” is not a pain point. “It takes me four clicks and a two-minute wait every time I export a report, and I do it twelve times a day” is. A real pain point has a who, a when, and a cost — it tells you who feels it, in what situation, and what it costs them in time, money, or stress.

Pain points come in flavours: friction (slow and annoying), cost (wasteful), and risk (it might fail or get me in trouble). A useful habit is to ask “and what does that cost you?” until you hit something measurable. “The dashboard is confusing” becomes “I rebuild last month’s number in a spreadsheet every Monday” — now you know the pain and its price.

Beware fake pain points. A request for a specific feature is often a guessed solution wrapped around a hidden pain. If a customer says “add a dark mode,” the real pain might be “the screen hurts my eyes during night shifts.” Chase the pain, not the feature, and you usually find a better fix.

A use case is a goal someone is trying to reach

A use case describes a situation in which someone uses your product to accomplish a goal. The clean way to phrase one is actor + goal + outcome: a regional manager (actor) wants to compare this month’s sales to last month’s (goal) so she can decide where to send extra staff (outcome). Notice it says nothing about buttons or screens — a use case is about the job, not the interface.

Use cases matter because the same product serves many of them, and they can pull in different directions. A note-taking app might serve “jot a quick idea on my phone” and “write a long structured document” — and optimising hard for the first can make the second worse. Naming your use cases lets a team decide which ones to nail and which to merely tolerate.

How pain points and use cases relate

A pain point is usually a use case gone wrong. Take the use case “send the monthly report to my boss.” The pain point is “exporting it takes forever and the formatting breaks.” Pair them and you get a crisp problem statement: for the actor doing this job, here’s exactly where it hurts. That pairing is the raw material for almost every product decision.

A use case is what the customer is trying to do. A pain point is where that attempt hurts. Always tie one to the other.

Voice of customer is their words, not yours

Voice of customer (often shortened to VoC) is the customer’s own language about their needs, gathered straight from the source: interviews, support tickets, sales-call notes, app-store reviews, survey free-text, and social posts. It matters because teams are fluent in their own jargon and quietly assume customers think the same way — they rarely do. VoC keeps you honest. If users keep writing “I just want to undo that,” and your menu says “revert transaction,” that gap is worth knowing.

The discipline of VoC is to quote rather than paraphrase. “Customers are frustrated by latency” is your summary; “I click save and then just sit there wondering if it worked” is their voice — and the second is far more useful for both spotting the pain and naming the use case.

Spot it: pain point, use case, or VoC?

Read each situation and decide for yourself, then tap a card to flip it and check your answer.

Sort the statements

Drag each item into the bucket it belongs to — or tap an item, then tap a bucket. Hit Check placement when you’re done.

How to use it

When you’re handed a request, slow down and separate the three layers: what are they trying to do (use case), where does it hurt (pain point), and what exactly did they say (voice of customer). A few phrases that work in real meetings:

• “What’s the use case here — what are they actually trying to accomplish?” (stops feature debates that skip the goal)
• “That’s a solution. What’s the underlying pain point?” (digs past a guessed feature)
• “Do we have voice-of-customer quotes, or are we paraphrasing?” (keeps the customer’s own words in the room)
• “And what does that pain cost them?” (turns a vague complaint into a measurable one)

Keep the customer’s words on the table and tie every pain to a real job, and your proposals will land as solving something real rather than scratching an imagined itch.