Persona and JTBD Analysis

Use during Phase 1 (GATHER) when the user lacks clear personas or the "Who" section needs rigorous definition. Provides structured alternative to ad-hoc persona descriptions.

Persona Template

For each user type, build a complete persona:

## Persona: {Name}

**Who**: {Role description -- one sentence capturing relationship to product}
**Demographics**:
- {Characteristic 1: e.g., technical proficiency level}
- {Characteristic 2: e.g., frequency of interaction}
- {Characteristic 3: e.g., environment/context of use}
- {Characteristic 4: e.g., primary motivation}

**Jobs-to-be-Done**: (see Job Step Table below)

**Pain Points**:
- {Pain 1} -- maps to Job Step: {step name}
- {Pain 2} -- maps to Job Step: {step name}

**Success Metrics**:
- {Quantified outcome 1: e.g., "Task completed in < 2 minutes"}
- {Quantified outcome 2: e.g., "Zero manual configuration steps"}

Job Step Table

Each persona has job steps describing what they accomplish. Steps follow ODI format.

Job Step	Goal	Desired Outcome
{Verb}	{What the user wants to achieve}	Minimize {metric} of {undesirable state}

Rules for Job Steps

• Job Steps are always verbs: Discover, Validate, Install, Configure, Monitor, Recover
• Goals describe what the user wants, not what the system does
• Desired Outcomes use ODI format: "Minimize [time/effort/risk/likelihood] of [undesirable state]"
• Each step maps to a workflow point where value is created or destroyed

Example Job Step Table

Job Step	Goal	Desired Outcome
Discover	Find the right tool for the task	Minimize time to evaluate fit
Install	Get the tool running locally	Minimize steps to working state
Configure	Adapt to local environment	Minimize likelihood of misconfiguration
Verify	Confirm correct installation	Minimize uncertainty about readiness
Start	Begin productive work	Minimize time from install to first output

Pain Point Mapping

Every pain point maps to a specific job step. Pain points without a corresponding step indicate either a missing step or irrelevant pain point.

Pain Point: "I don't know if the tool supports my OS"
  -> Job Step: Discover
  -> Desired Outcome: Minimize uncertainty about compatibility

Pain Point: "Installation fails silently with no error message"
  -> Job Step: Install
  -> Desired Outcome: Minimize time to diagnose installation failures

Prioritize: pain points on high-frequency job steps deserve attention first.

Success Metric Quantification

Every success metric needs a number or threshold. Qualitative metrics ("easy to use") are not actionable.

Qualitative	Quantified
"Easy to install"	"Install completed in < 2 minutes with zero manual steps"
"Fast startup"	"First productive output within 30 seconds of launch"
"Reliable"	"Zero silent failures; all errors produce actionable messages"
"Intuitive"	"New user completes core task without reading documentation"

Multi-Persona Segmentation

Different users have fundamentally different jobs even when using the same product. Segment by relationship to the product.

Common axes: Frequency (first-time vs returning vs power user) | Role (end user vs admin vs developer) | Context (individual vs team vs CI/CD) | Motivation (exploration vs production vs evaluation)

Example: Same Product, Different Jobs

Persona	Primary Job	Key Difference
Explorer	Evaluate the tool quickly	Needs fast time-to-value, minimal commitment
Returner	Resume work after absence	Needs state preservation, quick re-orientation
Deployer	Install for a team	Needs configuration management, multi-user setup
Automator	Integrate into CI/CD pipeline	Needs scriptability, headless operation, exit codes

Each persona gets their own Job Step table because workflows differ. Do not merge personas -- JTBD analysis value comes from surfacing differences.

Integration with Story Crafting

After completing persona analysis, feed results into LeanUX user story template:

1. Persona Who -> populated from persona template
2. Persona Pain Points -> inform story Problem section
3. Job Step Desired Outcomes -> inform AC (ODI outcomes translate to testable criteria)
4. Success Metrics -> inform NFR requirements in handoff package

Cross-reference: use bdd-requirements skill for Example Mapping once personas established. Use jtbd-workflow-selection skill to determine workflow for resulting stories.