Customer persona prompts built from real research

These 13 customer persona prompts help you build personas in ChatGPT or Claude from research you actually did: interviews, surveys, support tickets and sales notes. They extract evidence, group people by goals and behaviour, draft the persona with a source for every line, and check it for invented details. If you have no research yet, the first section helps you get some, because a persona with no evidence behind it is a guess.

How to use these prompts

Copy a prompt, replace the blanks in double braces, or keep the default after the colon: {{product:project management software}} means that product unless you change it. Blanks with no default, like {{transcripts}}, need your own research.

Persona work goes wrong in a predictable way: the model fills gaps with plausible details, and plausible details are hard to spot. Three habits stop that:

• Paste evidence, not descriptions. Transcripts, survey exports and ticket text, not "our users are busy marketers".
• Ask for quotes. Anthropic's guide to reducing hallucinations recommends, for long documents, asking the model to extract word-for-word quotes first and base its work on them, and letting it say "I don't know".
• Label every line. Each statement in a persona should point to a source, or be marked as an assumption.

Nielsen Norman Group's article on three persona types recommends that "For most teams, the best approach for creating personas is by running solid exploratory qualitative research" (such as interviewing users). These prompts follow that approach. For planning and running the research itself, use the customer research prompts and the UX research prompts.

Remove names, emails, company names and anything else that identifies a participant before you paste.

What research do you need before building a persona?

1. Research inventory and gaps

Start with what you already have. Most teams have more evidence than they think, scattered across tools.

I want to build customer personas for {{product:project management software}}.
Here is a list of the research and data I have:

{{research_list}}

For each source, tell me what it can and can't tell me about customers'
goals, context, behaviour and objections. Then list the biggest gaps and
the smallest piece of research that would fill each one (for example, 6
interviews with a specific group). Don't suggest a persona yet.

2. Interview guide for persona research

Persona interviews ask about past behaviour, not opinions about your product.

Write a {{length:45-minute}} interview guide for persona research with
{{participants:people who chose a project management tool in the last 6 months}}.

Focus on: their role and context, what triggered the search, what they
tried before, how they decided, what they do day to day, and what still
frustrates them. Ask about specific past events ("Tell me about the last
time..."), not hypotheticals or feature wishes. No leading questions. Add
follow-up probes under each question.

3. Anonymize notes before analysis

Use it only in a tool your organization has approved for research data, or follow it by hand as a checklist. Either way, anonymize before any other prompt sees the notes.

Below is an interview transcript. Replace every person's name with a
participant code ({{code:P1}}), every company name with a description such
as "a 40-person agency", and remove emails, phone numbers, addresses and
any detail that could identify someone. Keep job titles general. List
every replacement you made in a table at the end so I can check it.

{{transcript}}

Which prompts turn research into personas?

4. Extract evidence per participant

The foundation for everything that follows. One row per participant, every cell backed by a quote.

Here are anonymized interview notes, one section per participant.

{{transcripts}}

For each participant, extract: role and context, main goal, trigger for
looking for a solution, current workaround, key behaviours, frustrations,
and decision criteria. Support each cell with a word-for-word quote and the
participant code. Write "not mentioned" when the notes don't cover it.
Output as a table.

5. Group participants by goals and behaviour

Group by what people are trying to do and how they do it, not by job title or age.

Using this evidence table:

{{evidence_table}}

Group the participants into clusters that share goals, triggers and
behaviours. Ignore demographics unless they clearly change behaviour. For
each cluster: the participants in it, what they have in common (with
quotes), and how it differs from the other clusters. Tell me if the data
only supports one or two clusters, and flag participants who don't fit.

6. Draft a persona with sources

Every line cites its evidence. Lines without evidence are marked, not hidden.

Draft a persona for this cluster:

{{cluster}}

Supporting evidence:
{{evidence}}

Sections: a short descriptive name (role-based, like "The stretched team
lead"), context, goals, triggers, behaviours, frustrations, objections to
products like {{product:project management software}}, and 3 real quotes.
After each line, cite the participant codes it comes from. If a section has
no evidence, write "UNKNOWN: research needed" instead of filling it in.
No invented demographics, hobbies or backstory.

7. Write user needs from the persona

Needs statements turn a persona into something a team can act on. This uses the format from the GOV.UK Service Manual's guide on learning about users and their needs, which says good user needs should be "based on evidence from user research, not assumptions."

From this persona and its evidence, write {{count:6}} user needs in this
format:

As a [type of user], I need to [what they want to do], so that [why].
Optionally add: When [trigger], Because [constraint].

Use words the participants used. Focus on their problem, not on features
we could build. Cite the participant codes for each need.

Persona and evidence:
{{persona}}

How do you check that a persona isn't made up?

8. Evidence audit

Run this on any persona, including old ones nobody remembers the source for.

Audit this persona line by line.

Persona:
{{persona}}

Research:
{{research}}

For each statement, label it: SUPPORTED (quote the evidence and source),
WEAK (one source only, or indirect), or UNSUPPORTED (no evidence in the
research). Then give a summary: percentage of statements in each group, the
3 unsupported statements most likely to mislead the team, and what research
would confirm or reject them.

9. Turn a proto persona into a research plan

If your team already wrote personas from assumptions, treat each line as a hypothesis.

Here is a persona our team wrote from experience, without research:

{{proto_persona}}

Rewrite each statement as a testable hypothesis. Rank them by how much a
wrong assumption would cost us ({{decision:our pricing and onboarding}}),
and for the top 5, suggest how to test it: interview question, survey
question or data to check. Keep the plan small enough for
{{time:two weeks}}.

10. Stress test against new data

Personas age. Paste new tickets, reviews or interview notes and see what still holds.

Here are our current personas:
{{personas}}

Here is new research from {{period:the last quarter}}:
{{new_research}}

For each persona: what the new data confirms, what it contradicts (with
quotes), and anything new that doesn't fit any persona. Recommend whether
to keep, update, merge or retire each persona, with reasons.

How do you put personas to work?

11. Review a page or feature through a persona

The point of a persona is to change decisions. This applies one to something real.

Review this {{asset:pricing page}} from the point of view of this persona.

Persona and evidence:
{{persona}}

{{asset_content}}

Using only what the evidence says about their goals, triggers and
objections: what will they look for first, what will confuse or worry them,
and what is missing? Quote the persona evidence behind each point. Don't
speculate beyond the evidence.

12. Messaging map per persona

Connects each persona's trigger and objections to what you say and where.

For each persona below, build a messaging map: their trigger, the main
problem in their own words (quoted), the outcome they want, our most
relevant proof from these facts, their top objection and our answer, and
the channel where they are most likely to meet us (only if the research
says so).

Personas and evidence:
{{personas}}

Facts about our product:
{{facts}}

13. One-page summary for the team

Long persona documents don't get read. A one-pager with sources does.

Turn these personas into a one-page summary for {{team:the product and sales teams}}.

For each persona: name, one-sentence description, top goal, top frustration,
one quote, and one thing each team should do differently because of it.
Add a line at the bottom stating what research the personas are based on
(number and type of sources, date range) and the main open questions.

{{personas}}

What makes a customer persona useful?

The GOV.UK guide describes personas as groups of users "with similar behaviour and needs", and that is the test: if two personas would get the same product and the same message, merge them.

On consumer Claude plans, Anthropic's model training policy explains when chats can be used to improve Claude and says Incognito chats are not used for that. Check your own tool's settings, and what participants agreed to, before pasting research.

How do you keep persona prompts with the rest of your research?

Persona work repeats every time new research comes in, so the same prompts get reused with new transcripts. Kipt keeps prompts like these as Markdown in a private GitHub repo you own: save them with their blanks, tag them "research", and find them with Cmd+K. For turning a persona into positioning and campaigns, see the marketing prompts.