PERSONAS
What Is It
A descriptive model of a person (user, stakeholder, team member, etc), this tool is most often used to help a team define and understand the needs of its customer.
Why Use It
Understand users’ needs, motivations, limitations, and capabilities. Represent the full range of diversity among stakeholders, customers, or other groups. Ensure the final product is something a human being will need or want.
When to Use It
When exploring new ideas or potential applications.
How to Do It
- Assemble existing research into current or potential users.
- As needed, add your own evidence and data to the existing research by observing, interviewing, and/or profiling potential users. Be sure the cohort of users you interview represent the full diversity of your user group.
- Build a collection of user archetypes, based on various categories of users. Give each one a specific name (e.g., Acquisition Amy), rather than a generic title (e.g., Military Technologist), and ensure each Persona represents a unique use-case. TIP: The most useful personas are specific, not general. For example, rather than creating a persona of a “military member,” specify the persona’s service (Army, Navy, Air Force, Marine), rank, specialty, level of experience, etc.
- Add a stock photo or cartoon sketch of the described personas. You may want to add an invented quotation that summarizes a key issue, concern, or priority for the persona.
Key Concepts
Archetype vs. Stereotype — A persona is a research-grounded composite of real behaviors and goals, not a demographic caricature. Stereotypes built on assumptions produce decisions that fail the actual user base.
Goals and Motivations — The core of a persona is what the user is trying to accomplish and why, not their job title. This maps directly to Jobs-to-be-Done and drives feature prioritization.
Specificity Principle — Useful personas are narrow (rank, specialty, experience level) rather than generic ('military member'). Specificity forces concrete design tradeoffs instead of designing for an impossible everyone.
Primary vs. Secondary Personas — One persona should be the primary design target whose needs the product must satisfy; secondary personas are accommodated but never drive core decisions. Without this hierarchy, scope balloons.
Diversity Coverage — The persona set must span the real range of users — edge cases, accessibility needs, varied expertise — so the product isn't optimized only for the loudest or most convenient cohort.
Evidence Grounding — Every persona attribute should trace back to observed data from interviews, analytics, or field research. Invented quotes and traits are acceptable only as summaries of real patterns, not fabrications.
PM Applications
- Anchor the 'target user' and 'user needs' sections of a PRD so feature decisions reference a named persona rather than an abstract 'the user'.
- Frame user stories and acceptance criteria around a specific persona's goals, replacing generic 'As a user' with 'As Acquisition Amy' to expose real edge cases.
- Drive segmentation in discovery sprints by mapping which personas a proposed feature serves and which it ignores, informing scope cuts.
- Resolve backlog grooming disputes by evaluating competing requests against the primary persona's documented goals and pain points.
- Support roadmap reviews and executive briefings by giving stakeholders a memorable, evidence-backed face for the customer base instead of raw segment data.
- Pair with journey mapping to walk a persona through an end-to-end workflow, surfacing friction points that become epics or OKR targets.
Benefits
- A light-weight representation of a user / sponsor / stakeholder can help build empathy for the people who benefit from the work or are otherwise involved.
Common Pitfalls
- Building personas from internal assumptions instead of research, producing a flattering fiction that validates the roadmap you already wanted to build.
- Creating too many personas (8+) so none is treated as primary, leaving the team designing for everyone and satisfying no one.
- Loading personas with irrelevant demographic detail (favorite hobbies, pet names) that adds color but never informs a single product decision.
- Treating personas as a one-time deliverable that gets archived after a workshop, so they never update as analytics and new research contradict the original assumptions.
- Writing personas so generic ('busy professional') that they justify any feature, eliminating their power to force prioritization tradeoffs.
- Failing to tie persona goals to measurable behaviors, so the team can't validate whether the persona's needs are actually being met in production.
Combine With
Journey Mapping Storyboarding
Assets
- PDF: Download
- Markdown Template: template.md
Metadata
| Field |
Value |
| ITK Phase |
UNDERSTAND |
| Difficulty |
Intermediate |
| Group Size |
6+ people |
| Time Required |
45+ minutes |
| Source |
itk.mitre.org |
1---2name: itk-personas3description: A descriptive model of a person (user, stakeholder, team member, etc), this tool is most often used to help a team define and understand the needs of its customer.4---56# PERSONAS78## What Is It910A descriptive model of a person (user, stakeholder, team member, etc), this tool is most often used to help a team define and understand the needs of its customer.1112## Why Use It1314Understand users’ needs, motivations, limitations, and capabilities. Represent the full range of diversity among stakeholders, customers, or other groups. Ensure the final product is something a human being will need or want.1516## When to Use It1718When exploring new ideas or potential applications.1920## How to Do It21221. Assemble existing research into current or potential users.232. As needed, add your own evidence and data to the existing research by observing, interviewing, and/or profiling potential users. Be sure the cohort of users you interview represent the full diversity of your user group.243. Build a collection of user archetypes, based on various categories of users. Give each one a specific name (e.g., Acquisition Amy), rather than a generic title (e.g., Military Technologist), and ensure each Persona represents a unique use-case. TIP: The most useful personas are specific, not general. For example, rather than creating a persona of a “military member,” specify the persona’s service (Army, Navy, Air Force, Marine), rank, specialty, level of experience, etc.254. Add a stock photo or cartoon sketch of the described personas. You may want to add an invented quotation that summarizes a key issue, concern, or priority for the persona.262728## Key Concepts2930**Archetype vs. Stereotype** — A persona is a research-grounded composite of real behaviors and goals, not a demographic caricature. Stereotypes built on assumptions produce decisions that fail the actual user base.3132**Goals and Motivations** — The core of a persona is what the user is trying to accomplish and why, not their job title. This maps directly to Jobs-to-be-Done and drives feature prioritization.3334**Specificity Principle** — Useful personas are narrow (rank, specialty, experience level) rather than generic ('military member'). Specificity forces concrete design tradeoffs instead of designing for an impossible everyone.3536**Primary vs. Secondary Personas** — One persona should be the primary design target whose needs the product must satisfy; secondary personas are accommodated but never drive core decisions. Without this hierarchy, scope balloons.3738**Diversity Coverage** — The persona set must span the real range of users — edge cases, accessibility needs, varied expertise — so the product isn't optimized only for the loudest or most convenient cohort.3940**Evidence Grounding** — Every persona attribute should trace back to observed data from interviews, analytics, or field research. Invented quotes and traits are acceptable only as summaries of real patterns, not fabrications.414243## PM Applications4445- Anchor the 'target user' and 'user needs' sections of a PRD so feature decisions reference a named persona rather than an abstract 'the user'.46- Frame user stories and acceptance criteria around a specific persona's goals, replacing generic 'As a user' with 'As Acquisition Amy' to expose real edge cases.47- Drive segmentation in discovery sprints by mapping which personas a proposed feature serves and which it ignores, informing scope cuts.48- Resolve backlog grooming disputes by evaluating competing requests against the primary persona's documented goals and pain points.49- Support roadmap reviews and executive briefings by giving stakeholders a memorable, evidence-backed face for the customer base instead of raw segment data.50- Pair with journey mapping to walk a persona through an end-to-end workflow, surfacing friction points that become epics or OKR targets.5152## Benefits5354- A light-weight representation of a user / sponsor / stakeholder can help build empathy for the people who benefit from the work or are otherwise involved.5556## Common Pitfalls5758- Building personas from internal assumptions instead of research, producing a flattering fiction that validates the roadmap you already wanted to build.59- Creating too many personas (8+) so none is treated as primary, leaving the team designing for everyone and satisfying no one.60- Loading personas with irrelevant demographic detail (favorite hobbies, pet names) that adds color but never informs a single product decision.61- Treating personas as a one-time deliverable that gets archived after a workshop, so they never update as analytics and new research contradict the original assumptions.62- Writing personas so generic ('busy professional') that they justify any feature, eliminating their power to force prioritization tradeoffs.63- Failing to tie persona goals to measurable behaviors, so the team can't validate whether the persona's needs are actually being met in production.6465## Combine With6667Journey Mapping Storyboarding6869## Assets7071- PDF: [Download](assets/Personas.pdf)72- Markdown Template: [template.md](template.md)7374## Metadata7576| Field | Value |77|-------|-------|78| ITK Phase | UNDERSTAND |79| Difficulty | Intermediate |80| Group Size | 6+ people |81| Time Required | 45+ minutes |82| Source | [itk.mitre.org](https://itk.mitre.org/toolkit-tools/personas/) |
Dean Peters