About six years ago I was doing some work with a credit union, interviewing branch personnel. One of the managers told me something I have never forgotten: marketing shares these personas with us, but they don’t look anything like the customers who actually come into the bank.
That gap is the problem. It was the problem before AI, and AI has made it faster to create.
I can now generate a complete persona in about 90 seconds. Name, photo, backstory, a tidy list of pains, a confident statement about who signs the contract. It looks exactly like a persona built from 30 customer interviews. Until someone validates it against real customer evidence, it is a hypothesis with a headshot.
In our Proto to Proven working session we took an AI-generated persona named Rachel and tested her against CRM records, support tickets, and notes from customer-facing teams. Two of her central claims fell apart. One held.
This post walks through what persona validation actually involves, which assumptions are worth testing first, and how to run the check using data your company already has.
What Is Persona Validation?
Persona validation means testing each claim in a persona against real customer evidence, such as CRM records, support tickets, product analytics, and interviews, before your team relies on it to make decisions.
The word “each” matters. A persona is not one claim, it is a dozen. Who this person is, what they are trying to accomplish, what gets in their way, how they currently solve it, whether they can authorize a purchase, who influences them. Validation is not a yes or no verdict on the whole profile. It is a claim-by-claim check, and the answer usually comes back mixed.
In the session, Rachel’s claim that employees hated the incumbent tool held up across tickets and customer success notes. Her claim about owning the buying decision did not. Both were in the same document, formatted identically, written with the same confidence.
Proto-Persona vs. Validated Persona: What’s the Difference?
A proto-persona is a draft built from team opinions, anecdotes, or AI output. A validated persona is one whose claims have been checked against customer evidence. The format is identical. The difference sits entirely in what stands behind it.
The term comes from Jeff Gothelf’s work on Lean UX, where the proto-persona exists as a hypothesis the team agrees to test rather than a conclusion. That framing is the useful part. A proto-persona is not a lesser artifact, it is an honest one. It says out loud that the team has agreed on an assumption and has not yet checked it.
The trouble starts when nobody renames it. A proto-persona that quietly becomes “our persona” over two quarters has not gained any evidence, only familiarity.
Nielsen Norman Group draws a similar distinction across lightweight, qualitative, and statistical personas. Their research also found that roughly one in two personas in their sample were built mostly without research. So the proto stage is where most personas live, whether or not their owners would describe them that way.
Why AI-Generated Personas Look Validated (But Aren’t)
I use AI for this work and I recommend it. The output is polished, well structured, and genuinely a good starting point. What it is missing is any answer to a simple question: where did the evidence come from, and does it relate to our actual customer segment?
Two findings explain why the polish is misleading.
The first is agreeableness. Stanford research published in Science in 2026 found that AI models side with the user roughly 50% more often than a person would. Pleasing you is part of the objective. Ask it to describe your buyer and it will produce a buyer who makes sense given your prompt, which is not the same as one who exists.
The second is depth. Nielsen Norman Group compared AI-generated research participants against real customer research and judged the synthetic version too shallow. That matches my own experience running synthetic user interviews. The answers come back generic. They never reach the thing underneath what the person is saying.
Someone once pitched me a product for testing ideas against synthetic users, and closed by asking for feedback from real ones. That is the whole argument in one anecdote.
So treat an AI-generated persona as a starting point rather than as evidence. It is a reasonable hypothesis, produced quickly, and nothing more than that until you check it.
How Unvalidated Personas Skew Your Roadmap
An unvalidated persona rarely fails loudly. It sits in the background of decisions that look unrelated to personas at all.
It shows up in prioritization, because the pain you believe is primary determines which problems reach the top of the list. It shows up in outcome-based product roadmaps, because the outcome you are driving toward belongs to someone, and if that someone is wrong, the outcome is wrong too. It shows up in prioritization conversations where two teams disagree without realizing they are picturing different customers.
It also shows up in deals. If your persona says the operations manager signs the contract and in reality the CFO signs while IT security holds a veto, your messaging is aimed at a champion you have mistaken for a buyer.
The correlation data points the same way. Cintell’s 2016 research found that 70% of companies missing their revenue goals had never interviewed buyers for their personas, while 82% of those that did conduct qualitative persona research hit theirs. Correlation is not causation here, and I would not claim otherwise. But the implication is hard to ignore.
Rina made a related point during the session that has stayed with me. When she asks product leaders about a bet that did not pay off, the failed bet usually rested on an assumption that changing the product would change behavior. The behavior turned out to be driven by something outside the product entirely. Personas are where those assumptions get written down.
Which Persona Assumptions Carry the Most Risk
Not every claim deserves the same scrutiny. Rank them by what it costs you to be wrong.
Wrong age costs nothing. Wrong pain costs the roadmap. Wrong buyer costs the deal.
That is the shortest version of the rule. Three claims sit at the top of the list:
- Buying authority. Who signs, who champions, and who can say no. Get this wrong and deals stall late for reasons nobody can name.
- Primary pain. The problem this person most wants solved. Get this wrong and you are prioritizing the wrong work with perfect discipline.
- Desired outcomes. What this person is trying to achieve, and which of those outcomes they are not hitting today. This is how you locate the pain rather than guess at it. The gap between the outcome they want and the result they get is where the real problem lives, along with whatever is standing in the way.
Below those sit the job to be done and how the person currently solves the problem. These matter, and they are worth checking once the top three are settled.
Demographics sit at the bottom. Age, tenure, team size, and the photo are useful for empathy. They help your engineers picture who they are building for. They almost never change a decision.
This is the useful part for anyone working with AI: it is good at this ranking step. In the session I gave the model Rachel’s profile and asked which of her claims I should trust least and what evidence would be required to prove each one. It came back with her buying authority at the top, which is where Rina and I had both put it independently. Challenging AI output with AI is a reasonable use of the tool, because you are asking it to argue rather than to agree.
The Customer Data You Already Have to Validate a Persona
Full interviews and surveys give you the strongest evidence. They also take weeks, which is why persona work stalls. So start with what is already in your systems.
Three sources do most of the work, and each one answers a different question.
| Source | What it tests | What to look for |
| Support tickets | Primary pain | Most frequent problems, when volume spikes, who submits them, the customer’s exact words |
| CRM deal records | Buyer and pain | Champion vs. signer, pain in the deal notes, where deals stall, why deals are lost, patterns by company size |
| Sales and CS teams | The why behind both | Context and causes the records don’t explain |
If you run a marketing automation platform with CRM data in it, that counts too. The point is not the brand of system, it is whether the data reflects real customer behavior.
For the conversations with your customer-facing teams, six questions cover most of the ground:
- Who signs, and who can say no?
- Why are customers looking for a solution?
- Why do deals stall or die?
- What do customers complain about most?
- What do customers like most about our solution?
- Who doesn’t fit our persona?
That last one is underrated. Knowing who your persona excludes sharpens it as much as knowing who it includes.
One caveat: Internal data is good evidence and it is not the best evidence. Talking to customers is still better. Internal data is how you get moving this week instead of next quarter, and it pairs well with broader market research and competitive analysis when you are sizing a segment.
A Repeatable Persona Validation Workflow
How to validate a persona with AI and the data you already have:
- Pull CRM deal data, support tickets, and notes from sales and CS teams.
- Prompt AI to build the persona from that data and cite evidence for every claim.
- Ask AI to rate those evidence-based claims and flag which ones still need stronger proof.
- Review the result with customer-facing teams before you share it.
This takes less time than most teams expect. The slow part is getting the data, because pulling a CRM export or a ticket download often means jumping through a few hoops internally. Once you have the files, the build itself runs in minutes. In the session I loaded the CRM and ticket data with a prompt and the model came back with the persona and the evidence behind each claim, including the deal records that told us the finance operations manager was usually the champion rather than the buyer.
Step three is where AI earns its place. Asking the model to rate its own evidence-based output tells you which claims are resting on three data points and which are resting on thirty. That is the list you take into customer interviews.
A few notes from running this in practice. Ask for evidence explicitly in the prompt or you will get assertions back in the same confident tone as before. Expect gaps where your systems hold nothing, which in our case meant no demographic detail, and leave those blank rather than letting the model fill them in. And watch the influences field, because without specific instruction the model will describe internal influences when what you need for go-to-market is who influences this person from outside the company.
Step four closes the loop. Take the revised persona to the people who talk to customers every day and ask whether it matches who they actually see. If it does not, you have found something worth knowing before the roadmap does.
Where AI Helps in Persona Work, and Where It Doesn’t
AI is genuinely fast at this work. What matters is what you point it at.
- AI does well: reading a pile of tickets and deal records faster than you can, building a persona from that data with evidence attached, rating which of those claims still need stronger proof, formatting the result into your template, and drafting interview guides.
- AI cannot do: be the customer. Everything in the first list operates on evidence that already exists or on structure. Nothing in it creates new evidence about a real person.
Yes, you can ask AI to write a persona from nothing. We did exactly that with Rachel, and the data took two of her central claims apart within fifteen minutes. The output was fast, well formatted, and wrong where it mattered most. So point the tool at your own data instead. You get the same speed with evidence underneath it.
There is a useful exception on the research side. When Rina asked how AI helps with new markets rather than existing ones, my answer was to start in the CRM and look for deals outside your usual segment, including the ones you lost. Those are indicators of where demand exists that you are not serving. From there, deep research modes can produce a market analysis with sources attached, which gives you a candidate list in hours instead of the couple of months it used to take. Then you go and validate that list with real customers. The AI shortened the front of the process, not the end of it.
If you want to see this kind of work in more depth, we covered using AI for product management work in another session, and our AI Product Management course goes through it properly.
Run It With Your Team: The Productside Persona Pack
Three templates from the Productside Playbook cover this cycle, and they work in order.
| Template | What it does |
| Personas: user and buyer | Build the proto-persona, including the buying authority and influences fields most templates leave out |
| Empathy interviews | Gather the evidence, with a question set built for stories rather than opinions |
| Affinity mapping | Turn transcripts and notes into themes and key insights, then feed them back into the persona |
The loop closes where it started. You rewrite the persona in the customer’s words and drop the proto label, because at that point you have earned the right to.
The Productside Persona Pack is free to download, and you will find the rest of our product management tools and templates alongside it. One practical note on using the persona template with AI: ask the model to write its output directly onto the template image rather than handing you text to paste in. It will offer the text first. Ask again.
Watch the Proto to Proven Working Session
The replay runs about an hour. You will see Rachel generated from a single prompt, watch the model rank her riskiest claims, then watch the CRM and ticket data take two of them apart. The exercise files are the same ones attendees used, so you can run it yourself rather than watch someone else do it.
Here is the debrief table from the session, which is the shortest summary of why this work matters:
| Claim | Rachel said | The data showed | Verdict |
| Primary pain | Late, missing receipts | Month-end close: chasing approvals and reconciling card transactions | Broke |
| Buying authority | Decision-maker | Champion. The CFO signs, and IT security must approve | Broke |
| Employee experience | Employees hate the current tool | Confirmed across tickets and CS notes | Held |
- Watch the Proto to Proven working session and grab the Persona Pack while you are there.
- If you want the full framework behind this work, it is what we teach in Optimal Product Management.
- Disagree on which assumption carries the most risk? Tell us on LinkedIn. We’d rather hear it than guess.
