July flash sale
Personas have a shelf life
A persona is a research-based representation of a meaningful user or customer group. Markets, workflows, technology, regulations, and product adoption change. A once-useful persona can become a confident description of customers who no longer exist. Persona decay occurs when the artifact continues to drive roadmap and feature decisions after its evidence, behaviors, or distinctions have expired.
Symptoms of a decaying persona
- Teams cannot identify the research sources or their dates.
- The persona is defined mainly by age, job title, or invented biography.
- Support and usage data contradict the documented workflow.
- Every new customer is forced into an existing persona.
- Different personas lead to identical product decisions.
- The artifact never changes after launches or market shifts.
Run a persona evidence audit
| Evidence area | Audit question | Possible signal |
|---|---|---|
| Behavior | Do customers still pursue the goal this way? | New channel or workaround dominates |
| Need | Is the problem still consequential? | Frequency or severity has fallen |
| Context | Have policy, device, role, or environment changed? | Old constraints no longer apply |
| Distinctiveness | Does this group require different decisions? | Segments now behave similarly |
| Coverage | Who is missing from the current model? | Emerging group experiences different harm |
Choose the right maintenance action
Update a persona when the group remains meaningful but behaviors or context changed. Split it when credible subgroups have different goals, constraints, or product responses. Merge personas when distinctions no longer alter decisions. Retire one when the segment has disappeared, is no longer served, or lacks enough evidence to justify separate treatment. Create a new persona only when research reveals a stable, decision-relevant pattern.
Do not confuse buyers, users, and affected people
Enterprise solutions may involve an economic buyer, administrator, daily user, support operator, and person affected by an automated decision. One composite persona hides conflicts among them. Model roles separately when their goals and risks lead to different features, guardrails, or journey moments, then show relationships across the experience.
Governance lightweight enough to survive
Give each persona an evidence owner and last-reviewed date. Link source research, affected journeys, critical assumptions, and decisions it informs. Review after major market or policy changes and when outcome data deviates from expectations. Avoid a fixed review ceremony that republishes the same slide without new evidence.
Example: the branch-dependent customer
A financial product persona assumes customers rely on branches for identity help. New evidence shows most use assisted digital support, while a smaller accessibility segment still depends on branches for a distinct reason. The team retires the broad branch-dependent description, updates the mainstream digital persona, and creates a research-supported accessibility context rather than erasing the smaller group.
The customer-centric product practices in SAFe POPM training help teams connect personas to journeys, features, and outcome measures. Leading SAFe certification training supports decisions where segment coverage affects strategy or value-stream design.
Retirement is a product decision
Archive the old version with the reason, evidence, replacement mapping, and affected backlog or roadmap items. Search for features, metrics, and assumptions that reference it. A persona is safely retired only when downstream decisions no longer depend on its obsolete claims.
Communicate the change in language teams can apply: which old assumptions are invalid, which decisions now use the replacement, and where uncertainty remains. Updating the illustration while leaving backlog criteria, analytics segments, and journey maps untouched is cosmetic maintenance, not persona governance.
