Skip to main content
A user persona is a fictional but research-based character that represents a segment of your target users. Done well, it keeps the team aligned on who they’re building for. Done badly, it’s a made-up character with a stock photo who gets ignored after the kick-off meeting 😅

​
What a good persona contains

The basics: a name, a role, key goals, and the main frustrations relevant to your product. But the detail that actually makes personas useful goes deeper:
  • The job they’re trying to do - not their job title, but the outcome they’re trying to achieve (see Jobs To Be Done)
  • Their context - when and where do they use your product? Under what constraints?
  • Their level of sophistication - are they a power user or a first-timer? What do they already know?
  • What they’re currently using instead - the alternative is often more revealing than the persona itself

​
The research requirement

The difference between a useful persona and a useless one is whether it’s grounded in actual customer research. A persona built from customer interviews, usage data, and support tickets represents something real. A persona built from internal assumptions represents what your team wishes your users were like. The tell: if everyone on the team agrees immediately on the persona with no debate, it probably wasn’t built from research.

​
The limitations

Personas are a snapshot, not a system. They capture who your users are today but don’t explain why they behave the way they do - that’s what Jobs To Be Done is better at. They also compress real diversity into a single character. Two users can share a persona but have completely different needs. Use personas for alignment and empathy, not as a substitute for talking to actual users 💡 Lesson learned: the most useful thing a persona can do is remind a team that “users” is not a monolith. The moment someone in a meeting says “but our persona wouldn’t do that” - and it sparks a real debate - the persona has done its job 👊