Pm Personas Jtbd

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:

1. 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.
2. 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.
3. 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.

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

Source lessons (Uxcel)

• Personas vs. Jobs to Be Done
• Personas in UX Research
• 13 Tips for Creating User Personas
• Defining Target Audience