Keith Erik Wilson
In my experience, personas have always been useful and almost always badly built. I have watched most teams write them in a half-day workshop, paste them into a slide deck, and never look at them again. AI changes the cost of producing personas dramatically, which finally makes them practical to maintain. But the same AI that produces great personas can produce convincing fake ones, so in my view the discipline matters more than the speed. In this guide I walk through how I generate, validate, and use AI personas without falling into the synthetic-data trap.
AI Personas: How to Generate Buyer Personas in Minutes
The pattern I see across the successful AI persona programmes I have worked with: AI handles the structure and synthesis from real data; humans validate against organisational knowledge and lived customer experience. The teams I see get this balance right have personas that stay current and inform decisions. The teams that let AI invent personas have decorative artefacts that quietly mislead the team.
What an AI Persona Is (and Is Not)
An AI persona is a structured representation of a user segment, generated using AI from real data sources. It includes the segment’s job-to-be-done, pain points, behaviour patterns, vocabulary, decision criteria, and example workflows.
It is not a fictional character invented by an LLM. The distinction is critical. Personas with no real data behind them are dangerous - they justify decisions while being entirely wrong about real users. The discipline of grounding every persona claim in evidence is what separates useful personas from decorative ones.
The shift AI enables: personas can be refreshed monthly rather than annually because the synthesis cost is low. Organisations that previously had stale personas can have current ones. Organisations that never invested in personas can finally afford to.
The Three Inputs Every Quality Persona Needs
| Input | What it provides | Bad substitute |
|---|---|---|
| Real user data | Behavioural patterns, segments, frequencies | “What we think the user is like” |
| Verbatim quotes | Vocabulary, emotional tone, jobs-to-be-done | LLM-generated quotes |
| Quantitative ranges | Realistic numbers (deal size, team size, frequency) | Round-number guesses |
If you cannot point to a real source for each of these, the persona is fiction. Stop and gather data first.
The most common failure is mixing the three. A persona that has real behavioural data but invented quotes feels coherent but misleads in subtle ways. The vocabulary gets wrong; the emotional tone gets generic. Stakeholders who interact with real users notice the disconnect.
Strong personas trace each claim back to specific evidence. A claim about user motivations links to specific interview quotes. A claim about behaviour links to specific analytics data. A claim about decision criteria links to specific sales call transcripts. Without this traceability, persona quality cannot be audited.
The AI Persona Generation Workflow
Step 1: Identify segments from data. Use product analytics or CRM segments. Do not invent. The segments should be defensible based on real user data - usage patterns, deal size, role, industry, etc.
Step 2: Pull qualitative data per segment. Interviews, support tickets, sales calls, surveys. Aim for 20-50 data points per segment for synthesis to work.
Step 3: Cluster and theme. Use the AI VoC workflow (see AI Voice of Customer) to find pain points and jobs.
Step 4: Generate the persona draft. Use the prompt below.
Step 5: Quality-check. Apply the checklist in section 5.
Step 6: Publish and link. Each persona should be linked from the artefacts that need it: PRDs, research briefs, marketing copy.
The discipline that fades fastest is step 6. Teams generate personas, file them in a slide deck, and never reference them in subsequent work. Without active use, personas decay into wallpaper.
Prompts You Can Copy
Persona generation from real data
“Below are 12 user interview transcripts and 50 support tickets from the segment ‘Series A founders using analytics tools’. Generate a persona document with: name (descriptive, not a person’s name), demographics from the data, jobs-to-be-done with frequency, top 3 pain points with verbatim quotes, decision criteria when buying, vocabulary they use, anti-vocabulary they reject, an example workflow, and 2 success scenarios.”
Persona refinement
“Here is a draft persona. Identify 5 elements that read as generic or could apply to any user segment. Suggest specific replacements grounded in the source data.”
Persona validation
“Pick 3 specific claims in this persona. For each, point to the supporting evidence in the source data. If you cannot, flag it.”
Anti-persona generator
“Based on the same data, generate the anti-persona: who looks like our customer but consistently churns or fails to activate. Same structure as the persona.”
Cross-persona comparison
“Below are 4 personas. Identify: where they differ meaningfully, where they overlap, where overlap suggests we should merge them. Surface differences in vocabulary, decision criteria, and pain points.”
Persona-driven feature analysis
“Take this proposed feature and assess: which persona benefits most, which persona is unaffected, which persona might be hurt. Justify with evidence from the personas.”
The Quality Checklist Before You Ship a Persona
Run every persona through this checklist before publishing.
- Does every claim trace to real data?
- Are the verbatim quotes pulled from actual transcripts (not generated)?
- Do the numbers (deal size, team size, frequency) match real ranges from analytics?
- Is the persona specific enough that you could identify a customer who matches it?
- Does it include both jobs-to-be-done and anti-jobs (things they explicitly do not want)?
- Is there a paired anti-persona showing who is not your target?
- Has it been reviewed by someone who has spoken to real users in this segment?
A persona that fails any of these is not ready. The temptation is to publish anyway and refine later; in practice, draft personas that get published become the canonical version, and the refinement never happens.
The most common failure is invented quotes. AI generates plausible-sounding customer quotes that no real customer ever said. The fix is to demand traceable verbatims and reject any output without them.
How Personas Actually Get Used in 2026
Personas are useful only if they are referenced in real artefacts. The pattern that works:
- Every PRD opens by stating the primary persona it serves.
- Every research brief states which persona it interrogates.
- Every marketing campaign states the persona it speaks to.
- Every prioritisation discussion can ask: “for which persona is this most valuable?”
Without those rituals, personas are decorative. With them, they sharpen every product decision.
The rituals also produce a feedback loop: as the team uses personas, gaps in the personas become visible. The persona evolves through use rather than getting fossilised in a slide deck.
For PMs introducing personas to a team that has not used them well before, start with one workflow (typically PRDs). Demonstrate value. Add other workflows progressively. Top-down mandates rarely work; pull-based adoption does.
The Synthetic Data Trap
A growing temptation is to “talk to an AI persona” instead of talking to real users. Tools market themselves on this. The trap:
- AI personas reflect what the model has seen, not your specific users.
- They cannot surface surprise, only confirm priors.
- Decisions based on synthetic personas drift from reality fast.
Use AI to synthesise real data into personas. Do not use AI to invent personas. The difference is everything.
The synthetic data temptation becomes stronger when teams cannot easily access real users. This is precisely when discipline matters most. A team that cannot talk to real users should be solving the access problem, not substituting AI personas for real conversations.
Some research workflows can use AI personas as preparation - imagining how a persona might respond to a feature - but always with explicit framing that this is hypothesis generation, not validation.
The Anti-Persona: Equally Important
Anti-personas describe who you are explicitly not serving. They are equally important and almost always missed.
A useful anti-persona prompt:
“Based on our data, generate the anti-persona for our product. Who looks like our customer in superficial ways but consistently churns, fails to activate, or has poor outcomes? Document with the same structure as the persona.”
The anti-persona surfaces:
- Customers who should not be sold to (sales discipline).
- Use cases the product should not support (scope discipline).
- Marketing channels that attract the wrong segment (acquisition discipline).
- Features that look attractive but serve the wrong segment (prioritisation discipline).
Strong product organisations maintain both personas and anti-personas. The anti-persona is what keeps the product focused.
Maintaining Personas Over Time
Personas decay as the product, market, and customer base evolve. The maintenance routine:
- Quarterly review: refresh quotes, check that data still supports each claim.
- Annual rebuild: full synthesis from current data. Compare to previous version.
- Trigger-based updates: major product pivots, market changes, or organisational reorientation trigger immediate review.
The maintenance cost is low with AI. The cost of skipping maintenance is decisions made on stale personas - which feels productive at the time but produces drift between persona and reality.
For PMs maintaining personas, build a calendar reminder. Without the reminder, the maintenance falls off the priority list.
Personas Across Multiple Segments
Products with multiple distinct user segments need multiple personas. The mistake is to merge them into a “primary persona” that serves no segment well.
The pattern that works:
- 3-5 personas per product is typical.
- Each persona has its own distinct jobs, vocabulary, and decision criteria.
- Cross-persona comparison reveals where the product serves all and where it serves only some.
- The roadmap explicitly states which personas each initiative serves.
For PMOs running multiple products, persona work scales. Each product has its own personas; cross-product personas surface customers who span products. AI helps with the cross-product synthesis that would otherwise be impractical.
Using Personas in Specific Workflows
In PRD writing: lead with the persona served. Justify scope decisions in terms of persona impact.
In feature prioritisation: score features by persona served and impact. Items that serve no persona meaningfully get questioned.
In marketing copy: write to the persona’s vocabulary. Test copy against the persona’s anti-vocabulary.
In sales enablement: teach reps the persona’s decision criteria and objections.
In onboarding design: design flows that match the persona’s first-use behaviour.
In customer research planning: target interviews to confirm or extend the persona understanding.
The pattern: personas are tools, not artefacts. The teams that integrate personas into specific workflows produce sharper output across all of them.
Common Failure Modes
These are the failure modes I have watched destroy otherwise promising persona programmes. Each one is preventable if I catch it before the persona gets shared widely.
- Inventing quotes. I always pull verbatims directly. In my experience, AI-generated quotes that no customer said is the fastest way to destroy persona credibility.
- Overly specific demographics. I tell PMs that personas should describe the meaningful segment dimensions, not invented details that pretend to be specific.
- No anti-persona. Without anti-personas, I see personas drift to “everyone we want to sell to.”
- One-time creation. Personas that never get refreshed decay. Build maintenance into the calendar.
- Politically softened pain points. Personas that hide negative customer feedback because it is uncomfortable produce decisions that ignore real friction.
- Too many personas. More than 5 personas per product becomes unmanageable.
- Personas without numbers. “Mid-market companies” is fuzzy; “100-500 employees, 20-50 in finance team” is specific.
- Skipping the cross-functional review. Sales, support, customer success see customers differently from product. Cross-functional review surfaces blind spots.
With 25+ years of experience in Agile transformation, enterprise delivery, and coaching, Keith brings extensive real-world expertise to Agile leadership. Holding 16+ global certifications, including PMP, CSM, and SAFe, he is an Advanced SAFe Practice Consultant specializing in AI-enabled Agile practices, portfolio management, and Scrum Master development. Known for his high-energy, practical approach, Keith brings years of transformation experience across leading organizations
Questions people ask
Published