Name one person, not a segment

Your team has done the hard part. You know the pain is real, you know roughly where it lives, and somebody has written it down.

What they wrote down is SMB finance teams.

That phrase will now sit at the top of the document for six weeks while four people build against it, and every one of them will picture somebody slightly different. Nobody will notice, because a segment cannot contradict you.

The average user does not exist

The reason a segment is useless is arithmetic rather than philosophical. Attributes stack, and each one you add removes people.

Researchers tested this directly, generating ten thousand persona-like descriptions against six real survey datasets ranging from 268 to over ten thousand respondents. Their finding: once a description combined nine or more attributes, it matched nobody in five of the six datasets, including every consumer dataset. Their own conclusion is the one to keep: because descriptions with many attributes represent very few people, treat them accordingly.

SMB finance teams is already three attributes. By the time your document says finance leads at 20-to-200-person B2B companies who use Xero, close monthly, and have no dedicated ops function, you have written a description of nobody, in convincing detail.

The usual fix does not work either

The standard advice is to turn the segment into a persona. Give her a name, a photo, a job title, some goals and frustrations. I am not going to recommend that, because the evidence has never been there and it is worth knowing how thin it is.

The methodological objection has stood unanswered for twenty years: it is “difficult to determine how many, if any, users are represented by a persona”, and personas “cannot be adequately verified or falsified and therefore have no demonstrable validity.”

The practitioner evidence is no better. In the first study of experienced designers who had actually deployed personas in industrial software work, they “used personas almost exclusively for communication, but not for design”, and named four problems: personas were “abstract, impersonal, misleading and distracting.” The authors’ conclusion is blunt. “Personas cannot replace immersion in actual user data.”

And the strongest experimental result in favour of personas, when you go and read it, is a five-week pilot with nine student teams, scored by expert heuristic inspection because there was no time to build anything a user could try.

A fictional person cannot be wrong. That is exactly the problem.

The move

Pick one real person, by name, who you could message today, and build for them until they tell you otherwise.

The point is not empathy. Empathy is what the persona was for, and it is why the persona fails: an invented character produces a warm feeling and no new information.

The point is checkability. When you are three days in and unsure whether the bulk action should default to selected or unselected, you can send Priya a message and have an answer in ten minutes. There is nobody to message about SMB finance teams, so instead you will decide it yourself, and call that a product decision.

SEGMENT                    PERSONA                 A REAL PERSON

SMB finance teams          "Sarah, 34,             Priya Raghavan
                            Finance Manager"        Ops lead, Kelso Ltd
matches: unclear
answers: none              matches: unknown        matches: exactly one
                           answers: whatever        answers: within a day
                             you decide today       and often "no, actually"

                           cannot be wrong         disagreed with us twice
                                                     last week

  the test: when you are unsure on Thursday afternoon,
  which of these three can you ask?

The stake, in this era specifically

DORA’s research puts user-centric focus among the capabilities that decide whether AI adoption helps a team or hurts it, and their framing is the sharpest statement of this chapter’s argument that I have found anywhere:

“Without a user-centric compass, AI’s ability to accelerate code generation can simply propel a team faster in the wrong direction.”

They go further, and it is worth sitting with: adopting AI without a user-centric focus can actually harm team performance. Not fail to help. Harm.

When writing the code was the expensive part, aiming roughly and correcting later was affordable. Now that generating a plausible version of almost anything takes an afternoon, direction is most of what is left.

What it costs

One person is not your market, and you will over-fit to them. Priya has habits that are hers alone, and if you build only for her you will ship her spreadsheet. The correction is not to abstract back up into a segment. It is to get a second real person, then a third, and to notice which of Priya’s problems the other two also have.

She will be unavailable exactly when you need her, on holiday, in a close, or simply not replying. Have two.

And she can be wrong about her own work, which is a genuine limit and the subject of the next move. A named person gives you somebody to ask. It does not guarantee the answer.

Try this week

Open the document that describes who you are building for. Find the noun phrase where a person should be.

Then replace it with a name, a company, and a way to contact them. If you cannot fill in all three, you have found something more important than today’s ticket, which is that nobody on your team can currently check whether any of this is right.

Then do the smallest thing that proves the connection works. Send one message asking one question you were about to decide yourself:

Quick one, and no rush. When you do the Thursday update, do you usually start from the spreadsheet or from the system? I’m about to make an assumption and I’d rather ask.

If you get an answer, you have something your document did not have this morning. If you do not, you have learned that too, and it is better to learn it now than in week five.