| name | pm-personas-jtbd |
| description | Build or critique an audience-understanding artifact — research-based user personas, a Jobs-to-Be-Done framing, or the choice between them. Grounds the work in real research (never invented demographic fiction), keeps only detail that changes a decision, and picks the lens by research objective, stage, and resources. Applies the always-true core and gates context-dependent decisions (personas vs. JTBD vs. both, research-based vs. proto, how many personas, which details, segmentation depth, AI's role). Trigger when asked to create user personas, define a target audience/segment, apply Jobs-to-Be-Done, decide who the product is for, or review existing personas. |
| license | MIT |
| metadata | {"author":"uxcel","version":"1.0.0"} |
Personas & Jobs-to-Be-Done Skill
How this skill behaves (read first)
This is a generative skill, and personas are where an AI assistant is most tempted to do exactly the wrong thing. Asked to "make some personas," the default is to invent plausible demographic fiction — "Sarah, 32, marketing manager, loves yoga and oat-milk lattes" — with no research basis, needs inferred from demographics, and a pile of irrelevant lifestyle detail. Uxcel's own source is blunt about it: LLM-generated personas reflect generic internet stereotypes and underrepresent edge cases and minority users. A useful persona instead synthesizes real research into a memorable character whose every detail could change a design decision — or, when what matters is the progress a user is trying to make, a Job-to-Be-Done is the better lens. So this skill gates:
- Establish the research objective, the stage/data you have, and the resources — these decide whether to use personas, JTBD, or both, and whether you even have the evidence to build one yet.
- Apply the always-true core — ground in real research, keep only decision-relevant detail, use JTBD for the job and personas for the who, keep the set small, build as a team, and keep it alive.
- Surface the context-dependent decisions (lens choice, research-based vs. proto, count, which details, segmentation depth, AI's role) with trade-offs.
Then it hands off to pm-assumption-rigor-audit — the check that the persona's claimed needs and behaviors rest on evidence, not assumption.
Scope: this skill owns the audience-understanding artifact. It defers the research process that feeds it to pm-discovery (including ethical/inclusive recruitment), framing the user problem to pm-problem-statement, turning a persona + job into stories to pm-user-story, and behavioral/cohort analytics depth to pm-analytics.
Step 0 — Establish context before building
Ask if not known; state the assumption if proceeding without an answer:
- What's the research objective? Understanding motivations and unmet needs → JTBD. Targeted marketing / team alignment around who → personas. Guiding product development → both. The objective picks the lens.
- What stage are you at, and what data exists? Early stage with only qualitative interviews → JTBD or a clearly-labeled proto-persona. Established product with analytics + research → research-based personas. Do not fabricate what you don't have.
- What resources and time? JTBD leans on deeper qualitative interviews (more costly); personas can start from analytics and short surveys (quicker, broader).
- Who is the artifact for? A diverse team that needs a shared, relatable reference → personas. A team hunting unmet needs and innovation → JTBD.
The always-apply core (true for any persona or JTBD work)
- Ground it in real research — never fiction, never AI stereotype. A persona synthesizes patterns found in interviews, field studies, surveys, and analytics. If no research exists yet, build a proto-persona labeled as an assumption placeholder and test it — don't pass it off as validated. AI (including this assistant) is a synthesis and drafting aid once you have real data; it is not a research substitute, because generated personas reproduce generic stereotypes and erase edge cases.
- Every detail must change a design decision. The test for any attribute: would it change a decision? If not, cut it. Lead with psychographics (goals, pain points, motivations, behaviors) — the layer that drives decisions — and include demographics only when relevant to how the person uses the product. Irrelevant detail doesn't add richness; it erodes the team's trust in the whole persona.
- Don't derive needs from demographics. Two people of the same age and income behave differently. Demographics are a starting point for segmentation, not the source of needs — build needs from research insight.
- Use JTBD for the job, personas for the who. JTBD asks what progress the user is "hiring" the product to make ("users hire it, and fire it when it disappoints") — focused on the outcome, more stable than demographics, and strong for innovation and differentiation. Personas add the empathy, context, and feelings JTBD misses. They're complementary: a job like "find a product quickly" may span several personas, which is exactly what makes it worth prioritizing.
- Keep the set small, with a clear primary. Most products need ~3–5 (up to 7) personas. Merge groups that would make the same design demands; drop segments too small to influence decisions. Designate one primary persona per product area (decisions default to serving it) and treat others as secondary (accommodated, never overriding).
- Build as a team and test with scenarios. Involving researchers, designers, and PMs surfaces assumptions and earns trust. Write short scenarios (a persona pursuing a goal) to anchor requirements in real context and to pressure-test whether the persona is credible.
- Keep it alive. A persona is a snapshot, not a permanent record. Merge two that have converged, split one that's gotten too broad, and revise as the product, market, or user base shifts — teams that revise more often rate their personas as far more impactful. Having a persona is not an excuse to stop talking to users.
To narrow from "everyone": define the target market (who has the strongest need and access), then the target audience (the specific segment for a given release), layering demographic → psychographic → behavioral data before giving the segment life as a persona or job.
The context-dependent decisions (surface, don't auto-apply)
Present each with its trade-off and a recommendation tied to Step 0; let the user choose. Defaulting to "generate three demographic personas" is the failure mode.
| Decision | Apply when | Avoid / adapt when | Default recommendation |
|---|
| Personas vs. JTBD vs. both | JTBD for motivation/unmet-needs/innovation and early-stage; personas for team alignment, marketing, and the "who" of an established product | Forcing one lens regardless of the objective | Match to research objective + stage; use both for product development (personas = who, JTBD = what) |
| Research-based vs. proto-persona | Proto-persona only as a labeled placeholder when research doesn't exist yet | Presenting a proto-persona (or an AI-drafted one) as validated | Proto only to make assumptions visible; replace with research-grounded as soon as data arrives |
| How many / primary–secondary | Multiple personas only for genuinely distinct user groups | A persona per micro-segment — unmemorable and unmaintainable | As few as cover meaningful variation (~3–5); one primary per product area |
| Which details to include | Only attributes that would change a design decision; demographics when relevant to use | Demographic fiction, lifestyle filler, idealized stock-photo stereotypes | Psychographics-first; keep it to 1–2 pages; cut anything that wouldn't move a decision |
| Segmentation depth | Demographics as a starting frame, then psychographics (why) and behavior (how) for real groups | Segmenting on demographics alone and inferring needs from them | Layer demographic + psychographic + behavioral, grounded in first-party data |
| AI's role | AI to cluster transcripts, surface patterns, and draft profiles after real data is collected | AI to invent the persona from a prompt (generic stereotypes, missing edge cases) | Use AI for synthesis and formatting; the starting point is always fieldwork |
Validate the result (orchestration)
Hand-offs name each lens by its installable skill name. Invoke one only if that skill is installed; if it isn't, this skill's own core already carries these rules — proceed without it rather than blocking.
After producing or revising, hand it to the audit lenses rather than declaring it done. These are candidate lenses — posture per docs/orchestration-policy.md, or route the whole artifact through pm-product-review. Here assumption-rigor is the always-relevant lens (auto-runs); the others are offered, tied to what the artifact actually contains. If the user invoked this skill for one specific thing, respect that scope.
pm-assumption-rigor-audit (auto-runs) — the core check: are the persona's needs, goals, and behaviors (or the job's desired outcome) grounded in evidence and a real pattern, or quietly assumed — inferred from demographics, carried over from a proto-persona, or generated from generic priors? Flag the load-bearing claims that haven't been validated and need a research pass.
Composition (per docs/orchestration-policy.md §9): the artifact then feeds the rest of PM work rather than being audited by it. The research that grounds it (pm-discovery) is an upstream input. The problem framing (pm-problem-statement) and the user stories (pm-user-story) the persona + job become are downstream (offer to produce next, don't auto-generate). If the audit shows the persona is mostly assumption, resolve toward the purpose: a persona exists to keep a real, specific user present in every decision — if it isn't grounded in research, it's a stereotype wearing a name tag, and it will mislead the team. For a full idea-to-plan build, pm-idea-to-plan is the compositional front door that sequences this step with the rest of the ladder and enforces evidence before the spec.
Common do/don't patterns
| ❌ Don't | ✅ Do |
|---|
| Invent "Sarah, 32, loves yoga" from a prompt | Synthesize a persona from real interviews, analytics, and field research |
| Treat an AI-generated persona as research | Use AI to cluster/draft your data; fieldwork is the starting point |
| Infer needs from age/gender/income | Build needs from research; demographics are only a segmentation starting point |
| Stuff the persona with lifestyle trivia | Include only detail that would change a design decision; psychographics first |
| Pick personas because they're familiar | Choose the lens by objective — JTBD for the job, personas for the who, both for product dev |
| Ship a proto-persona as fact | Label assumptions as a placeholder and test them |
| Spin up a persona per micro-segment | ~3–5, merge similar, drop peripheral, name one primary |
| Create personas once and frame them on a wall | Build as a team, test with scenarios, revise as data shifts |
| Ship the persona unchecked | Hand off to assumption-rigor to flag unvalidated claims |
Source lessons (Uxcel)
