Pain Point

Every team already had a list of things to fix. The trouble was that each item on it got there for a different reason. The engineer wrote down the screen with the ugliest code behind it. The designer wrote down the button that looked wrong to them. Sales wrote down whatever a customer mentioned in passing on yesterday's call. Almost nothing appeared on more than one list, and all three people described their own items with the same word: annoying.

So prioritization meetings kept landing in the same place. Someone would ask whether a screen was frustrating, someone else would say it seemed fine to them, and from there the item belonging to the loudest voice or the highest title moved up. The evidence was taste, so the conclusion was taste too. When the fix shipped and the numbers didn't move, there was no way to say whose call had been wrong, because nobody had made a claim specific enough to be wrong about.

Pain point exists to narrow who gets to put an item on that list. The test is not whether anyone called something annoying. It's whether a customer's behavior actually broke at that spot. Once the idea had a name, two sentences that used to sound the same could be told apart in the same meeting: "this screen looks frustrating" and "62 of the last 100 people closed the tab here."

You find them by laying out the places a customer passes through in order, then checking each place for behavior that stopped. It takes four steps.

1. Write down the contact points in time order. Any place a customer meets the product or the brand is a touchpoint — a blog post in search results, a failed-payment text message, the sentence a support agent typed back. A full list usually runs to twenty-something items.
2. Look for three signals at each place. Does the customer stop there, go back to the previous screen, or route around the product entirely and get the job done some other way? If none of the three shows up, the place doesn't get marked, no matter how many people said it was annoying.
3. Attach a size to the signal. Funnel analysis, which shows how many people drop out at each step, produces numbers like 62 out of 100 invited people stalling on the sign-up screen. Without a size there is no way to order the list.
4. Write the cause as one sentence. Not "signing up is awkward" but "they saw a notice telling them to register again with a company address and closed the window." Whether the thing to fix is the screen, the wording, or the policy behind it gets decided in that sentence.

Numbers and observation each fill a different half. Numbers tell you exactly where behavior broke and say nothing about why. Watching a recording of the real session through session replay, or handing someone a task and watching where they stall in a usability test, supplies the why. Play back ten of the 62 stalled sessions and the cursor tends to stop on the same line of text in most of them.

The first place is prioritization, where a team decides what to do first with the capacity it has. Because every marked place carries a size, the list can be sorted, and the size then gets multiplied by how much that place shapes the customer's impression. A contact point where the impression hardens for good is a moment of truth, and the same 62 people stalling inside the first five minutes of use outranks 62 people stalling on a billing history page.

The second is onboarding design, the work of helping a new user settle in. Places marked in the first few days after sign-up usually come apart with one rewritten sentence or one deleted step, and the numbers move a lot relative to the effort spent.

The third is outside the product. The lines sales and marketing use land hardest when they repeat a frustration the customer already has. If "the colleague you invited has to create a whole new account" sits on the map as a marked place, that sentence becomes the opening line of the pitch deck without anyone having to invent it.

An empty list of marked places doesn't mean the product is flawless. It means nobody looked. Maps come out that way when a team has never sat with users to watch and ask, which is user research, and has never opened the pile of complaints already sitting in its voice of the customer channels.

"I can't tell whether this is a real pain point or just something that bugs us."

Asking whether the evidence is customer behavior or the team's own taste.

"The invite acceptance screen is the biggest one. 62 out of 100 people close it there."

Attaching a number to move that place to the front of the fix list.

"It's annoying, sure, but it's not a pain point. Everyone just puts up with it and moves on."

Pointing out that a complaint existing and behavior breaking are two different things.

At Pagedeck, Mia redraws the journey map every quarter. Last quarter the largest marked place was the invite acceptance screen. Noa found the cause by playing back twenty session recordings: invited colleagues were shown a notice telling them to register again with a company email address, and seven in ten read that line and closed the window.

Sofia arrived at the same place from a different direction. Team leads evaluating Pagedeck kept going quiet after inviting a colleague to try it, and because the map already had that spot marked, her account and Noa's recordings merged into a single item instead of two separate complaints.

The most common mistake is copying stated complaints straight onto the map. The customer said it out loud, so it feels like the strongest evidence available. But people are poor witnesses to their own behavior, and when asked why they stopped they will construct an answer on the spot. A team that transcribes its request list ends up fixing what a loud minority named, and after all of it ships the drop-off on the sign-up screen is exactly where it was. Use what people say as a lead, and decide what to mark by what they did.

The other one is treating an empty map as the goal. Twenty marks on a page look like twenty assignments. But frustrations people shrug off don't move any number when they're fixed, and some friction is there on purpose. A confirmation step before deleting an account is an obstacle, and the obstacle is what prevents an irreversible mistake. Teams that set out to clear all twenty spend a quarter producing no visible change, and start the next one with the single largest place still untouched.