๐งโ๐คโ๐งUser Personas
Done right, personas are decision tools. Done wrong, they're laminated posters that no one references.
Most personas are useless. Either too generic ('Sara is a busy professional') or too specific (made-up names with no underlying data). A useful persona is short, evidence-backed, and constantly referenced in product debates.
A useful persona is two paragraphs: (1) who they are and what they're trying to accomplish, (2) what they care about and what they avoid. It's grounded in real interviews and behavioral data, references a specific segment, and shows up in PRDs and design reviews โ not just in onboarding decks.
What makes a persona useful
A useful persona has:
- A segment definition. "Solo founders pre-seed to seed, technical background, 1-3 person team."
- The dominant JTBD. "Wants to figure out if there's a market for their idea without burning runway on something nobody wants."
- What they care about (1-2 things). "Speed to first learning. Cost. Time to first revenue."
- What they avoid. "Anything that looks like enterprise software. Long onboardings. Sales calls."
- A representative real quote. Pulled from an actual interview.
Skip the fake photo and the made-up age. Those don't help you make product decisions.
How many personas to have
For most products, 2-4. More than that and the team can't keep them straight. Less than that and you're probably oversimplifying.
If your product genuinely serves more segments, group them by JTBD โ often 8 user-types collapse into 3 jobs.
When to update them
Quarterly minimum. Personas are a snapshot of who you serve today; the customer base shifts, and stale personas misdirect the team.
The signal you need an update: an interview where the person doesn't match any of your personas. If it happens twice, you have a new segment forming.
Bringing personas into the work
- Reference them in PRDs. "This feature is for Persona A; it will likely not be adopted by Persona C."
- Use them in prioritization. "This bet helps Persona B; Persona B is where the growth is; therefore prioritize."
- Use them in design reviews. "Would Persona A understand this label?"
If you can't think of three product debates in the last month where you referenced personas, your personas aren't earning their keep.
Real-world examples
Mailchimp's product team built three personas โ Solo Founder, SMB Marketer, Agency โ and explicitly tracked features by which persona they served. New features had to declare a primary persona; quarterly reviews tracked persona-level adoption. Discipline showed up in the product's coherence.
Go deeper โ recommended reading
Interview questions (1)
Q1Walk me through how you'd build personas for a product you've never worked on before.executionmidโผ
Five steps:
- Talk to sales and support. They've talked to thousands of customers; they know the segments before you do. Get their pattern recognition first.
- Pull the data. Segment the user base by behavior (active vs lapsed, free vs paid, light vs heavy use) and attribute (industry, company size, role). Look for clusters.
- Interview the top 2-3 clusters. 5-10 interviews per segment. Look for shared JTBDs, not just shared demographics.
- Draft 2-3 personas. One paragraph each: segment definition, JTBD, what they care about, what they avoid, real quote.
- Pressure-test in a review. Show the team. Ask: 'does this match your gut?' Refine. Then commit to using them in PRDs for 6 weeks and revisit.
The output isn't perfect personas โ it's personas that actually get used.