Personas — a tool, not a deliverable.

Personas have a strange place in modern product work. Every team I walk into has either built them and forgotten them, inherited a set from a consultancy and never used them, or, most often, has a passionate disagreement about whether they're worth bothering with at all. The truth is somewhere in the middle and it's narrower than either camp argues. A persona is a tool. A reasonably specific tool, with a clear job to do. When you point it at that job, it earns its keep. When you point it anywhere else, it's pageantry. A glossy poster on the wall of an office nobody works in any more.

The original idea came from Alan Cooper in the mid-1990s, eventually crystallised in The Inmates Are Running the Asylum. Cooper's argument was that software was being designed by engineers for an abstract, imagined "user" who was, conveniently, almost identical to the engineer themselves. The persona was the corrective: a sharp profile, drawn from interview data, that gave the team a specific human to hold in mind when they made a design decision. Would Sarah, the operations manager at a mid-sized logistics firm, find this useful? The question is more answerable than would users find this useful?, and that's the whole point.

The anatomy of a useful persona.

A persona that earns its keep has the same anatomy whether you draw it on a napkin or commission an illustrator to render it. Name. Role. A few demographic anchors (age range, location, technical fluency, only what's load-bearing). Goals: what they're trying to achieve at work and adjacent to work. Frustrations: what gets in their way today. Behaviours, the most important row of the lot: what they actually do, observed, not what they say they want. And a key quote, in their own voice, that captures the essence of the segment.

Notice what isn't on a useful persona. There's no stock photo of a smiling stranger to make her feel "real". There's no astrology, no Myers-Briggs, no inspirational mood board, no list of favourite Netflix shows. The Sarah on a good persona card is a vehicle for a decision, not a character in a novel. Cooper himself was sharper about this than the consultants who later commercialised the format: if a detail wouldn't change a product decision, it shouldn't be on the card.

Behaviour beats demographics. Every time.

The single biggest mistake in persona work is over-weighting demographics. Sarah is 42, lives in Manchester, drives a Skoda Octavia. None of that, on its own, should change what you ship. What changes what you ship is what she does: that she opens the app eleven times a shift but only uses two of its features; that she keeps a paper backup ledger because the app doesn't load on the depot's dodgy Wi-Fi; that she WhatsApps her drivers instead of using your messaging feature because WhatsApps is what they already have.

Behaviour-driven personas tell you what to build. Demographic-driven personas tell you what stock photo to license. The team that builds a persona around "Sarah, the paper-backup logistics ops manager who runs her morning standup off two systems and a WhatsApp group" will make sharper product decisions than the team that builds one around "Sarah, the 42-year-old logistics professional in the North West with a household income of £55k."

The wall-poster trap.

The most common failure mode I see isn't bad personas. It's well-made personas that nobody references after the workshop. The agency runs a great session. Photos get taken. Posters get printed. A laminated stack goes on a shelf. Three months later, ask anyone on the product team to name a persona without looking and you'll get blank faces. The personas didn't make any of the last fifty decisions. They didn't shape a single ticket in the backlog. They didn't show up in a single design review. They're decorative. Beautifully laminated decoration of an idea that never actually informed work.

The fix is structural, not motivational. The personas need to live inside the work: referenced by name in user stories ("Sarah needs to..."), pinned at the top of design files, named in roadmap arguments ("which segment does this serve, Sarah's or the new SMB cohort?"). If the personas don't naturally show up in those moments, they're not earning their keep and you should either retire them or rewrite them sharper. A persona that doesn't shape decisions is taking up space that something else could occupy.

When personas help. When to skip them.

Personas earn their keep in three specific situations. First, when the team is large enough that decisions get made without the most senior product person in the room. The persona becomes a shared reference point that keeps the team aligned without needing the founder to weigh in on every call. Second, when product and marketing have diverged in their language about the customer. A shared persona forces both functions to agree about who they're talking to. Third, when the product serves more than one clearly distinct segment and the team needs a shorthand to debate trade-offs ("this helps Sarah but penalises David. Is that the trade we want to make?").

Skip them when: you're early-stage and have a single, well-understood user type the whole founding team has talked to personally. When your segmentation is genuinely complex and a few personas would caricature it rather than clarify it. When the team is small enough that everyone has the same intuition about the user, in which case the persona is documenting consensus, not building it. And, crucially, when you have richer data: a strong jobs-to-be-done framing often gives sharper decision-leverage than a persona for the same effort.

JTBD as the alternative lens.

Jobs to be done is the most useful alternative to personas, and the two play well together. Where a persona asks who is the user?, JTBD asks what job is the user hiring this product to do? The job lens forgives a lot. It doesn't require you to fit users into pre-built segments, it doesn't make demographic noise feel important, and it generalises more cleanly when the product expands. Many strong teams I've worked with use lightweight personas to align cross-functionally, then run product decisions through a JTBD lens at the spec level. I'll cover that in detail in N°17.

Personas as living artefacts.

If you build personas, build them as living artefacts. Review them every six months, not to redecorate them, but to ask whether the behaviour patterns they describe are still accurate. Sarah's app behaviour from interviews done eighteen months ago may no longer match what your analytics now show. Either update the persona to match reality or, and this is the harder call to make, retire it. A persona that's been allowed to drift is worse than no persona, because the team still references it when making decisions and the decisions are now subtly wrong.

Retire ruthlessly. If a persona hasn't been referenced in three months of real work (not workshop work, real work), kill it. There's no shame in a persona having served its purpose and being put away. The shame is in keeping it on the wall as evidence that research happened.

How we use this at Product Pieces.

Personas live in the Discovery Set Piece kit, not the standing offer. Most teams that ask us to "build personas" actually need either a tighter PO Piece running the backlog with a sharper user lens, or a short JTBD framing engagement to clarify what the product is hired to do. When the persona work is the right answer, we build no more than three, behaviour-led, and we write a one-page test for each: which decisions did this persona shape in the last quarter? If the answer is none, we kill it the next quarter. The artefact serves the decision. The decision never serves the artefact.

Next issue: N°12, The Journey Map. What the user feels, step by step.