user persona template

This is the template. No download. No signup. Copy the markdown below, paste it into Notion, Confluence, or a plain text file, and fill in your details.

What follows the template is an explanation of every field — why it exists, what bad answers look like, and what good ones do.

The template

Copy everything between the horizontal rules below.

# Persona: [Name]

**Version:** v1.0
**Author:** [Your name]
**Last updated:** [Date]
**Product:** [Which product / feature area this persona applies to]
**Research basis:** [What you used to build this — interview count, survey size, analytics source]

---

## 1. Who they are

**Name:** [First name only. Make it real.]
**Role:** [Job title or life situation — be specific, not generic]
**Context:** [Where they work, live, what their daily situation looks like]
**Quote:** ["One sentence in their voice — what they actually say about this problem domain"]

---

## 2. Goals

**Primary goal:** [The one thing they are trying to accomplish that your product touches — 1 sentence]
**Secondary goals:** [1–2 other things that matter to them in this context]
**Definition of success for them:** [What does "this worked" look like from their perspective? Be specific.]

---

## 3. Frustrations

**Biggest pain point:** [The friction they feel most acutely today — the thing they complain about]
**Workarounds they use now:** [How are they solving this today without your product?]
**What they distrust:** [What has burned them before? What makes them hesitate?]

---

## 4. Behavior

**How they discover solutions:** [Search, WhatsApp group, peer recommendation, vendor demo?]
**Decision process:** [Do they decide alone? Who do they consult? What is their veto criteria?]
**Usage pattern:** [Daily active? Weekly? Seasonal? When in their workflow does this product fit?]
**Device and connectivity context:** [Mobile-first? Desktop? Low-data constraints? App or web?]

---

## 5. What your product must do for this persona

**The job it must do:** [One sentence. Complete this: "When [situation], they want to [motivation] so they can [outcome]."]
**The experience standard:** [What does "fast enough," "simple enough," "trustworthy enough" mean for them specifically?]
**The deal-breaker:** [What one thing, if present, will make them stop using the product?]

---

## 6. What this persona is not

[Explicitly state the adjacent user type you are NOT optimizing for here. Forces a decision.]

---

## 7. Research sources

| Source | Sample size / detail | Date |
|--------|----------------------|------|
| [User interviews] | [N=12, 45 min each] | [Month Year] |
| [Survey] | [N=340, existing users] | [Month Year] |
| [Analytics segment] | [7-day active cohort, 45K users] | [Month Year] |
| [Support ticket analysis] | [500 tickets, tagged by theme] | [Month Year] |

How to fill each field

Field 1: Who they are

The name is not decoration. Your brain processes information about people differently than information about categories. “Priya” triggers narrative thinking. “Urban aspiring millennial” triggers category thinking. Category thinking produces generic solutions. Narrative thinking produces specific ones.

The quote is the hardest field to fill well. The temptation is to write what you think they would say. Do not. Go back to your interview transcripts. Find an actual sentence an actual user said. The specificity of a real quote does more work than ten paragraphs of synthesis.

Bad: “I just want something that works without a lot of hassle.” Good: “I have WhatsApp on one phone and my work apps on another. I don’t want to switch phones every time a customer calls.”

The second quote tells you something actionable. The first tells you nothing your competitor doesn’t already know.

Field 2: Goals

State one primary goal. Not three. Not five. One.

If you write three primary goals, you have not yet understood which one matters most. That ambiguity will surface later — in a prioritization meeting where two features are competing and your team has no tiebreaker. The persona’s single primary goal is that tiebreaker.

Bad: “Wants to manage her business efficiently and save time and grow her customer base.” Good: “Knows which customers to follow up with today, without having to remember or maintain a list manually.”

The first is aspirations. The second is a job. Products solve jobs.

Field 3: Frustrations

The workarounds section is where the real insight lives. What people do today — before your product exists — tells you more about their actual needs than what they say they want.

A small kirana owner in Lucknow who is tracking credit sales in a physical khata is not asking for accounting software. She is asking for something that does what the khata does, but without the risk of someone tearing a page or the khata getting wet in the monsoon. The product that understands this builds a digital khata. The product that doesn’t builds QuickBooks Lite and wonders why adoption is low.

Ask “what do you do today when this problem comes up?” in every user interview. The answer is your competition — not just other software, but paper, phone calls, WhatsApp groups, and memory.

Field 4: Behavior

The device and connectivity context is routinely skipped by teams in Delhi and Bangalore building for users in Tier 2 and Tier 3 cities. Do not skip it.

A 2G-constrained user in Jodhpur who opens your app on an entry-level Android phone experiences your product as a fundamentally different object than the person who demoed it on a MacBook in your office. If your persona does not capture this, your design decisions will optimize for the demo environment, not the real one.

Also: decision process in Indian B2B is almost never one person. Document who else is involved and what their veto criteria are. A mid-market CRM sale in Mumbai typically runs through a champion (middle manager), a decision-maker (founder or COO), and sometimes an IT gatekeeper. If your persona is the champion but you have not documented what the decision-maker cares about, your champion will love the product and the deal will still die.

Field 5: What your product must do

The Job to Be Done format (“When X, they want to Y so they can Z”) sounds formulaic. It is. That is the point. It forces you to connect the trigger (situation), the motivation (want), and the outcome (result) explicitly.

Bad JTBD: “When they need to manage inventory, they want an easy-to-use system.” Good JTBD: “When a customer calls asking whether a specific item is in stock, they want to answer accurately in under 30 seconds without putting the customer on hold.”

The bad version gives you a product category. The good version gives you a performance standard, a use case, and a success metric.

The deal-breaker field is where teams consistently underinvest. Knowing what will make a user stop using the product is more valuable than knowing what will make them like it. Users do not leave products because they found something marginally better. They leave because something crossed a line — a trust violation, a workflow regression, a performance threshold. Document that line explicitly.

Field 6: What this persona is not

This is the field that makes a persona a decision rather than a description.

If your primary persona is a small business owner, write explicitly: “This persona is not the freelancer who invoices three clients a year.” If your primary persona is the IT admin at a 500-person company, write explicitly: “This persona is not the IT admin at a 10,000-person enterprise with a dedicated procurement team and 18-month vendor evaluation cycles.”

The act of naming who you are not optimizing for forces a conversation. If your team cannot agree on what to put in this field, you do not have alignment on your persona — you have polite ambiguity. Surface that disagreement now, not in a sprint planning meeting six months later.

Filled examples

Example 1: B2C — fintech app, urban aspiring segment

# Persona: Kavya

**Version:** v1.0
**Author:** Meera Krishnan
**Last updated:** March 2026
**Product:** UPI-based savings feature
**Research basis:** N=18 user interviews, N=2,200 survey respondents (existing active users),
                    90-day cohort analysis (260K users)

---

## 1. Who they are

**Name:** Kavya
**Role:** Junior HR executive, 2 years into her first corporate job
**Context:** Lives in a PG in Koramangala, Bengaluru. Monthly salary INR 28,000 credited
            on the 1st. Sends INR 8,000 home to Mysuru each month. Remaining INR 20,000
            is gone by the 22nd, and she does not know where it went.
**Quote:** "I know I should save but every time I try I end up spending it before the
           month ends. The money is just there and I use it."

---

## 2. Goals

**Primary goal:** Have at least INR 5,000 left at the end of every month without having
                  to think about it.
**Secondary goals:** Build an emergency fund over 6 months; avoid borrowing from her
                     roommate when rent is due.
**Definition of success for them:** "I didn't have to ask my roommate for money this month."

---

## 3. Frustrations

**Biggest pain point:** Money disappears between salary day and mid-month. She cannot tell
                        you where it went — UPI payments are instant and invisible.
**Workarounds she uses now:** Sets a daily spending reminder on her phone (ignores it after
                              day 3). Keeps INR 2,000 cash in an envelope for emergencies.
**What she distrusts:** Any app that requires her to "invest." Her mother lost money in a
                        chit fund in 2019. She will not touch anything she does not understand.

---

## 4. Behavior

**How she discovers solutions:** WhatsApp groups with her PG roommates. Instagram ads.
                                 Her older sister's recommendation.
**Decision process:** Decides alone. Consults her sister for anything involving money she
                      cannot withdraw easily.
**Usage pattern:** Opens finance apps once a week, on Sunday evenings when she is anxious
                   about the upcoming week. Not a daily active user by habit.
**Device and connectivity context:** Poco X3 Android. Reliable 4G. Uses 5–7 UPI apps
                                     interchangeably depending on cashback offers.

---

## 5. What the product must do for Kavya

**The job:** When salary is credited, she wants to automatically move money she will not
             miss into a separate bucket so it is still accessible but not in her daily
             flow — without having to make a decision at the time.
**Experience standard:** Setup under 3 minutes. No lock-in. She can take it back in one
                         tap if she needs it. Any complexity and she drops off.
**Deal-breaker:** If she cannot withdraw her saved money immediately when she needs it,
                  she will uninstall the app within a week.

---

## 6. What this persona is not

Kavya is not the financially literate young professional who is already investing in mutual
funds and wants a portfolio tracker. She is not the Tier-1-city, IIT/IIM graduate who
reads MoneyControl. Features optimized for those users — fund comparison, XIRR calculations,
tax-loss harvesting — add noise for Kavya. Build those for a different persona.

---

## 7. Research sources

| Source | Sample size / detail | Date |
|--------|----------------------|------|
| User interviews | N=18, 40–60 min, recruited via PG WhatsApp groups in Bengaluru, Pune, Hyderabad | Jan 2026 |
| In-app survey | N=2,200, active users who had at least 3 UPI transactions in last 30 days | Feb 2026 |
| Cohort analysis | 90-day behavior, users who opened savings tab at least once (260K users) | Feb 2026 |
| Support tickets | N=180 tagged "savings," last 6 months | Dec 2025 |

Example 2: B2B — SaaS, mid-market champion

# Persona: Vikram

**Version:** v1.0
**Author:** Sanjay Mehta
**Last updated:** March 2026
**Product:** Field sales CRM
**Research basis:** N=14 user interviews (sales managers, not executives),
                    N=6 sales calls observed, N=90 in-app behavior sessions

---

## 1. Who they are

**Name:** Vikram
**Role:** Regional Sales Manager, FMCG distributor, Pune. Team of 12 field reps.
**Context:** Manages INR 4–6 Cr monthly sales volume. Spends 40% of his time in meetings
            with retailers and distributors; 30% in his car between locations. Reports
            daily to the VP Sales in Mumbai. His team uses a mix of WhatsApp, Excel,
            and one legacy CRM his company bought 3 years ago and nobody likes.
**Quote:** "My boss asks me for numbers at 9 AM and my reps don't update the system until
           Friday. So I'm always guessing on Monday morning."

---

## 2. Goals

**Primary goal:** Know by 9 AM which deals in his pipeline will close this week and which
                  ones need his intervention today — without calling each rep.
**Secondary goals:** Reduce time spent building Monday morning reports; reduce instances
                     where a deal slips because he found out too late.
**Definition of success for him:** "I walked into my Monday call with accurate numbers and
                                   I knew which three deals I needed to make calls about."

---

## 3. Frustrations

**Biggest pain point:** Reps do not update CRM in real time. They batch-update on Friday
                        or when Vikram chases them. By then, the pipeline view is stale.
**Workarounds he uses now:** WhatsApp group for daily check-ins. Manual Excel tracker
                             he maintains himself each Monday. Calls his top 3 reps
                             personally if something big is at risk.
**What he distrusts:** Any tool that requires his reps to do more data entry. "They
                       won't do it. I've seen it fail twice already."

---

## 4. Behavior

**How he discovers solutions:** Peer recommendation from other sales managers in his
                                 industry WhatsApp groups. Vendor demos arranged by
                                 his company's IT department.
**Decision process:** Vikram is the champion, not the buyer. He can run a pilot and
                      advocate internally. Final sign-off is with the VP Sales or COO.
                      IT department has a veto on integration feasibility.
**Usage pattern:** Accesses on mobile, primarily between 7–9 AM and during commute.
                   Desktop for report review on Monday morning. Not logging in during
                   field visits.
**Device context:** Samsung Galaxy, reliable 4G. Uses mobile-first. Desktop only for
                    formal reviews.

---

## 5. What the product must do for Vikram

**The job:** When a rep completes a customer visit, Vikram wants the pipeline to update
             automatically — without the rep having to open a laptop — so his Monday
             morning view reflects what actually happened last week.
**Experience standard:** Rep-side data entry must be under 60 seconds on mobile.
                         If it takes longer, reps skip it. No exceptions.
**Deal-breaker:** If his VP asks a question that the product cannot answer from real data —
                  and Vikram has to say "I'll check and get back to you" — he stops
                  trusting the tool and reverts to his Excel tracker.

---

## 6. What this persona is not

Vikram is not the VP Sales in Mumbai who needs a strategic pipeline overview and
revenue forecasting. He is not the IT head evaluating integration architecture. Build
for Vikram's daily operational need first — the downstream dashboards for VP Sales
are a separate persona with different requirements. A product that tries to serve both
in one view will serve neither well.

---

## 7. Research sources

| Source | Sample size / detail | Date |
|--------|----------------------|------|
| User interviews | N=14, field sales managers, 45–60 min, Pune + Mumbai | Nov 2025 |
| Sales call observation | N=6, shadowed reps during customer visits in Pune district | Dec 2025 |
| In-app session recordings | N=90 sessions, mobile, existing users on trial | Jan 2026 |
| NPS verbatim | N=120 detractor responses, filtered "CRM" tag | Oct 2025 |

One persona or many?

The answer is: as few as you can get away with, and no fewer.

The pressure on every product team is to add personas — to make everyone feel represented, to avoid the politics of saying “we are not building for you right now.” Resist this. A product that has six personas of equal weight has made no decisions. It has documented its indecision in six character profiles.

One to two personas is the right number for most early-stage products. One primary persona — the person you are optimizing every hard decision for — and at most one secondary persona whose needs you accommodate when they do not conflict with the primary.

Three is sometimes warranted in marketplace or platform products where you have distinct supply-side and demand-side users with genuinely different needs and different product surfaces. A field sales CRM has Vikram (the manager) and a rep-side persona. A fintech app might have Kavya (the saver) and a family account holder. But these are still two personas each — not six.

More than three personas is a sign you have not done enough segmentation work. You have collected observations about five different user types and called them all personas because you cannot decide who matters most. That is a strategy problem, not a research problem. Go back to first principles: which segment drives the most value for your business if they succeed? Start there.

When you have multiple personas, be explicit about hierarchy. Your PRD should reference which persona a given feature serves. If a feature serves Persona B but degrades the experience for Persona A, that is a product decision that needs to be surfaced — not resolved by pretending both personas are equally important.

Building from research, not imagination

The most common failure mode in persona work is building personas from internal assumptions rather than external research. The team sits in a room, discusses “who our users are,” and produces a document that reflects their own mental model rather than actual user behavior.

You can tell an assumption-based persona from a research-based one by asking: “What would you have to find in your research to change this?”

If you cannot answer that question for any field in your persona, that field is an assumption. Go validate it.

Minimum research required to write a persona you can trust:

• Seven to ten interviews with people who actually experience the problem you are solving. Not your team. Not your investors. Not friends who use similar products. The actual person the persona represents.
• One behavioral anchor — something you observed or measured, not just something people told you. Users tell you what they want. Behavior tells you what they actually do. When these diverge, trust the behavior.
• One explicit outlier interview — deliberately talk to someone who does not fit the pattern you are building toward. Outliers reveal the edges of your persona’s validity. If your outlier behaves like your primary persona on every dimension, your persona is too broad. If they are completely different, you have found either an edge case to exclude or a second persona worth documenting.

Test yourself

Related pages

• Building User Personas — the theory behind personas: what makes them useful, the India-specific segments most PM resources ignore, and how to prevent persona drift
• User Research Methods — how to run the interviews that feed this template
• Jobs to Be Done — the framework behind Field 5’s JTBD format
• PRD Template — how to reference personas inside a PRD without rewriting them from scratch
• Problem Definition — what to do when your personas surface multiple problems and you need to pick one