itk-personas

name	itk-personas
description	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.
intent	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.
type	component
phase	understand
outcome	understand
difficulty	intermediate
group_size	6+ people
time_required	45+ minutes
best_for	["Early discovery when you need to align engineering, design, and sales on who the actual target user is","Translating raw user research from interviews and surveys into shareable archetypes the whole team references","Prioritizing a backlog when competing feature requests serve different user segments with conflicting needs","Onboarding new team members or stakeholders who lack context on who the product actually serves","Pressure-testing a roadmap assumption that 'users want X' before committing engineering capacity"]
sources	["MITRE Innovation Toolkit (ITK)","https://itk.mitre.org/toolkit-tools/personas/"]

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

1. Assemble existing research into current or potential users.
2. 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.
3. 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.
4. 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