itk-painstorming

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

1. Identify an initial set of ideal users in the P block, perhaps using the Personas tool as a source of inputs.
2. Observe and/or interview the users to answer the questions identified in the A, I, and N blocks in the PAINstorming table.
3. 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

• PDF: Download
• Markdown Template: template.md

Metadata

Field	Value
ITK Phase	UNDERSTAND
Difficulty	Beginner
Group Size	2+ people
Time Required	30+ minutes
Source	itk.mitre.org