How to build user personas a product team will trust

A product team opens the persona deck in a roadmap meeting, and the argument carries on anyway, because nobody can check where the personas came from. User personas earn trust when every line traces to what customers said or did, and each persona shows how many customers it stands for. Build them from interviews, then size them with a survey.

User personas are profiles of customer groups, built from research. Each one centers on a shared goal and a shared way of working. In a large company, several product teams, regions and sales can each hold a different picture of the customer. A persona nobody can check lets every team keep its own.

The checks and steps below tell you which persona lines to keep, which to cut, and when a persona is ready for a team to build for.

A persona earns trust when each line has a source and a size

A product team will use a persona when it can answer two questions about it. Where did each line come from? How many customers does it stand for? Interviews answer the first question. A survey or product analytics answers the second. A persona that fails either test stays on the slide.

Each kind of line has a best source. Interviews carry goals, motives, pains and workarounds. Those need the customer to explain them. Counts and shares need a survey or analytics.

Line in the persona	Best source	What to avoid
Goal	Interviews	A goal written as a product feature
Decision criteria	Interviews	Criteria no participant named
Workarounds	Interviews, then analytics for how common	A workaround one person mentioned once
Pains	Interviews	Ranking pains by how loudly they were said
Context (devices, team, timing)	Interviews and analytics	Guessing context from a job title
Demographics	Survey or CRM data	An age or bio no study measured
Share of customers	Survey or analytics	A share guessed in a workshop

The gap runs both ways. Nielsen Norman Group advises against creating personas from analytics data alone, because personas aim to capture attitudes, goals and pain points, and analytics alone cannot supply those. The advice comes from a November 2023 video presented by Page Laubheimer. A persona built only from interviews has the reverse gap. It carries reasons and no size, so a team cannot weigh it against another persona.

Leave out demographics that no study measured. An invented age and hobby invite stereotypes and give a team nothing to act on. If the business already segments by market or plan, keep that field and take it from the CRM.

How to build user personas from interviews, step by step

Build user personas in six steps: recruit across the segments you suspect, ask about recent behavior, code the transcripts, keep a ledger of evidence, size each candidate with a survey, and give each persona an owner. Each step leaves a record, so any team can check the persona later.

1. Recruit across the segments you already use

Invite people from each segment the business already reports on, such as market, plan and how long they have been a customer. The interviews can then confirm those segments or break them. Recruiting across them also gives every stakeholder a reason to accept the result. Plan a set of interviews per segment, and keep going in any segment where new interviews still add patterns. No fixed count is enough in every case. The post on how many interviews you need works through what moves the number.

2. Ask about the last time they did the task

Ask each participant to walk through the last time they did the task: what started it, what they compared, where they gave up and what they used instead. A recent episode gives you behavior to code. Questions about the product's features give you feature feedback, which belongs to another study. The guide to conducting user interviews covers the session itself.

3. Code the transcripts and group people by behavior

Coding means tagging each passage of a transcript with a short label, such as "needs sign-off" or "works around upload". Use qualitative coding for goals, behaviors, pains and decision criteria. Then group participants by the behavior they share, for example how often they do the task and whether someone else must approve it. Groups that form on behavior can cut across job titles and markets. When they do, the persona tells the team something the CRM could not.

4. Keep a ledger as you go

A ledger is a list of every persona line with the participants and quotes behind it. Write it while you code. A line backed by one participant is a lead. It stays out of the persona until another study confirms it. Have a second person group a sample of transcripts without the segment labels, and compare the two groupings. That shows whether the groups came from the data or from the segments the team already knew. The post on bias in user research covers this check.

5. Size each persona with a survey

Turn each persona's defining behaviors into two to four survey questions: how often the task happens, which workaround the respondent uses, who signs off. Send the survey to a sample drawn from the same segments, and use the sample size calculator to set how many responses you need. Respondents who match a persona count toward its share. Respondents who match none show what the personas leave out.

6. Give each persona an owner and a review trigger

Give every persona one owner, usually in research or insights, plus a version date and a list of the studies behind it. A new study that contradicts a line reopens the persona. Retire personas nobody cites in decisions, and merge two that teams keep confusing. Store the ledger in a shared research repository, so a product manager in another unit can open the quotes behind any line.

How an insurer's claims team would decide which persona to build for

For illustration, a large insurer's digital team is redesigning its motor claims journey in two markets. Each market's product lead wants the redesign built around a different customer. The team has to decide which persona the first release serves, and the decision has to hold up in front of both leads.

The business question has two parts. Which group of claimants loses the most time in the journey, and how big is that group? The team has three sources it can draw on: interviews with recent claimants, a sizing survey, and app analytics on where claims stall.

Source	What it can establish	What it cannot establish
Interviews with recent claimants	Goals, the steps people struggle with, and their workarounds	How many claimants share each pattern
Sizing survey	The share of claimants in each market who match each persona	Why they behave the way they do
App analytics	Where claims stall, and how often	What the claimant was trying to do at that point

The team weighs the three together. Interviews suggest the candidate personas, and the ledger shows which lines have several participants behind them. Analytics checks whether the workaround people describe, such as emailing photos when an upload fails, shows up in the data. The survey then gives each persona its share in each market.

The evidence sets the next decision. If one persona is the largest group in both markets, the first release serves it, and both leads can see why. If each market's largest group is a different persona, the team builds the shared steps first and plans a market-specific release for each. Either way, some lines stay out of the persona that goes to the steering group. A line with one participant behind it is cut, and so is an age band no source measured.

Generated personas can draft questions, and interviews decide what goes in

A persona written by a large language model (LLM) without customer data has no participants behind its lines, so nothing in it can be traced or sized. Use it as a list of guesses to test in your interview guide. Interviews with real customers then decide which lines stay.

Early research points the same way. A 2025 arXiv preprint by Prama, Danforth and Dodds compared human answers with answers from eight LLM-generated social personas. It used 100 culturally specific questions in Bangladesh. Human responses scored higher than every model on all persona perception measures, with the largest gaps in empathy and credibility.

The same study found the generated persona text more positive in tone than human answers, a bias the authors link to the Pollyanna Principle. In a product persona, that tilt would show up as softer pains and fewer workarounds, which are the lines a product team most needs.

Checking generated personas is still part of the work. Amin and colleagues reviewed 81 articles on how generative-AI personas are created and evaluated, in a scoping review published at CHI 2026. It also covers ethical questions such as bias detection.

Where Pulse fits in building personas

The slow part of an evidence-based persona is the fieldwork: interviewing enough customers in each segment, then reading every transcript to fill the ledger. Pulse runs that part. It runs AI-moderated voice interviews with one guide across every segment, and asks a follow-up question when an answer is thin.

It groups the answers into themes and ties each theme back to the quotes and interviews behind it, which is the ledger's raw material. Pulse also runs surveys alongside the interviews, so a persona's reasons and its size can come from one study. The researcher still decides which behaviors define a persona and which lines are strong enough to keep.

Use one rule before any persona goes to a product team. If a line has no participant behind it, cut it. If the persona has no share, size it before anyone builds for it. To see how a persona study would run for your teams, book a demo.

Questions readers ask

1. What are the different types of personas?

Three common types are goal-directed, role-based and engaging. Goal-directed personas center on what the user is trying to get done and what stands in the way. Role-based personas add job duties and decision authority, which suits B2B products. Engaging personas add a story to build empathy, and each detail in that story still needs evidence.

2. What should B2B user personas include?

B2B user personas need the role, the decision the person owns or influences, who else signs off, the criteria they apply, the workarounds they use today, and the persona's share of accounts or users. In B2B the buyer and the daily user are often different people, so a team may need a separate persona for each.

3. How many user personas should a product team have?

No count is right for every team. Build as many personas as the evidence shows distinct behavior patterns, and no more than teams will use in decisions. If two personas lead to the same product choices, merge them. If a persona never comes up in a roadmap discussion, retire it.

4. How do you get product teams to use personas once they exist?

Put the persona name and its share into the documents where teams decide, such as roadmap proposals and feature briefs, and link the ledger from each one. A team that has to say which persona a feature serves, and how many customers that is, will check the evidence before the meeting.