Product Personas — Build reusable synthetic personas from real research

Take the research material you already have and distill it into 3 to 5 synthetic personas, each saved as a personas/<slug>.md file. A persona is the modeled target: a compact, grounded portrait of one segment that any prompt, Skill or agent can load instead of you re-describing your users from memory every time.

The output is not a slide. It is a small set of files plus an index, a reusable asset that gets more valuable the more you point downstream work at it. Same logic as a brand-voice.md: you freeze the target once so the AI stops guessing who it is talking to.

Hold the distinction clear, because it decides what belongs in the file: a persona is the modeled target, an expert is the evaluator, the PRD is the decision downstream. This Skill builds the target. It does not score your copy (that is mktg-expert-panel), and it does not decide what to build (that is a PRD). It gives those steps someone concrete to react to.

When to use

• You re-type "our user is a non-technical PM who..." in every prompt, from memory, slightly differently each time.
• You have real material sitting unused: interview notes, a survey export, six months of support tickets, call transcripts, and no distilled read of who is actually in there.
• You are about to test copy, audit a landing page, or write evals, and you need a stable target to test against, not a fresh guess each round.

Where this sits among the neighbors:

• Upstream of mktg-expert-panel, mktg-cro-audit and product-evals. Those three all need a target. Personas are it. Point the expert panel at a persona to score copy through its eyes, run a CRO audit against its objections, or turn its pains into eval cases. Build the personas once, reuse them across all three.
• Sibling of mktg-brand-voice on the asset side. Brand-voice freezes how you sound; personas freeze who you are talking to. Both are files you write once and load forever, not one-off outputs.

Input

Real research material, in any of these forms:

• Pasted directly as the argument
• File paths or a folder to read (Glob/Grep over transcripts, exports, ticket dumps)
• A URL to fetch (a public survey report, a review page, a community thread)

Ask for the rawest material available: verbatims over summaries, transcripts over recaps, actual ticket text over a satisfaction score. The voice is in the raw. If the user has no material at all, do not invent it: run the guided discovery below and label the output as hypotheses to validate, never as findings.

Workflow

Phase 1 — Ingest the raw material (or run guided discovery)

If material is provided, read all of it before writing anything. Pull out, per source, who is speaking, what they were trying to do, what blocked them, and the exact words they used. Keep the quotes verbatim: they are the evidence every later phase leans on.

If no material is provided, run a guided discovery of the segment or market instead: ask who they sell to, what those people are hiring the product to do, where they currently look for a solution, and what makes them say no. Fetch a public source (a review site, a forum, a competitor's testimonials) to ground it in real language rather than your assumptions. Mark every unverified claim as a hypothesis.

Phase 2 — Cluster into segments

Group the material by who behaves alike, not by demographics alone. A segment is a set of people with the same job-to-be-done, the same blocker, or the same decision path, even if their titles differ. Aim for 3 to 5 clusters: fewer and you are hiding real differences, more and you are splitting noise. Name each cluster by its defining tension, not its label ("the one who already has a workaround" beats "SMB user"). Note how much material backs each one: a cluster resting on a single quote is a hypothesis, not a persona.

Phase 3 — Write one file per persona

For each cluster, write a personas/<slug>.md file with these sections. Every claim is either backed by a quoted line from the material or explicitly flagged as an assumption.

1. Identity. A name, a role, a one-line who-they-are. Enough to make them concrete, not a novel.
2. Context. Their situation: team size, tools in hand, constraints, what a normal week looks like around the problem.
3. Jobs-to-be-done. What they are actually hiring the product to accomplish, phrased as outcomes, not features.
4. Pains. The frictions and blockers, ranked by how often and how sharply they showed up in the material.
5. Objections. The reasons they say no or stall: cost, trust, effort, prior bad experience. These are what downstream audits stress-test against.
6. Language and real verbatims. The words they actually use, quoted. This is what makes the persona usable for copy and evals: you test against their vocabulary, not yours.
7. Decision criteria. What tips them from no to yes, and who else is in the decision.
8. Channels. Where they already are, where they look for a solution, who they trust.

Keep each file to one screen. A persona that runs three pages is a report, not a reusable target.

Phase 4 — Output the set and an index

Save the persona files under personas/ and write a personas/index.md: one line per persona (slug, name, defining tension, how well-backed), plus a short note on coverage, which segments are solid, which are hypotheses, what material would sharpen them. Tell the user where the files live and how to reuse them: point mktg-expert-panel at a persona to score copy, mktg-cro-audit at its objections, product-evals at its pains turned into cases. The set is the deliverable; the index is how you and the AI navigate it later.

Output example

# Persona: Léa, la PM qui a déjà un bricolage

## Identity
Léa, Product Manager, équipe de 8, boîte SaaS B2B. Non-technique, prompte déjà tous les jours.

## Context
Un Notion plein de specs, un backlog qu'elle trie à la main le lundi.
Valide encore ses features "au feeling" sur l'exemple sous les yeux.

## Jobs-to-be-done
- Décider quoi construire sans attendre trois semaines de recherche.
- Arriver en réunion avec un chiffre, pas une intuition.

## Pains
1. "Je découvre les frictions en prod." (revient 4 fois)
2. Relire 40 pages de verbatims à la main, jamais fini de dépouiller.

## Objections
"J'ai pas le temps de monter un truc de data scientist."
"Comment je sais que l'IA n'invente pas ?"

## Language (verbatims)
"au feeling", "ça a l'air mieux", "je surligne des verbatims".

## Decision criteria
Bascule si ça tient en 20 minutes et se rejoue en 2. DAF sur les coûts.

## Channels
Threads X de PM, newsletters produit, recommandations de pairs.

# Personas — index

| Slug        | Persona | Tension               | Backed by        |
|-------------|---------|-----------------------|------------------|
| lea-pm      | Léa     | a déjà un bricolage   | 6 interviews     |
| marc-fondat | Marc    | décide seul, pressé   | 2 calls (mince)  |

Solide : lea-pm. Hypothèse à valider : marc-fondat (peu de matière).
Prochaine matière utile : tickets support du dernier trimestre.

Rules

• Write the persona files in the user's language; keep this Skill's own instructions in English.
• Ground every persona in the material. A pain, an objection or a verbatim with no source is an assumption, and must be labeled as one.
• Never launder a guess as a finding. Discovery-only personas are hypotheses to validate with real users, not a substitute for research.
• A persona is the modeled target, not the evaluator and not the decision. Do not score copy or write a PRD here; produce someone for those steps to react to.
• Keep each file to one screen and cap the set at 3 to 5. If a cluster rests on a single quote, say so in the index rather than inflating it into a persona.
• Save real files under personas/ with an index. The value is in reuse: a persona that is not on disk cannot feed the panel, the audit or the evals.