Most user personas end up in a slide deck that nobody opens after sprint two. They read like a casting call for a fictional character, packed with hobbies and favorite coffee orders but missing anything that would change how your team builds software.
I've been thinking about why that is, and I think the problem is that most personas are written for product managers and designers, not for the full team. Developers never see them, so they never use them. And a persona nobody uses is just creative writing.
Here's what actually works.
Keep it to one page
A persona that fits on a single page gets used. One that requires scrolling gets ignored. Here's what belongs:
| Section | What to include |
|---|---|
| Demographics | Name, job title, company size, location |
| Goals | 3-5 professional goals related to your product |
| Pain points | Current frustrations and blockers |
| Behavioral patterns | How they work, buy, and make decisions |
| Technical context | Devices, tools, comfort level with tech |
What to leave out: favorite color, what they eat for breakfast, detailed personal backstories. If a data point wouldn't change a product decision, it doesn't belong.
A quick example
Here's a persona for a B2B project management tool:
Sarah Chen, Senior Engineering Manager, Series B SaaS company (120 people)
Goals: Ship features predictably, reduce meeting overhead, give leadership visibility into sprint progress without daily check-ins.
Pain points: Current tools don't surface blockers early enough. Sprint retros feel repetitive. Estimations are inconsistent across sub-teams.
Behavioral patterns: Prefers async communication. Reviews dashboards every morning before standup. Evaluates new tools by trying the free tier herself before involving procurement.
"I don't need another dashboard. I need my team to spend less time talking about work and more time doing it."
Every detail here connects to a product decision. Sarah's preference for async work means your product needs strong notifications and reporting. Her evaluation behavior tells you the free tier has to be self-serve and compelling.
Where personas actually get used
A persona that doesn't show up in daily work is just a character sketch. Here's where they actually get used:
During backlog refinement, ask "Which persona does this serve?" If the answer is "all of them," the story is probably too broad. If the answer is "none of them," it might not belong in the backlog.
When writing user stories, replace "As a user" with the persona's name. "As Sarah, a remote engineering manager, I want to see sprint progress without attending standup" is immediately clearer and easier to estimate.
In sprint planning, if your primary persona's top pain point isn't addressed in the upcoming sprint, that's worth flagging.
And in retros, try asking "Are we building for our personas, or have we drifted?" Two-minute gut check, surprisingly useful.
How many do you need?
Three to four. More than that and your team can't keep them straight. Fewer than two and you're probably treating a diverse user base as a monolith.
Cover these types:
- Primary user - the person who uses your product daily
- Buyer - the person who makes the purchase decision (often different in B2B)
- Influencer - someone who recommends or blocks adoption
You might also create a detractor persona to understand who your product is not for. Knowing who to say no to is just as useful as knowing who to say yes to.
Don't wait for perfect research
Start with provisional personas based on what you know today. Pull from support tickets, sales call notes, analytics. Five to eight user interviews per segment is enough to spot patterns.
A rough persona that the team actually references beats a polished one that nobody reads. You can always refine later.
The 5-minute version
If you want to get a structured persona fast, I built a free AI User Persona Generator that creates one from a product description in seconds. It's not a replacement for real research, but it gives you something concrete to react to instead of starting from a blank page.
I wrote a more detailed version of this guide with step-by-step instructions and more examples on our blog: How to Create User Personas That Actually Improve Your Product
If your team uses planning poker or retrospectives, you might also find these useful:
Top comments (0)