Docs / Concepts

Personas

Personas describe who you’re building for: the user archetypes your product serves, with their goals, context, and what they need. Linking features to personas keeps delivery anchored to real users and lets you track how much of each one’s needs has shipped.

A persona might be “Enterprise Admin, who manages seats and security policy for hundreds of users and cares about audit trails, SSO, and bulk operations.” It is a lightweight, shared definition of an audience rather than a detailed research dossier, just enough to keep features pointed at someone real.

What a persona contains

A persona is deliberately simple: a name and a couple of optional fields. Only the name is required:

Name: A short label for the archetype, for example “Enterprise Admin” or “Self-serve Developer.” This is what appears on persona cards, in the feature editor, and as a tag in the feature set.
Role / title: An optional one-line description of who they are, for example “IT administrator at a large org.” Shown as a subtitle beneath the name.
Description: An optional fuller picture of their goals, context, and what they need, for example “Manages seats and security policy for hundreds of users. Cares about audit trails, SSO, and bulk operations.”

Org-wide or project-scoped

Like norms and safeguards, a persona can apply across the whole organization or be scoped to a single project, so an archetype that only matters for one domain doesn’t clutter the others. By default a persona is org-wide (“All projects”); set a scope to limit it to one project. When you’re working in a project, whether choosing personas for a feature or viewing the feature set, you see the org-wide personas plus those scoped to that project.

Who manages them

Personas live on the Personas page, reachable from the sidebar. Only org admins can add, edit, or delete them; everyone else sees them and can link features to them. Keeping authorship with admins means the set stays a deliberate, shared vocabulary for who the product serves rather than a sprawl of one-off labels.

Linking a feature to a persona

When you create or edit a feature, a Personas field lets you tag it with one or more of the personas available in that project; click each one to toggle it on or off. The field only appears once at least one persona exists, so set your personas up first if you want features to reference them.

Personas do double duty. Linking a feature to one is how you track delivery by audience, and the personas available in a project are also part of the context REEZN plans from, so the analysis and the canvas reason about actors and edge cases in terms of the people you actually serve rather than a generic user.

Tracking delivery per persona

A project’s feature set view rolls up progress by persona under “Completion by persona.” For each persona that has linked features, you see how many of those features are complete out of the total, as a percentage, a quick read on how much of that audience’s needs has shipped. A feature counts as complete once it reaches the Approved state (every canvas signed off). Features with no persona are surfaced separately, as a nudge to link them in.

Why this exists

It’s easy to plan features in the abstract and end up serving no one in particular. Naming the persona keeps the conversation on a real person’s needs, not just the mechanics, and tagging features with personas turns that into something you can measure: not only “what have we built?” but “who have we served?”