AI Personas Are Hypotheses, Not Customer Research

By Abdallah Atef

An AI-generated customer can have a name, a job, a detailed routine and a convincing explanation of why they would buy your product. None of those details establishes that a real customer has the problem, controls the budget or would make that purchase.

The useful leadership question is not whether the persona sounds realistic. It is which parts come from observed evidence, which are interpretations and which were invented to help the team think.

My AI for Business workshop includes audience understanding and market analysis among business applications of AI. My VORTA material also treats strategic assumptions, stakeholder expectations and user-journey impact as matters to examine. The approach below applies those ideas to one specific decision: how much weight should a manager give an AI-generated customer profile?

Distinguish a research summary from a simulated customer

Two outputs can look almost identical while having very different foundations.

An assistant might summarise interviews your team actually conducted, grouping recurring needs into a working persona. That is an interpretation of supplied research. It still needs checking against the original material, including disagreements and people who do not fit the grouping.

Alternatively, it might invent a persona from a short description such as “an operations manager at a growing company.” That can be a useful brainstorming aid, but it is not a new participant. An imagined answer to a buying question is not evidence of demand.

Nielsen Norman Group’s research on synthetic users recommends using generated profiles to develop hypotheses rather than replace research with people. Its evaluation also illustrates how simulated responses can miss the detail and trade-offs present in real accounts. That is a reason to examine the origin of an insight, not simply its presentation.

Put an evidence label beside every useful claim

Before a persona enters a marketing brief or product discussion, classify its claims:

  • Observed: supported by a traceable interview, service interaction or relevant behavioural record. Keep the source and context available.
  • Interpreted: a pattern or explanation drawn from that material. State who made the interpretation and what remains uncertain.
  • Hypothetical: generated or proposed without direct support in the research. Turn it into a question to test.

A single profile may contain all three. For example, an interviewee may have described a difficult approval process, while the team inferred that faster approval would be their main buying priority. An AI-generated biography may then add a budget, an age or a preferred channel. Those additions must not silently inherit the credibility of the interview.

Use the minimum detail needed for the decision. A fictional name can make a workshop easier to follow, but a detailed lifestyle or personality should not distract from the actual work, constraints and purchasing process.

When an assistant summarises existing research, the review of AI summaries and disagreement is relevant: a neat profile must not erase evidence that points in another direction.

Replace simulated enthusiasm with a research question

Consider this fictional example. A team is exploring a maintenance-planning service for small facilities businesses. It asks AI to create a potential buyer. The profile says: “I would pay more for a dashboard that saves me time.”

That sentence leaves the commercial decision largely unanswered. What work consumes the time? Who currently does it? What goes wrong? Does the person who benefits control the purchase? What would they stop using or paying for?

Instead of adding the statement to a slide titled “Customer demand,” make it a research question: “How do facilities teams plan maintenance today, and where does that process create work they would prioritise changing?”

Ask people to describe a recent instance and, where appropriate and permitted, show the current process. Separate a user’s preference from a buyer’s approval criteria. Look for the cost and effort of changing, not only the attraction of the proposed feature.

The GOV.UK guidance on planning user research similarly advises turning unsupported assumptions into research questions and choosing activities that answer them. The method should fit the question: a discussion about recent work answers something different from observing someone use a prototype.

Use a compact claim-to-test record

A manager does not need a long persona document to make this discipline practical. For each claim that could change a decision, record five things:

  1. Claim: what the team currently believes about the customer.
  2. Origin: the specific research source, an interpretation, or a generated hypothesis.
  3. Consequence: which feature, message, price or investment would change if the claim were wrong.
  4. Next check: what evidence would help support, narrow or reject it.
  5. Decision owner: who will review that evidence before the team commits.

For the fictional maintenance service, the claim might be that planning time is the main reason to switch. The next check could examine recent planning work and why an organisation kept its existing approach. A finding that integration effort dominates the decision would change the offer, even if everyone likes the dashboard in principle.

Record what the evidence does not establish as well. A few useful conversations can reveal constraints without showing how common they are across a market. Stated willingness to buy is not a completed purchase. A successful task in a prototype does not establish willingness to adopt it in everyday work.

Keep generated voices out of the findings count

Do not combine simulated responses and human responses into one total. Generating fifty personas does not add fifty customers to your research sample. Likewise, a model repeating an idea across prompts does not show that independent people share it.

Keep synthetic exercises in a clearly labelled section. If you use a generated quotation to explain a concept internally, mark it as illustrative; do not present it as a customer quote or testimonial. When reporting actual research, preserve the distinction between participants, statements and the team’s interpretation.

Protect source material too. Interview notes and customer records may contain personal or commercially sensitive information. Use approved tools and the business-data boundary checks before sharing them. Removing a name alone may not make a detailed account safe to upload.

Approve the decision, not the character

Before accepting a persona-led recommendation, ask: “Which customer evidence would I inspect if I challenged this conclusion?” If the answer is another generated conversation, the team has a hypothesis to investigate, not a customer finding to approve.

AI can help organise research, propose questions and make assumptions visible. The manager’s responsibility is to preserve the difference between a useful imagined perspective and evidence about the people the business intends to serve.

If your team needs a practical way to review AI-supported customer analysis and the decisions it informs, schedule a consultation.

Abdallah Atef home

Copyright © 2025

abdallahatef.com All rights reserved.