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.
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
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)
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