What Is a Persona? A Product Manager's Practical Guide

A persona is a fictional but realistic profile of a typical user, built from real research so a team can design for one specific person instead of "everyone." In product work it usually gets a name, a goal, a handful of frustrations, and the context in which the person uses your product. The word itself is older than software: in Latin it meant a theatrical mask, and Carl Jung borrowed it for the face we show the world.

Designer Alan Cooper is often credited with bringing personas into software in the 1990s, and teams have been misusing them ever since. You have probably seen the result: a laminated card reading "Marketing Mary, 34, loves yoga," pinned to a wall and never mentioned in a meeting again. That is decoration, not a tool.

A user persona earns its place when it settles arguments. Should the onboarding checklist be skippable? Does this report need an export button? If the persona can answer, it works. If nobody quotes it, it is wallpaper.

User Personas Examples: What Good Ones Contain

Most user personas examples online look identical: a stock photo, an age, a job title, a favorite brand of coffee. Almost none of that changes a product decision. The details that do are the goal the person is trying to reach, the situation they are in when they open your product, and what usually goes wrong.

Here is a compact B2B example. "Dana" is an operations lead at a 40-person logistics company. She opens your reporting tool on Monday morning with 20 minutes before a leadership meeting. She needs one number she can defend, she distrusts dashboards she did not build, and last quarter an export silently dropped rows, so she now re-checks everything in a spreadsheet. Notice what is missing: her age, her hobbies, her favorite coffee. Notice what is there: a deadline, a trust problem, and a behavior you can design against.

Nielsen Norman Group describes a persona as a fictional yet realistic description of a typical or target user, and its 2025 article on why personas make users memorable makes a point worth keeping on a sticky note: every detail should serve a purpose, and irrelevant ones should go. Teams that build personas together also trust and use them more, which matters because a persona nobody believes gets ignored in the first heated prioritization debate.

A few rules of thumb for what to include:

• A goal stated in the person's words, not your feature names
• The moment of use: where they are, how much time they have, what else is open
• One or two frustrations taken from real sessions or tickets
• A quote you actually heard, if you have one
• A short list of what this person does not care about, which is surprisingly useful for saying no

If you want the longer version with templates, our guide on user personas, their meaning, and UX best practices goes deeper on format.

How to Create a User Persona Without Inventing Users

The honest answer to how to create a user persona is: talk to people first, write second. A persona drafted in a conference room from the team's assumptions is called a proto persona. It is fast, it aligns the room, and it is also the most likely to be wrong, because it records what the team already believes. Nielsen Norman Group lays out three approaches in its piece on lightweight, qualitative, and statistical personas, and the middle option is the practical choice for most teams.

Qualitative personas rest on a modest number of interviews, roughly 5 to 30 according to that article, grouped by shared goals, attitudes, and pain points. Statistical personas need a survey of at least 100 respondents plus clustering methods, which sounds rigorous until you realize most teams lack the analyst time to do it well. Unless you have a data scientist on hand, start qualitative.

A workable sequence looks like this:

1. Pull what you already have: support tickets, sales call notes, onboarding survey answers. Look for repeated phrases, not averages.
2. Interview a mixed set of current users, churned users, and people who evaluated you and left. Our post on conducting user interviews that drive decisions covers how to run them.
3. Cluster what you heard by goal and situation, not by demographics. Two people with different job titles who want the same outcome are one persona.
4. Write each persona on one page, then cut everything a designer or engineer could not act on.
5. Test it by asking the team to settle a real roadmap question with it. If they cannot, revise.

Two to four personas is plenty for most products. Past that, nobody remembers them, and "everyone" quietly creeps back in. Treat them as living documents: when a new interview contradicts the persona, change the persona, not the interview notes.

User Persona AI: Useful Draft, Poor Evidence

Tools that generate a user persona with AI are tempting, especially when a deadline is close and recruiting interviews takes three weeks. They are good at one thing: producing a plausible first draft to react to. They are poor at the thing a persona exists for, which is representing real users you have not met yet.

The reason is bias in the generation itself. A 2025 preprint, LLM Generated Persona is a Promise with a Catch, reports that persona generation methods built on informal rules of thumb produced systematic biases, and in experiments such as election forecasts and surveys of U.S. opinion those biases opened substantial gaps between the simulated personas and real-world outcomes. For a product team, the translation is simple. If you ask a model for "a typical logistics operations lead" and then design around the answer, you are designing around the model's average of the internet, not around your customers.

That does not make AI useless here. Reasonable uses include:

• Drafting interview questions for each hypothesis you want to test
• Summarizing transcripts you collected yourself, with a human checking quotes
• Turning a finished persona into variants for edge cases, clearly labeled as hypotheses
• Stress-testing a roadmap argument by asking what a skeptical user would object to

The line to hold is evidence. A persona built from interviews can be defended in a meeting. A persona built from a prompt cannot, and the first time an engineer asks "where did this come from?" you will want a better answer than "the chatbot said so." Label anything AI-generated as an assumption until real users confirm it.

FAQ

A persona is only as good as the research under it and the decisions it changes. Keep the details that guide design, cut the ones that do not, and let real interviews overrule any draft, human or machine.

Pick one open roadmap question this week and try to settle it with your current persona. If the team cannot, that is your signal to schedule five interviews and rebuild it.