What Makes a Persona Useless

The useless persona looks like this: "Sarah, 34, Marketing Manager at a mid-size company. She uses LinkedIn daily. She values efficiency. She struggles with [generic pain point]. She wants to [obvious outcome]."

This persona fails because:

1. It's based on assumptions, not research
2. It's so generic it could describe 40% of white-collar workers
3. It has no specificity about the actual workflow or decision context
4. Nobody disagrees with it, so it doesn't help resolve any debates

A persona that doesn't help you resolve debates between product options isn't doing its job.

What Makes a Persona Useful

A useful persona is built from real user research, specific enough to be disputed, and actionable enough to guide real decisions.

The critical difference: real personas contain specifics that generic ones don't. They name the actual tools the user works with, the specific moment in their day when the problem occurs, the exact language they use to describe the problem, and the specific failure modes that drive them away from current solutions.

"Sarah uses Airtable for content calendars, does her first review of the backlog at 9am before joining standups, describes the problem as 'I never know what's actually been approved vs. just discussed,' and has tried 3 scheduling tools that all required too much manual entry to keep updated."

This Sarah can help you make product decisions. The generic Sarah cannot.

How to Build Research-Based Personas

Step 1: Interview first, design later

Don't design personas before talking to users. Start with 8–15 user interviews, then look for patterns. The patterns you find are your personas — not pre-baked archetypes that you apply interviews to confirm.

Step 2: Cluster by behavior, not demographics

The most common mistake: segmenting personas by age, job title, or company size. Demographic segments often have heterogeneous behavior. Behavioral segments (how people use the product, what jobs they hire it for, what their workflow looks like) are more predictive.

"The Planner" (someone who batch-processes tasks weekly) and "The Reactor" (someone who responds to things as they arrive) might both be "Marketing Manager, 28–40, mid-size company." Demographic segmentation obscures this distinction. Behavioral segmentation surfaces it.

Step 3: Write down what you actually observed

In each section of the persona, distinguish between what users said, what you observed, and what you inferred. "Users said they feel overwhelmed by notifications" is different from "users have 400+ unread emails (observed)." Both are useful; conflating them produces unreliable personas.

The Anatomy of a Decision-Ready Persona

A persona that guides real decisions contains:

Context: Where does this person's problem actually occur? Time of day, surrounding workflow, what they were doing when the need arose.

Current behavior: What do they do today? What tools, workarounds, and processes? What's the cobbled-together solution?

Specific frustrations: In their words, not your paraphrase. "I spend an hour every Monday recreating the same report in Google Sheets" is better than "poor reporting tools."

Decision criteria: What would make them choose or abandon a solution? What does good look like for them?

Trigger moments: When do they reach for a tool like yours? What happened right before?

Non-obvious constraints: Budget authority, who else needs to be involved, technical literacy level, time available.

How to Actually Use Personas

The test of a persona: can you sit down with a design decision and ask "how would [persona name] experience this?" and get a specific, differentiating answer?

Good uses of personas:

• "We're designing the onboarding flow. The Planner needs to see the full picture before they can act. The Reactor needs to start immediately with minimal setup. Which persona are we optimizing for with this version?"
• "This feature requires a 3-step setup. For Sarah, who is already managing 5 other tools, this will feel like work. Can we reduce it to 1?"

Bad uses of personas:

• Adding a quote to a pitch deck slide to look user-focused
• Creating personas for personas you haven't validated yet ("there might also be a user type who...")

Two or three well-researched personas that the team actively debates against are worth more than a dozen generic personas that sit in documentation. Keep them visible, keep them current, and use them to end debates — not to start them.