Posts

How to create user personas that actually improve your product

Product team gathered around a whiteboard with colorful persona cards pinned to it, discussing user needs and behaviors during a product planning session

Kelly Lewandowski

Last updated 25/02/20267 min read

Most user personas end up in a slide deck that nobody opens after sprint two. They read like a casting call for a fictional movie character, packed with hobbies and favorite coffee orders but missing anything that would change how your team builds software. A useful persona does something specific: it helps your team make better product decisions, faster. This guide covers how to create personas that your team will actually pull up during backlog refinement and sprint planning.

What is a user persona?

A user persona is a fictional representation of a real user segment. It captures who your users are, what they're trying to accomplish, and what gets in their way. The best personas are grounded in research, not assumptions, and they stay focused on information that affects product decisions. In agile teams, personas are a shared reference point. When someone writes a user story that starts with "As a user," the immediate follow-up should be "Which user?" Personas give that question a concrete answer.

The anatomy of a strong persona

Skip the four-page biography. A persona that fits on a single page gets used. One that requires scrolling gets ignored. Here's what belongs in an agile persona:

Section	What to include	Why it matters
Demographics	Name, job title, company size, location	Grounds the persona as a real person
Goals	3-5 professional goals related to your product	Drives feature prioritization
Pain points	Current frustrations and blockers	Reveals what your product should solve
Behavioral patterns	How they work, buy, and make decisions	Shapes UX and feature design
Technical context	Devices, tools, comfort level with tech	Informs technical constraints
Evaluation criteria	How they assess solutions, deal breakers	Guides positioning and onboarding

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 in the persona.

How to create user personas step by step

Start with what you already know

Pull data from support tickets, sales call notes, analytics, and user feedback. You probably know more about your users than you think. Look for recurring patterns in who reaches out, what they ask for, and where they get stuck.

Talk to real users

Five to eight user interviews per persona segment is enough to spot patterns. Ask about their workflow, not your product. "Walk me through how you handle X today" reveals more than "What features do you want?"

Identify clusters

Group your findings by shared goals and pain points, not by demographics. A startup CTO and a mid-level engineering manager might have the same goals but completely different constraints. That's two personas, not one.

Draft the persona

Write it up using the anatomy above. Give them a real name and job title. Keep each section to a few bullet points. If you need a starting point, Kollabe's User Persona Generator can create a detailed persona from a product description in seconds.

Validate with your team

Share the draft with developers, designers, and anyone who talks to customers. The best feedback usually sounds like "That's not quite right, our users actually..." That means the persona is doing its job.

A researcher reviewing interview notes and sticky notes arranged in clusters on a desk, organizing user research findings into persona segments

A real persona example

Here's what a finished persona looks like for a B2B project management tool:

Sarah Chen

Senior Engineering Manager | Series B SaaS Company (120 employees)

San Francisco, CA | Remote-first | Age 34Goals: 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 retrospectives 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.”

Notice how every detail connects to a potential product decision. Sarah's preference for async work means your product needs strong notification and reporting features. Her evaluation behavior tells you the free tier has to be self-serve and compelling.

How many personas do you need?

Three to four. Seriously. 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. If you're unsure which segments to cover, start with these persona types:

Primary user - The person who uses your product daily
Buyer - The person who makes the purchase decision (often different from the user 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 valuable as knowing who to say yes to.

Start provisional

Don't wait for perfect research to create your first personas. Start with provisional ones based on what you know today, then refine as you learn more. A rough persona that the team actually references beats a polished one that nobody reads.

Using personas in your agile workflow

A persona that doesn't show up in daily work is just a character sketch. Here's where they actually get used: Backlog refinement - When reviewing stories, 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 at all. This pairs well with backlog refinement practices your team is already running. User story writing - Replace "As a user" with the persona's name and role. "As Sarah, a remote engineering manager, I want to see sprint progress without attending standup" is immediately clearer and easier to estimate. Strong personas make writing user stories easier. Sprint planning - Use personas to prioritize. If your primary persona's top pain point isn't addressed in the upcoming sprint, that's worth flagging. During planning poker, understanding which persona the story targets helps developers estimate more accurately because they understand the context. Retrospectives - Ask "Are we building for our personas, or have we drifted?" in your next retrospective. It's a useful gut check that takes two minutes.

Agile team during sprint planning, with persona cards visible on a board alongside user story cards, showing how personas connect to daily planning work

Keeping personas alive

Personas go stale. The market shifts, your product evolves, and the users you built personas for six months ago might not match your current user base. Review your personas every quarter. Look at recent support tickets, churn reasons, and new customer profiles. Update the goals and pain points to reflect what you're hearing now, not what you heard during the initial research. A good forcing function: add "persona review" to your quarterly planning agenda. It takes 30 minutes and prevents your team from building for a user who no longer exists.

Wrapping up

User personas work when they're specific enough to inform decisions and accessible enough that the team actually uses them. Keep them to one page, ground them in real data, and put them in front of your team during the rituals that matter: refinement, planning, and retros. If you're starting from scratch or want to fill in gaps, try the free User Persona Generator to create a detailed persona from a product description in seconds. Then refine it with your own research.

A user persona represents the person who uses your product day to day. A buyer persona represents the person who makes the purchase decision. In B2C they're often the same person. In B2B, the buyer is typically a manager or executive who may never log in.

Review them quarterly. Look at recent support data, churn reasons, and sales conversations to see if goals and pain points have shifted. A quick 30-minute review prevents your team from building for outdated assumptions.

AI tools like a persona generator are great for creating a structured starting point, especially when you need to move fast. But they work best when refined with real data from interviews, analytics, and customer feedback. Use AI to draft, then validate with research.

Yes. Developers who participate in persona creation write better user stories and ask better questions during refinement. Include them in the research and review process.