Home
cd ../playbooks
Product ManagementBeginner

Proto-Persona

Create a lightweight, hypothesis-driven persona in hours from existing research, market signals, and team knowledge — a working customer profile before deeper validation.

60 minutes
By communitySource
#persona#discovery#research#lean-ux#customer-profile

Your stakeholder deck has "Manager Mike, 30-45, lives in SF, has a dog" — and that demographic snapshot tells you nothing about whether he'd use your product. A proto-persona is a hypothesis: behavioral, quote-driven, with explicit "assumption — validate" tags. Good enough to align the team in a day. Not so polished you forget to validate it.

Who it's for: PMs aligning teams pre-research, UX leads kicking off design, founders without deep customer knowledge yet, product teams identifying research gaps

Example

"Create a proto-persona for our analytics tool's primary user" → Manager Mike (Director, mid-sized SaaS) + quotes + pains (10 hrs/week in meetings) + trying to (deliver 2 weeks ahead) + decision authority ($10k budget, exec approval above) + [ASSUMPTION—VALIDATE] tags

CLAUDE.md Template

New here? 3-minute setup guide → | Already set up? Copy the template below.

# Proto-Persona

Create a lightweight, hypothesis-driven persona from current research, market signals, and team knowledge. A working customer profile that prevents design-by-committee while acknowledging you don't have all the answers yet.

Not a validated persona. Not demographic data alone. Not permanent.

## Proto vs. Validated

| Proto-Persona | Validated Persona |
|---------------|-------------------|
| Hours/days | Weeks/months |
| Assumptions + limited research | Extensive user research |
| Aligns teams early | Guides detailed design |
| Evolves rapidly | Stable |
| Good enough to start | High confidence |

## Why Use Proto-Personas

- **Speed** — align teams without months of research
- **Focus** — shared "who we're building for"
- **Hypothesis framing** — assumptions explicit, then validate
- **Prevents generic design** — design for everyone = design for no one

**Anti-patterns:** Not validated research. Not a research replacement. Not demographics alone. Not permanent.

## When to Use

**Use:** Early-stage development, new feature/pivot kickoff, stakeholder alignment, identifying research gaps.
**Don't use:** After extensive research (graduate to validated), mature products with known segments, as quantitative substitute.

## Application

### Step 1: Gather Available Context

- User research (interviews, surveys, tickets)
- Analytics (usage, demographics, behaviors)
- Market data (industry reports, competitors)
- Stakeholder insights (sales, support, CS)
- Product context (`problem-statement`)

If missing: note gaps. Don't fabricate.

### Step 2: Define Identity

**Name** — alliterative, memorable ("Manager Mike," "Startup Sarah").

**Bio & Demographics** (only those that influence product decisions):
- Age range
- Geographic location
- Social status
- Online presence
- Leisure activities
- Career status

Behavioral, not just demographic. "Works remotely, active in Slack communities" beats "30-40, lives in SF."

### Step 3: Capture Voice

**Quotes** (real or representative):
- Reveal mindset, not just facts
- "I'm drowning in manual work and can't focus on strategy" beats "I need better tools"

If no real quotes: tag `[PLACEHOLDER—NEEDS RESEARCH]`.

### Step 4: Document Context

**Pains** — specific problems related to your product space.

**What they're trying to accomplish** — observable behaviors/outcomes (not internal goals).

**Goals** — short-term + long-term, personal + professional.

### Step 5: Understand Influences

**Decision-Making Authority** — yes/no + context (budget limits, approval levels).

**Decision Influencers** — boss, peer Slack channels, analyst reports, Twitter, etc.

**Beliefs & Attitudes** — focus on those affecting adoption ("skeptical of training-heavy tools," "values data-driven decisions").

### Step 6: Validate & Iterate

- Share with team — does it resonate?
- Tag uncertainties: `[ASSUMPTION—VALIDATE]`
- Plan research to fill gaps
- Update as you learn; graduate to validated when confident

## Mini Example

```markdown
### Name
Manager Mike

### Quotes
- "I spend more time in status meetings than actually building product."
- "My team expects answers immediately, but I'm constantly searching for data."

### Pains
- 10 hours/week in low-value meetings
- Can't find historical decisions across tools

### Trying to accomplish
- Deliver projects 2 weeks ahead of schedule
- Make data-driven decisions without 3-hour data hunts
```

## Common Pitfalls

1. **Demographics without behavior** → add "remote, async-first, 5 Slack communities"
2. **Treating proto as fact** → use `[ASSUMPTION—VALIDATE]` tags
3. **10 proto-personas** → start with 1-2 (primary + secondary)
4. **Fabricated quotes** → mark as placeholder until research
5. **Never validating** → plan research sprints; graduate when confident

## References

- `problem-statement` — persona informs "I am"
- `jobs-to-be-done` — informs pains/goals
- `positioning-statement` — persona is "For [target]"
- `user-story` — "As a [persona]"

**External:**
- Alan Cooper, *The Inmates Are Running the Asylum* (1998)
- Jeff Gothelf, *Lean UX* (2013) — proto-personas
- Indi Young, *Mental Models* (2008)
README.md

What This Does

Walks through name → bio → quotes → pains → trying-to-accomplish → goals → decision authority → influencers → beliefs, with [ASSUMPTION—VALIDATE] tags for everything not backed by research. Outputs a hypothesis-driven persona that aligns teams quickly without pretending to be validated research.

Pairs with problem-statement, jobs-to-be-done, positioning-statement, and user-story.


Quick Start

mkdir -p ~/Documents/ProtoPersona
mv ~/Downloads/CLAUDE.md ~/Documents/ProtoPersona/
cd ~/Documents/ProtoPersona
claude

Provide whatever context you have — interview snippets, support tickets, sales call notes, market reports. Claude drafts the persona and tags assumptions for validation.


The Sections

Section Purpose
Name Alliterative, memorable
Bio & Demographics Only behavior-relevant details
Quotes Reveal mindset (real or [PLACEHOLDER])
Pains Specific, related to your product space
Trying to accomplish Observable outcomes
Goals Short + long term, personal + professional
Decision Authority Buying power + approval levels
Influencers Who shapes their decisions
Beliefs & Attitudes Affect adoption

Tips & Best Practices

  • Behavior over demographics. "Active in 5 Slack communities" beats "lives in NYC."
  • Tag assumptions. [ASSUMPTION—VALIDATE] keeps the team honest about what's a guess.
  • Start with 1-2. Primary + secondary. Adding more before validating creates analysis paralysis.
  • Real quotes only. Or mark placeholder. Fake quotes ("I love delight!") create fake empathy.
  • Plan to graduate. A proto-persona that's never updated is a fossil. Validate, evolve, or replace.

Common Pitfalls

  • Demographic snapshot with no behavioral context
  • Treating proto-persona as validated fact
  • Building 10 personas before validating any
  • Fabricated quotes that sound like marketing copy
  • Never updating the persona as research comes in

$Related Playbooks