- A category is not an answer to who this is for. It is the absence of one. It cannot rule anything out, which means nothing in your product can be argued down.
- Nobody chooses the average user. It wins by default, because it is the only answer in the room that no one can object to.
- Your build partner cannot answer this and should not try. On your side, usually nobody has the job either. So it goes unanswered.
- The fix is a persona model built from how the product is already being used. Its value is not empathy. It is that somebody can finally say no.
Say it out loud. Who is your product for?
Whatever came out, it almost certainly had a shape. A sector, a size, a role, a stage. Operations managers at mid-market logistics firms. Finance teams at Series A startups. Independent landlords. It sounded like an answer because it is the answer you give investors, and it is the answer on your home page, and nobody in three years has asked you to improve on it.
Now name three of them.
Not three companies. Three people. First name, last name, and what each of them was doing in your product last Tuesday.
Most founders eighteen months into a live build cannot do this. The ones who can will usually name three people they sold to rather than three people who use it, which is a different list. The gap between those two answers is not a gap in your research budget. It is a gap in your product’s definition of itself.
A category cannot be wrong.
The problem with “operations managers at mid-market logistics firms” is not that it is vague. Vague would be survivable. The problem is that it is unfalsifiable.
Take any feature you like to that definition and ask whether it belongs. Bulk export. A permissions matrix. A mobile view. A dashboard nobody requested. The answer is yes every time, because somewhere inside a group that broad there is an operations manager at a mid-market logistics firm who would want it. You cannot prove there is not. Neither can anybody else.
A definition that nothing can fail is not a definition. And a plan that rules nothing out is not a plan, it is an inventory.
Nobody in the room is supposed to know.
I built and exited an agency, so let me put this where it belongs rather than somewhere convenient.
Your build partner cannot answer this question. They have not met your users. Meeting them was not in the scope, was not in the estimate, and would not have been paid for if it had been. The good ones know this about themselves. Ask a serious firm which of your users matters most and you will get a careful non-answer, and that is the right response. A firm that guessed would be doing something considerably worse than staying quiet. It would be inventing the single input every downstream decision rests on, and then building on it for a year.
So they stay quiet, correctly, and the question sits there. On your side of the table there is usually nobody whose job it is either. Not because you do not care about it. Because on a founder led build the roles that exist are the ones somebody is paying for, and “find out who this is actually for” has never appeared on an invoice.
An unanswered question does not stay empty. It gets filled by whatever is nearest to hand.
The answer nobody can object to.
This is the part worth slowing down for, because it is not a failure of anybody’s judgement. It is arithmetic.
Put a feature on the table in a room where the user is a category. Somebody proposes it. Now watch what has to happen for it not to get built. Somebody has to say no, and to say no they have to say on whose behalf they are saying it.
They cannot. There is nobody specific to speak for. The most anyone can offer is that they personally are not sure, which in a room of people who are also not sure loses to the person who is enthusiastic.
So every feature has a defender and no feature has a challenger. Not most features. Every one.
Run that for eighteen months and the product converges on the widest possible reading of the category: the union of everything anybody inside it might want, smoothed until nothing in it is sharp enough to be wrong for anyone. That is what the average user is. Not a demographic. The residue left behind when nothing can be excluded.
Nobody chose it. No meeting decided it. It won by default, which is how the answer nobody can object to always wins.
There is a second empty chair beside this one, and it is worth a sentence rather than a section. The same plan that has no page describing the person the product is being built for has no page describing the person paying for it either. One absence, viewed from the two ends.
What it looked like at Visual Sectors.
Visual Sectors had a live product and it was working. That is the first thing to say, because this is not a story about a failure. It supported several different kinds of user, doing real jobs, and there was nothing obviously broken to point at.
What there was not was a shared, evidenced picture of who those users actually were or what each of them needed. Different users had different jobs to be done. Nobody had got that wrong. Nobody had written it down.
The effect was the one above, and it showed up in the shape of the roadmap rather than in any single decision. Features added for one group. Friction left in place for another. No obvious way to decide whose needs came first, because deciding that requires a basis for preferring one user to another and there was not one. The roadmap drifted, in the precise sense that it kept moving and nobody could say it had gone the wrong way.
What followed was not a workshop. We defined the distinct personas the product was already supporting, grounded in how it was actually being used rather than in who the team imagined was using it. Then we mapped each persona’s needs and jobs against the product as it stood: where it served them well, where it fell short, where the experience needed tailoring, and how to prioritise that work around the personas that mattered most.
The output was a persona model and a roadmap anchored to real users instead of a generic average. The thing that actually changed was smaller than either and more useful than both. Product decisions got a frame: which persona, which need, which trade-off. A one size fits all product became one deliberately shaped around the people it serves, and that only became possible once there was somebody specific to shape it around.
Built from what your product already knows.
The instinct here is to book a workshop, and the instinct is wrong. A room full of your own team imagining your users will produce a document that is internally consistent, nicely designed, and made of exactly the assumptions you walked in with. You will have written the average down rather than replaced it.
The material is already in the product, and three questions get at it. All three have evidence behind them.
Who is actually in it. Not who signed up. Who comes back. Not accounts, people.
What each of them actually does once they are in. Not the journey you designed. The one they take.
Which of them pays, and which is merely present. These are frequently not the same people, and a product that has never separated them is usually shaped around whichever group is louder.
Turning that into a persona somebody can use is a craft with its own literature, and our version of it is N°11. This issue is not that. This is the argument for why it is your job rather than a designer’s: a persona model is not a design artefact, it is the document that grants somebody the authority to refuse. Design can execute it. Only you can authorise it.
Decide who it is worst for.
Here is the version of this you can do before the end of the week, and it is a decision rather than a discovery.
Work out which of your users your product is worst for. Then decide, out loud and in front of somebody else, whether you mind.
Deciding that you do not mind is a strategy. It means that group is not yours, that the friction they meet is a boundary rather than a defect, and that nothing in the next two quarters goes on smoothing it. That is a real position, and good companies hold it deliberately.
Not knowing is not a position. It is the average user again in a different hat, and it will keep winning every argument it is in.
The same trap sits under advice, which is a thing I have written about elsewhere and will not relitigate here: the general answer is the one nobody can object to, and only the specific one can be wrong. But the decision in front of you is a product decision, and it comes down to a single line.
You cannot say no on behalf of a category. Nobody can. And until somebody in your company can say no on behalf of a person with a name, the list of things to build only ever grows.
So start there, today, on paper. Write the three names down. If you cannot, you have just found the most valuable thing you will do this quarter.
N°66 finds the same question already answered in public. Your pricing page named two or three of these people the afternoon it went up, and the line between two tiers is that choice made where every customer can read it.