Product teams often ask users what they want. Better product teams uncover what hurts using the PAINS framework: Physical, Assurance, Inclusion, Name, and Success.
PAINS adapts Maslow’s hierarchy of needs into product language, while staying practical enough to use in defining opportunities. PAINS is also a useful companion to Jobs to Be Done. JTBD explains what the user is trying to accomplish, while PAINS helps reveal what is making that job painful or important enough to solve.
Physical asks whether the basic need is met. For an enterprise product, it means, “Does the feature actually work for real workflows, data, people, and organizational context?”
Assurance asks whether the user feels safe and confident. An enterprise buyer wants security, privacy, access control, compliance, reliability, and auditability.
Inclusion asks whether the product fits the user’s world. In enterprise software, it includes accessibility, localization, integrations, APIs, and compatibility with the customer’s existing tech stack and market ecosystem.
Name is the esteem layer. It is about credibility, competence, and being seen as capable. An enterprise champion asks, “Can I defend this purchase, show value, and look credible to leadership?”
Success asks whether the product helps the user reach the larger goal over time. For an enterprise, success is adoption, scale, extensibility, maintainability, and measurable business value.
The distinction between Name and Success matters. While Name is about perception and credibility, Success is about durable outcomes. For example, a dashboard can help a champion prove value and showcase their competence, which is Name. The same dashboard can help a team improve rollout and adoption, which is Success.
Latent needs
PAINS should uncover both obvious pains and latent needs. Obvious pains are what users already complain about. Latent needs are hidden because users have accepted something as normal.
For each PAINS bucket, ask what the user may have stopped questioning the status quo. What basic work feels impossible, too hard, or too slow? Where do users tolerate uncertainty because they have no reliable way to know what is happening? Who is excluded because the activity requires money, credentials, location, language, or technical skill? Where do users quietly want to look more capable? What larger outcome becomes possible once an old constraint is removed?
PAINS is useful because it catches needs that are easy to miss. Teams naturally focus on the core feature, while enterprise customers care about surrounding requirements such as administration, privacy, infosec, compliance, business impact, interoperability, scale, and SLA.
Breakthrough products often reveal latent needs. Once users experience the new capability, the old workaround feels unacceptable.
PS: I write about building products to pay it forward and to sharpen my thinking.