top of page

The Deal with "Pain Points"


Complaints are not problems. Ergo, pain points are not problems.

A product group's response to a complaint in which the quest is to "fix" the "pain point" is a reaction. Reactions rarely tie to a business mission or a product strategy. A few months of fixing pain points and your product is wildly off-course.

The pain point concept comes from sales. A salesperson thinks, 'What does this person want, and how much does not getting what they want result in pain?'. Then the salesperson knows what to show a potential buyer and how to pitch it.

The design of products and services requires much more detail to define a problem, align possible solutions with business and technical objectives and capabilities, and then formulate and implement a satisfying experience.

Moreover, the term 'pain point' implies that if just one aspect of a product or service is fixed, the whole thing becomes golden and a thing is happily bought/adopted.

This is NOT the way product developers think. Users and consumers don't think this way either. A "pain point" comes from the perspective of a person gunning for their monthly sales numbers.

Sometimes during beta testing, a single issue of user discomfort arises that can be fixed with a simple change of color or button placement. Such fantasies are legend, though as with many legends, exact, true examples are hard to specify. They are nice songs to hear, though.

UX researchers, designers, and product managers/owners think systemically. We consider layers of flows of thinking and feeling. Well-crafted and appreciated things result.


One or more comments about a pain point can lead to a hypothesis that can be used to get to the bottom of the users' problem(s). That hypothesis, in turn, might lead to simple tests to understand the scope. The response could be fairly simple or it could be a rethinking of product strategy through consideration of a user's workflow or a systemic reboot. Put in the work and rewards will come.

bottom of page