| name | itk-painstorming |
| description | PAIN stands for Persona, Activities, Insights, and Needs – the four main research topics explored in this structured method for gathering insights about users or user identities. |
| intent | Improve the team’s understanding of the user’s behaviors, pain points, assumptions, and needs. Focus the team on addressing actual user preferences. Explore assumptions and identify the unknown gaps about users. |
| type | component |
| phase | understand |
| outcome | understand |
| difficulty | beginner |
| group_size | 2+ people |
| time_required | 30+ minutes |
| best_for | ["Early discovery when you need structured user understanding before committing to a problem statement or solution direction","Validating or replacing persona assumptions with observed behavior before writing PRD requirements","Preparing for user interviews by defining what activities, insights, and needs to probe per persona","Aligning a cross-functional team on who the real user is when stakeholders hold conflicting user models","Building the evidence base for Jobs-to-be-Done framing ahead of roadmap or OKR planning"] |
| sources | ["MITRE Innovation Toolkit (ITK)","https://itk.mitre.org/toolkit-tools/painstorming/"] |
PAINStorming
What Is It
PAIN stands for Persona, Activities, Insights, and Needs – the four main research topics explored in this structured method for gathering insights about users or user identities.
Why Use It
Improve the team’s understanding of the user’s behaviors, pain points, assumptions, and needs. Focus the team on addressing actual user preferences. Explore assumptions and identify the unknown gaps about users.
When to Use It
When you need to better understand user identities, activities, and difficulties.
How to Do It
- Identify an initial set of ideal users in the P block, perhaps using the Personas tool as a source of inputs.
- Observe and/or interview the users to answer the questions identified in the A, I, and N blocks in the PAINstorming table.
- Use this data to ensure that any proposed products, services, or interventions are aligned with actual user preferences.
Key Concepts
Persona (P) — A representative user identity grounded in shared characteristics, goals, and context. It anchors the rest of the analysis so insights stay tied to a specific user rather than a vague 'everyone'.
Activities (A) — The concrete tasks and behaviors the persona performs in their real environment. Capturing actual activities prevents the team from designing for an idealized workflow that users don't follow.
Insights (I) — Non-obvious observations about motivations, frustrations, and workarounds discovered through research. Insights translate raw behavior into the 'why' that drives meaningful product decisions.
Needs (N) — The underlying problems and desired outcomes the user is trying to satisfy, independent of any specific solution. Needs map directly to opportunity areas and JTBD outcome statements.
Assumption vs. Evidence — The distinction between what the team believes about users and what research has confirmed. PAINstorming's value collapses if blocks are filled from opinion rather than observation or interviews.
Pain Point — A specific friction, blocker, or unmet need the persona experiences during their activities. Surfaced pain points become candidate problems to prioritize in discovery and the backlog.
PM Applications
- Use it during a discovery sprint to structure user interviews, mapping each interview into the A, I, and N blocks so findings translate directly into validated needs.
- Build a PAINstorming table per primary persona to populate the 'user problems' and 'target users' sections of a PRD with evidence rather than assertions.
- Translate the Needs and Insights blocks into Jobs-to-be-Done statements and opportunity solution tree branches before roadmap prioritization.
- Run it as a pre-mortem on persona assumptions ahead of backlog grooming, flagging which user stories rest on untested beliefs versus research.
- Create multiple PAINstorming tables across stakeholder segments to inform OKR target-user definitions and ensure outcomes address real pain points.
- Use the completed tables as a stakeholder briefing artifact to align engineering, design, and leadership on a shared, evidence-backed user model.
Benefits
- Helps generate thoughtful insights into the needs, priorities, and pain points for various users. Make several of these to represent a wide swath of stakeholders.
Common Pitfalls
- Filling the A, I, and N blocks from team intuition instead of interviews or observation, producing a confident but fictional user that misdirects the roadmap.
- Treating Personas as the output rather than the input — skipping the research step yields a superficial sketch that can't justify prioritization decisions.
- Conflating Needs with solutions (writing 'needs a dashboard' instead of 'needs to assess status at a glance'), which prematurely locks in design and narrows the solution space.
- Creating a single generic persona that averages across distinct user segments, masking the conflicting needs that should drive separate roadmap bets.
- Capturing activities at too high a level ('manages projects') so no actionable pain points emerge, leaving the Insights block empty of anything decision-relevant.
- Producing the tables once and never revisiting them, so they ossify into stale assumptions while actual user behavior and the product context evolve.
Combine With
Journey Mapping Storyboarding Personas
Assets
Metadata
| Field | Value |
|---|
| ITK Phase | UNDERSTAND |
| Difficulty | Beginner |
| Group Size | 2+ people |
| Time Required | 30+ minutes |
| Source | itk.mitre.org |
