User Personas: Build for a 'Who', Not a 'What'

Why it exists

Products fail when they don't solve a real problem for a real person. Without a clear picture of the user, teams build features for themselves or a generic, non-existent audience. Personas were created to force this clarity and empathy, making the user a concrete "person" in the room during all decisions.

The mental model

A persona is a composite sketch of your target user, not a real individual. Think of it as a character sheet in a role-playing game. It has stats (demographics), goals (what they want to achieve), and pain points (obstacles). When faced with a product decision, you don't ask "what's a cool feature?"; you ask "what would 'Data-Driven Dana' need to do her job better?".

How it works

Personas are built from qualitative and quantitative research: user interviews, surveys, analytics data, and market analysis. The output is a one-page document that includes a name, a photo, demographics (age, job title), goals, frustrations, and motivations. The key is to distill research into a memorable, empathetic portrait that the entire team—from engineering to marketing—can reference. It makes the abstract user tangible.

When to use it

Use personas at the start of any product development cycle to define the target audience. They are essential for prioritizing features ("Does this help our primary persona achieve their main goal?"), designing user interfaces ("Is this workflow intuitive for this persona's technical skill level?"), and writing copy ("Does this message resonate with this persona's motivations?"). They are a constant reference point.

When not to use it

Do not create personas based purely on stereotypes or internal assumptions without data; this is worse than having none. Avoid creating too many personas; 3-5 is a common maximum, as more will dilute focus. Also, don't treat them as static documents. As you learn more about your users, your personas should be updated. They are living hypotheses, not stone tablets.

One canonical example

A B2B software company might have two key personas. First, "Developer Dave," the end-user. He's 28, values efficiency, hates clunky UIs, and his goal is to deploy code with minimal friction. Second, "Manager Mary," the buyer. She's 45, manages the budget, is concerned with security and compliance, and may never use the software herself. Building a successful product requires satisfying the distinct needs of both Dave and Mary.