Why Personas Matter
A persona is not a creative writing exercise. It is a decision-making tool. Alan Cooper introduced goal-directed personas in About Face, arguing that personas should be defined by what users are trying to accomplish, not by demographics alone. When your team debates whether to build Feature A or Feature B, a well-researched persona gives you a concrete user to point at and ask: "Which of these actually solves her problem?" Without that anchor, product decisions drift toward whoever argues loudest in the room.
This template gives you a repeatable structure for building personas grounded in real research, not assumptions. Each section maps to a specific type of product decision. If you are early in discovery and still identifying who your users are, start with the Product Discovery Handbook for a structured approach to customer research.
How to Use This Template
- Start with research, not imagination. Interview 5-8 users in your target segment before filling in any field. Pull behavioral data from analytics. Review support tickets. The Nielsen Norman Group's persona guide emphasizes that personas built from desk research alone are fiction.
- One persona per segment. Do not merge two distinct user types into one. If your startup founder and enterprise PM have different goals, create separate personas.
- Fill in what you know, flag what you don't. Mark uncertain fields with "[Assumption]" so your team knows what still needs validation.
- Keep it to one page. A persona that nobody reads is useless. Cut anything that does not directly inform a product decision.
- Update quarterly. Users evolve. Revisit personas after major research rounds or significant product changes.
User Persona Template
Identity
| Field | Details |
|---|---|
| Name | [Give them a realistic name] |
| Photo | [Stock photo or illustration placeholder] |
| Role / Job Title | [Current title] |
| Company Size | [Startup / SMB / Mid-Market / Enterprise] |
| Industry | [Primary industry] |
| Location | [City, region, or "Remote"] |
| Age Range | [e.g. 28-35] |
| Experience Level | [Years in current role or field] |
Goals
What does this person need to accomplish? Focus on outcomes, not features.
- [Primary goal: the thing they are measured on or care most about]
- [Secondary goal: what they want in service of the primary goal]
- [Tertiary goal: a nice-to-have that influences their choices]
Frustrations and Pain Points
What slows them down, annoys them, or prevents them from reaching their goals?
- [Pain point 1: specific, observable behavior or complaint]
- [Pain point 2]
- [Pain point 3]
Current Tools and Workflow
How do they solve this problem today? What is their existing stack?
- Primary tools: [List 2-3 tools they use daily]
- Workarounds: [Manual processes, spreadsheets, or hacks they rely on]
- Gaps: [What their current tools cannot do]
Quote
"[A real quote from a user interview that captures this persona's mindset. If you don't have one yet, leave this blank and fill it after your next round of interviews.]"
Behavioral Patterns
- How they discover new tools: [Word of mouth, Product Hunt, peer recommendations, vendor outreach]
- Decision-making style: [Data-driven, consensus-seeking, fast/intuitive, methodical]
- Buying authority: [Decision maker, influencer, end user, champion]
- Content consumption: [Blogs, podcasts, Slack communities, conferences]
Key Jobs-to-be-Done
Use the Jobs-to-be-Done framework to capture what this persona is trying to accomplish in context. Structure each job as: "When [situation], I want to [motivation], so I can [expected outcome]."
- When [situation], I want to [motivation], so I can [expected outcome].
- When [situation], I want to [motivation], so I can [expected outcome].
- When [situation], I want to [motivation], so I can [expected outcome].
You can use the JTBD Builder tool to generate structured job statements from your research notes.
Example 1: Startup Founder Persona
Identity
| Field | Details |
|---|---|
| Name | Maya Chen |
| Role / Job Title | Co-founder and CEO |
| Company Size | Startup (12 employees) |
| Industry | B2B SaaS (developer tools) |
| Location | Austin, TX |
| Age Range | 31-36 |
| Experience Level | 4 years as founder, 6 years prior as engineer |
Goals
- Reach $1M ARR within 18 months of launch
- Find and validate a repeatable acquisition channel before Series A
- Ship fast enough to stay ahead of two funded competitors
Frustrations and Pain Points
- Spends 3+ hours per week on roadmap alignment calls because the team has no shared view of priorities
- Customer feedback is scattered across Slack, email, and Notion with no way to see patterns
- Investors keep asking for a "product strategy doc" but she has never written one before
Current Tools and Workflow
- Primary tools: Linear for engineering tasks, Notion for docs, Google Sheets for everything else
- Workarounds: A manually updated spreadsheet that tracks customer requests by revenue impact
- Gaps: No way to connect customer feedback to roadmap items or measure feature impact
Quote
"I know what to build next, but I can't explain why in a way that satisfies my board or my team. It's all in my head."
Behavioral Patterns
- How they discover new tools: Twitter/X, Hacker News, founder Slack communities
- Decision-making style: Fast and intuitive, but increasingly pressured to show data
- Buying authority: Final decision maker for tools under $500/mo
- Content consumption: Podcasts (Lenny's, First Round Review), occasional blog posts
Key Jobs-to-be-Done
- When I am preparing for a board meeting, I want to show which features drove retention, so I can justify our roadmap direction.
- When a large prospect requests a feature, I want to quickly assess its priority against everything else, so I can give them an honest timeline without derailing the team.
- When onboarding a new engineer, I want to share a clear picture of what we are building and why, so they can make autonomous decisions from day one.
Example 2: Enterprise Product Manager Persona
Identity
| Field | Details |
|---|---|
| Name | David Park |
| Role / Job Title | Senior Product Manager |
| Company Size | Enterprise (2,500 employees) |
| Industry | Financial Services SaaS |
| Location | New York, NY |
| Age Range | 33-38 |
| Experience Level | 7 years in product management |
Goals
- Increase platform adoption from 40% to 65% across existing enterprise accounts
- Reduce time-to-value for new account onboarding from 90 days to 45 days
- Build a self-serve analytics layer so customers stop filing "data export" support tickets
Frustrations and Pain Points
- Three layers of stakeholder approval before any feature reaches development. Average cycle time from idea to shipped: 14 weeks.
- Customer success team surfaces feature requests through a spreadsheet that is always out of date
- Engineering estimates vary wildly because specs are inconsistent. The same feature gets scoped at 2 weeks or 6 weeks depending on the engineer.
Current Tools and Workflow
- Primary tools: Jira, Confluence, Amplitude, Figma
- Workarounds: A personal Notion database where he tracks stakeholder commitments and their status
- Gaps: No structured way to tie customer health scores to feature adoption data
Quote
"I spend more time getting alignment than building product. By the time everyone agrees, the market has moved."
Behavioral Patterns
- How they discover new tools: Peer recommendations at PM meetups, internal tool evaluations, vendor demos
- Decision-making style: Data-driven and methodical. Builds business cases before proposing anything.
- Buying authority: Influencer and evaluator. VP of Product has final sign-off.
- Content consumption: Reforge, Stratechery, industry reports, LinkedIn thought leaders
Key Jobs-to-be-Done
- When quarterly planning starts, I want to present a prioritized list of features with clear impact estimates, so I can get stakeholder alignment in one meeting instead of five.
- When a customer escalation comes in, I want to see that customer's usage data alongside the feature request, so I can assess whether this is a real gap or a training issue.
- When writing a spec, I want a consistent structure that engineering trusts, so estimates are accurate and scope creep is minimized.
Superhuman famously used a persona-driven approach to find product-market fit, measuring how disappointed users would be if the product disappeared. Read the full breakdown in the Superhuman PMF case study.
Common Mistakes
Persona as marketing fiction. If your persona reads like a creative brief ("Meet Sarah, she loves yoga and artisanal coffee"), it will not help you make product decisions. Every field should connect to a behavior that affects how they use your product.
Too many personas. Three to five personas cover most products. If you have ten, you have not segmented clearly enough. Merge similar users and split only when their goals genuinely diverge.
Building personas after deciding what to build. Personas created to justify a feature you already want to ship are confirmation bias with a template. Do the research first.
Never updating. A persona from 18 months ago may describe a user who no longer exists. Especially in fast-moving markets, revisit personas when you notice support tickets or interview data contradicting your assumptions.