Paste "generate 3 personas for a project management app" into ChatGPT and you will get something like this:
Sarah the Marketer. 32, works at a mid-sized marketing agency, uses Slack and Asana, wants to streamline her workflow and save time. Goal: better team collaboration. Pain: too many tools.
This is fiction wearing the clothes of research.
There is no concrete role, because "marketer" could mean CMO or content manager or marketing ops and those three people want completely different products. There is no specific workflow. The goals, saving time and better collaboration, apply to literally every knowledge worker alive. Hand this to an engineer and ask "should we build a Slack integration?" and it tells you nothing at all.
The good news is that the same model produces dramatically better output with the right scaffolding. The bad news is that stock fiction is the default, because it was trained on a decade of lazy persona documents that all look like the one above.
What a useful persona contains
Ten fields separate a persona that changes product decisions from one that decorates a slide.
- Name. Realistic, and not alliterative. "Sarah Shah" beats "Sarah the Marketer."
- Role. Specific title and seniority. "Marketing Ops Manager at a 50-person agency," not "Marketer."
- Company context. Size, industry, stage, revenue band.
- Experience. Years in role, tenure at this company.
- Daily tools. Actual product names. Slack, HubSpot, Notion, Asana. Not "a CRM tool."
- Jobs to be done. Tasks they complete today, with the current friction level attached.
- Goals. Measurable outcomes they care about in the next six months.
- Pains. Specific frustrations with their current workflow, not "wants to save time."
- Representative quote. Something they would actually say out loud, in their voice.
- Why this persona matters. The specific decision this persona should influence, and what breaks if their needs go unmet.
Miss any of the first nine and the persona is decorative. Miss the tenth and it cannot be used for prioritisation, which was the point.
The prompt
Use this as written. Replace the product description and leave everything else alone. The rules are load-bearing, and loosening them collapses the output quality quickly.
I need 3 distinct user personas for this product:
<PRODUCT DESCRIPTION>
Rules:
1. Names must be realistic. No alliteration. No "Sarah the [role]".
Use a real first name and a real last name.
2. Roles must be specific. "Product Manager" is too vague. Use
"Senior Product Manager at a 50-person B2B SaaS startup, 6 years
PM experience, previously an engineer". Include seniority and
company size.
3. Tools must be named products. "Uses a CRM" is banned. "Uses
HubSpot for email, Notion for docs, Slack for team comms" is right.
4. Goals must be measurable and time-bounded. "Improve team
collaboration" is banned. "Cut weekly status-update meetings by
50% this quarter" is right.
5. Pains must be concrete scenarios. "Has too many tools" is banned.
"Spends 4 hours every Monday copying updates from 6 Slack channels
into a weekly report nobody reads" is right.
6. Quotes must be something this person would say out loud in a
meeting. Not marketing copy.
7. Every persona needs a different primary motivation. If two share
one, replace one of them.
8. "Why this persona matters" must state: if we ignore this persona,
which specific feature do we get wrong?
9. If you lack the context to satisfy a rule, output
[OPEN: <question>] rather than inventing detail.
Output as JSON. Schema:
{
"personas": [{
"name": string,
"role": string,
"companyContext": string,
"experience": string,
"dailyTools": string[],
"jobsToBeDone": string[],
"goals": string[],
"pains": string[],
"quote": string,
"whyTheyMatter": string
}]
}
Rule 9 is worth keeping in any prompt of this shape. Without it, a model handed thin context invents plausible detail at the same confident register as everything else, and you cannot tell the difference by reading. With it, the guesses announce themselves.
The five-question audit
Every generated persona should survive this before you use it for anything.
Could I find this exact person on LinkedIn? Search the role and company size. Two hundred real matches means the persona is anchored in something. Zero matches means you invented a job that does not exist.
Do the tools make sense together? A persona using both HubSpot and Salesforce is unusual, since they compete. Slack plus Notion plus Linear is a completely normal tech-company stack. Incoherent tool lists are the fastest tell that the model was pattern-matching rather than reasoning.
Would this pain survive the next two years? "Wants to automate with AI" will date badly. "Spends four hours on Monday status updates" will not. Persistent pains make better product foundations than fashionable ones.
Does the quote sound like speech? Read it out loud. If it sounds like a tagline, rewrite it. Real people speak in fragments and complaints, not value propositions.
Can I name a feature this persona actively does not want? This is the one that catches the most. Good personas have negative space. If your persona would happily accept any feature you proposed, they are too vague to help you say no to anything, and saying no is most of what personas are for.
Fail two or more and the persona is not usable. Regenerate with tighter constraints, or go talk to actual people.
When AI personas are genuinely enough
I want to be even-handed here, because the "AI personas are fake research" take is popular and only half right.
They work well for early-stage direction checks, where rough fidelity is fine and you are sanity-checking whether the product serves anyone real. They work for solo builders with no research budget, where a credible invented persona genuinely beats a nameless "user" as a decision anchor. They work for filling a gap in a proposal when real research would take weeks you do not have. And they work for internal planning on minor features, where the persona is a filter for "does this matter to anyone."
They are not enough for pricing, which needs real willingness-to-pay data. Or for positioning a major launch, which needs the actual language customers use. Or for enterprise B2B go-to-market, which needs named-account research. Or for any decision that is expensive to reverse.
In those cases, use the generated personas as interview prep rather than as the finding. They are a good hypothesis and a bad conclusion.
Red flags in generated personas
Six patterns that mean the output is stock fiction.
Alliteration. Sarah the Strategist, Marty the Marketer. A defining tell.
Round numbers. Exactly 32 years old, exactly five years of experience. Real populations do not distribute that neatly.
Universal goals. "Wants to save time," "values efficiency." True of everyone, useful for nobody.
Zero friction. A persona who loves every tool they use. Every real worker hates at least one thing in their stack, and that hatred is usually where your opportunity is.
No negative space. Accepts any feature. Real users actively reject directions.
Identical quote cadence. Every quote opening with "I just want..." That is the model's voice, not three different people's.
The sanity check I would apply: would you trust this persona enough to kill a feature they do not care about? If not, it is not load-bearing, and you are making decisions on vibes with extra steps.
Personas only pay off if they connect to something
This is the real limitation of a persona generator used on its own, and it has nothing to do with output quality.
A persona named Alex Jiménez is worth something only if the artifacts downstream actually reference Alex. Stories that start "as Alex Jiménez, a Marketing Ops Manager." Acceptance criteria that inherit Alex's permission level. Schema enums that encode Alex's role. Pages that exist because Alex needs them.
| Stage | What personas feed into it |
|---|---|
| Features | Each feature serves one or two personas. Features serving none get cut. |
| User stories | Every story names a persona, so you can filter work by user. |
| Acceptance criteria | Some personas carry elevated requirements, like an admin needing role checks on every story. |
| Schema | Persona roles often become enum values, such as user_role: 'admin' | 'member' | 'viewer'. |
| Pages | Persona journeys decide which pages exist. The admin dashboard exists because an admin persona does. |
With a standalone generator you get three nicely formatted personas and zero linkage. Then you copy-paste names into every later prompt, hope the model retains them, and reconcile by hand when it does not. That reconciliation work is where most persona documents quietly die, about two weeks in.
Whether you solve that with a pipeline or with discipline is genuinely up to you. The failure mode is the same either way: personas that nothing downstream depends on will drift out of date and nobody will notice, because nothing was relying on them.
Related reading
- How to generate an app spec from a prompt, where personas feed the rest of the pipeline.
- Generating user stories with AI, the stage that consumes persona output.
- AI PRD generator and free templates, the document personas feed into.
- Prompt engineering for product managers, for the general pattern behind prompts like the one above.
To get a first set to audit, the Persona Generator produces structured personas from a product description. Free, no signup. Run the five-question audit on whatever comes back before you trust it.
Sources and further reading
- Alan Cooper, The Origin of Personas: where personas came from in interaction design.
- Jeff Gothelf and Josh Seiden, Lean UX: proto-personas for early-stage validation.
- Kim Goodwin, Designing for the Digital Age: full persona development methodology.
- Nielsen Norman Group, Personas: Research Methods: when research-backed personas matter and when assumptions will do.
