Personas Are Useful Until They Become an Excuse

A persona is supposed to do one job: replace a team's vague, shifting idea of 'the user' with something specific enough to make decisions against. Done well, early in a project, that's exactly what it delivers - a name, a context, a set of goals and frustrations that everyone in the room can picture the same way. Done badly, or simply left unattended for too long, a persona stops describing users and starts describing an assumption that got frozen in time. The tool is the same in both cases. What changes is whether anyone is still checking it against reality.

The early value is easy to underrate because it looks so simple. Before a persona exists, 'the user' means something slightly different to everyone in a meeting - the designer is picturing someone patient and detail-oriented, the engineer is picturing someone who reads documentation, the salesperson is picturing whoever they talked to last week. A well-built persona, grounded in actual interviews and observation, collapses that into one shared reference point. It doesn't need to be exhaustively accurate to be useful here - it needs to be specific enough that two people can disagree about a design decision by pointing at the same imagined person instead of two different ones.

Picture a team building an onboarding flow for a productivity app, working from a persona built out of a round of interviews with time-pressed managers: someone who signs up on a lunch break, gets interrupted twice in the first five minutes, and abandons anything that asks for more than two decisions before showing value. That persona earns its place in every early conversation about flow length, default settings, and what can wait until session two. It's doing exactly what a persona should do - turning a vague design instinct into a concrete, checkable claim about a specific kind of person.

The trouble starts quietly, usually around the second or third project that reuses the same persona without revisiting the research behind it. The market shifts, the product picks up a different kind of user than it launched with, competitors change what people expect by default - and none of that shows up anywhere, because the persona itself never changes. It just keeps getting pulled up in the same slide, described in the same present tense, as if the interviews it was built from happened last month instead of two years ago. Nobody decided to stop updating it. It simply became easier not to.

What makes this hard to notice is that the persona doesn't look stale. It's still detailed, still has a name and a photo and a neat paragraph of goals and frustrations - all the surface markers of a well-made research artifact. What's missing is the part that doesn't show up on the slide: the date the underlying research was gathered, and whether anyone has checked since then whether it still holds. A persona built from real interviews and a persona built from someone's best guess about what those interviews might have said look identical once they're both formatted the same way in a deck.

The clearest symptom shows up in how the persona gets used in conversation. A healthy use sounds like a question: 'would Sarah actually do that - has anyone checked recently?' It invites someone to go find out, and treats the persona as a hypothesis worth testing against a real decision. An unhealthy use sounds like a verdict: 'Sarah wouldn't do that,' stated flatly, closing the conversation rather than opening it. The first version treats the persona as a standing question about real users. The second treats it as a fact that no longer needs checking - which is precisely the moment a persona stops being research and starts being an excuse not to do any.

This drift happens for organizational reasons more than intellectual ones. A persona that's been in the deck for two years has accumulated a kind of institutional authority that a fresh finding hasn't earned yet - it's been cited in enough roadmap reviews and onboarding decks that questioning it can feel like questioning something settled, even when nobody in the room actually knows how current the research behind it is. Checking it means scheduling more research, which competes for the same time and budget as everything else on the roadmap. Simply citing it costs nothing. That asymmetry, repeated across enough meetings, is how a research artifact quietly turns into an unexamined assumption.

There's a broader critique of personas worth taking seriously here too - that they flatten real diversity into a tidy stereotype, and that a fictional 'Sarah' was always a simplification with limits, however current the research behind her. That's a fair caution about the format itself, and it argues for keeping personas provisional and specific rather than treating any single one as a complete picture of a user base. But it's a different problem from staleness, and conflating the two lets teams off the hook too easily - a persona can be a reasonable simplification and still be actively wrong, simply because the research it simplified is years out of date.

Keeping a persona honest doesn't require a heavy process, just a deliberate one. Give each persona a review date the same way a technical document gets a version number, and treat that date as a real trigger, not a formality - when it passes, someone actually checks the persona's core claims against a small round of current research before the persona gets cited again. If nobody owns that check, build in a lighter tripwire instead: any major product or market shift automatically puts every existing persona up for revalidation, rather than waiting for a scheduled date that's easy to let slide when things get busy.

A related failure mode is persona sprawl - a new team, a new initiative, or a new stakeholder who didn't trust the old research quietly produces another persona instead of updating the existing one, until a product has six overlapping, slightly contradictory personas nobody fully believes and nobody has the authority to consolidate. The fix isn't more personas, it's fewer, better-maintained ones, with a single clear owner responsible for retiring or merging anything that duplicates an existing one. A crowded wall of personas is usually a sign that revalidation has been skipped often enough that people have given up trying to fix the old ones and started over instead.

Reintroducing healthy skepticism is mostly a habit of asking one blunt question out loud before a persona gets to settle anything: when was this last checked, and against what? Asking it doesn't require distrust of the original research - it requires treating a persona the way any other perishable input gets treated, with an expiration date implied even when it isn't printed on the page. Teams that build this into their normal review rhythm rarely end up debating a two-year-old assumption as though it were current fact, because the question gets asked long before the assumption calcifies that far.

A persona was never supposed to be a fact about users - it was supposed to be a standing invitation to keep checking one. The moment it stops inviting that check and starts substituting for it, the tool has quietly flipped from something that sharpens a team's thinking into something that excuses them from thinking at all. The fix isn't to abandon personas; it's to remember that the useful ones were always temporary by design, built to be replaced the moment the users they described moved on without them.