User Personas — Useful Tool or Corporate Fiction?

Personas are one of those things that sounds good in theory.

"Let's create detailed profiles of our users! Give them names! Understand their goals!"

In practice? I've seen teams create beautiful persona documents that nobody ever references. Stock photo of "Sarah, 32, Marketing Manager" pinned to a wall, gathering dust.

But I've also seen personas done right — tools that genuinely changed how teams made decisions. Here's the difference.

When Personas Fail

They're made up. Someone in a conference room invents users from imagination. No research, no data, just assumptions. These aren't personas, they're fiction.

They're too detailed. "Sarah drives a Honda Civic, drinks oat lattes, and has a dog named Max." Cool. None of that affects how she uses our software.

They're too many. 12 personas = no focus. If everyone is your user, no one is your user.

They're not used. Created once, presented in a meeting, then forgotten. If personas don't influence decisions, they're decoration.

What Actually Makes Personas Useful

Personas work when they:

1. Come from real research. Talked to actual users? Great. Made it up? Don't bother.

2. Focus on behavior, not demographics. I don't care that the user is 34 years old. I care that they check the dashboard every morning before their first meeting.

3. Highlight different needs. The point is showing that different users want different things. If all your personas want the same thing, you only have one persona.

4. Get referenced in discussions. "Would [Persona] actually use this?" should be a question that gets asked.

A Better Persona Format

Skip the stock photos and life stories. Focus on what matters:

PERSONA: [Name]

WHO THEY ARE:
[One sentence describing their role]

WHAT THEY'RE TRYING TO DO:
[Their main job/goal with your product]

WHAT FRUSTRATES THEM:
[Pain points we can solve]

HOW THEY USE THE PRODUCT:
[Frequency, context, typical workflow]

SUCCESS LOOKS LIKE:
[How they measure if the product is working for them]

That's it. Half a page. Everything relevant, nothing decorative.

Real Examples That Actually Helped

I've built products for wildly different users. Here are personas that influenced actual decisions:

For a payments platform:

The Finance Controller — Reviews every transaction, needs audit trails, wants exportable reports. Cares about accuracy over speed.

The Operations Manager — Processes hundreds of transactions daily. Needs batch actions, keyboard shortcuts, speed above all. Audit trails? That's someone else's job.

These two users wanted opposite things. Knowing that prevented us from building a one-size-fits-all UI that pleased nobody.

For an internal tool:

The Power User — Uses the tool 4+ hours daily. Knows every shortcut. Gets annoyed by confirmation dialogs and "helpful" wizards.

The Occasional User — Uses it once a month. Forgets how everything works. Needs guidance, can't remember keyboard shortcuts.

We built modes for both. Power users got a dense interface with advanced options exposed. Occasional users got a guided flow with defaults.

How Many Personas?

3-5 for most products. Fewer if you're focused. More than that and you're probably just describing the same user with different demographics.

Questions to ask:

• Do these personas have meaningfully different needs?
• Would we build different features for each?
• Can the team actually remember them?

If two personas would make the same product decisions, merge them.

The Real Test

A good persona should:

• Be recognizable to your sales/support team ("Oh yeah, we talk to this person all the time")
• Influence feature decisions ("We're building this for [Persona], not [Other Persona]")
• Help settle debates ("What would [Persona] actually want here?")

If your personas don't do these things, they're not working.

My Hot Take

You don't need formal personas to build great products. What you need is to actually understand your users.

Talk to them. Watch them use your product. Read their support tickets. Know their problems.

Personas are a tool to communicate that understanding across a team. If you're a solo founder who talks to users weekly, you might not need them. If you're a 50-person team where engineers never meet customers, you probably do.

The format matters less than the understanding behind it.