Most teams should document and maintain three to five customer personas. That range has less to do with how many distinct customer types exist in your market than with how many a working team can keep accurate.
The question is rarely how many personas to create from scratch. It is whether the set already in front of you is the right size. Someone joins a CX team and finds eleven personas built by an agency three years ago, or inherits two that each cover four recognizably different people. The count arrived rather than got decided.
The research behind creating user personas tells you what distinctions exist in your market. It does not tell you how many you can afford to carry. That second decision is the one this comes down to.
How many personas you find and how many you can keep
Recommendations in circulation range from a single persona to well over a hundred. The spread has a cause: two different questions are getting answered as if they were one. How many meaningfully different customer types exist in your market is a research finding. How many personas you document and keep current is an operating decision.
The research finding can be large and still be right. Segmentation work on a mid-market software product or a regional bank routinely surfaces nine or fourteen behavioral clusters, none of them invented. The operating decision is bounded by something else: what you can refresh, the number of genuinely different responses your organization can make, and the number of artifacts your team can keep true. A distinction you cannot serve differently is real, and still not worth a persona.
Segments and personas part company here. A segment divides a population for analysis and can be as granular as your data allows, because a filter costs nothing to hold. A persona is a point of view you design and decide from, and every one has a running cost.
Each of those published ranges answers a different one of the two questions, which is what makes them look incompatible.
The usable answer: the number of personas you need is the number of distinct customer viewpoints your team can keep accurate and act on differently.
The act-differently test
A candidate persona qualifies for its own entry when the difference it represents would change something you are able to act on. That is a higher bar than being different, and it is deliberately about your capability rather than the customer's uniqueness, because a distinction nobody can serve differently produces a document instead of a decision.
- Would it change the journey you map?Different steps, not different feelings
- Would it change what you build, write, or offer?A real artifact, made differently
- Would it change the priority order?A different ranked list of pain points
- Is there someone who would act on the difference?A named owner and a named audience
A candidate needs a yes to at least one of them.
Would it change the journey you map?
If both candidates move through the same steps, in the same order, hitting friction in the same places, the journey does not need two points of view laid over it. Sentiment can differ by ten points at the same step and still belong to one persona.
A split is warranted when the same goal is reached by a genuinely different path. A patient referred by their GP and a patient who self-refers are not one journey with two moods: one of them has an entire stage the other skips.
Would it change what you build, write, or offer?
The test is whether a real artifact would come out different: a different onboarding sequence, a different pricing page, a different implementation plan. Something a team would build twice. If only the wording changes, that is a content variant, and copy variants do not need a maintained research artifact behind each one.
Would it change the priority order?
Personas exist partly to settle arguments about what to fix first. Two candidates who would produce the same ranked list of pain points will never be used to resolve anything, whichever one you open. Split them when they would rank the same list differently, and certainly when one has a pain point the other does not have at all.
Is there someone who would act on the difference?
Name the team or role that would use this entry and do something differently because of it. A persona with no owner and no audience is a research summary with a face on it. If nobody can currently serve this group differently, note that it exists and revisit when someone can act.
A candidate that fails all four is better recorded as an attribute of a persona you already have: a behavior or context field on the entry that absorbs it, or a tag you can filter by later. The observation survives without a maintained entry of its own. The common version of this is two candidates whose demographics differ and whose behavior does not, which is one persona with a demographic range recorded on it.
The inverse deserves as much attention and gets far less. Sometimes one persona's behavior splits cleanly along a condition: first purchase versus renewal, self-serve versus procurement-led. The tell is a review where every claim about the persona needs an exception attached. That is a case for adding rather than merging.
What each additional persona costs to keep
Advice to consider your resources is unusable until somebody counts what a persona consumes. Four things recur, and each recurs per persona rather than once for the set:
- Research refresh. Revisiting the evidence behind the entry and updating it where reality moved. This is the part of keeping personas up to date that never appears on a project plan.
- Journey artifacts. Every journey scoped to this persona has to still describe it accurately, which means rereading them with that persona in mind.
- Review cycle. A named person confirming the entry is current, at whatever cadence you committed to.
- Onboarding. Every new colleague learns the whole set before using any of it.
The multiplier nobody counts
Personas multiply what sits downstream of them. Four personas across three maintained journeys is twelve views to keep accurate rather than four, which is why persona count feels cheap at creation and expensive eighteen months later.
The way out is not fewer journeys. It is maintaining each journey once and treating the persona as a lens rather than a reason to copy it. In Smaply, persona-based journey views work this way: the steps and evidence live in one map, and switching persona changes what you see rather than which document you opened. That is what makes a set of six survivable where six parallel maps would not be.
Run the arithmetic on your own set
Take a CX team of three, six personas, three maintained journeys, and a commitment to refresh twice a year. Call it one day per persona per cycle to revisit the evidence and update the entry, plus half a day to walk the journeys it is scoped to.
| Personas maintained | Days per refresh cycle | Days per year (two cycles) |
|---|---|---|
| 3 | 4.5 | 9 |
| 6 | 9 | 18 |
| 9 | 13.5 | 27 |
Eighteen days is most of a working month, taken out of a team of three who also run research and facilitate workshops. Nine is a fortnight and survives a bad quarter. Twenty-seven does not survive anything.
Your own figures will differ, and the slope matters more than the absolute numbers. Refresh capacity sets the ceiling, and a set above it becomes a set of documents about who your customers used to be.
Smaply keeps personas in one shared home, linked to the journeys and research that prove they are still true.
Cutting an inherited set down
Most people asking this question are not choosing a number, they are cutting one. The usual arrival state is a set nobody in the room can name from memory, which says more than any count: it stopped being used some time ago and nobody noticed.
Sets fail in both directions, and the remedy for one makes the other worse, so check which problem you have before cutting anything.
- Nobody can name the set from memory
- Entries with no named owner
- Entries not opened since the workshop that produced them
- Two entries always updated in the same sitting
- Refresh cycles slipping past their cadence
- One persona that is visibly three different people
- Every claim in review needs an "except for" clause
- Attributes described in ranges too wide to carry information
- Teams informally designing for a sub-group the entry does not name
In mid-market and enterprise organizations the count is rarely high because one team chose badly. It is high because marketing, product, support, and the CX function each built their own set, so the company holds fourteen personas and three incompatible definitions of the same customer. Building a fifth set to reconcile the other four is the standard mistake. One owned set with named contributors from each of those teams is slower to agree and the only version that lasts.
When you do merge, the mechanics matter more than the decision. The research behind a retired entry should attach to the persona that absorbs it, so the survivor ends up with more evidence rather than a thinner justification. Anything pointing at the retired entry needs somewhere to go first: tags, journey cards, portfolio items. The surviving entry's behavior fields also have to absorb the range the merge widened, or you lose the distinction without recording that you lost it.
The political move is to demote rather than delete. An entry a director sponsored can move to a secondary or held tier: recorded, visible, not maintained, not part of the set the team designs against. That removes the running cost without asking anyone to concede the group does not matter. The concession is usually the real obstacle, not the arithmetic.
When the right answer is more than five
Three situations make a larger set correct rather than indulgent. In each one the extra entries represent different people on different paths, not finer slices of the same person.
B2B buying committees.
Five roles at one account is a genuine case for five role-based personas, because the procurement lead, the daily user, and the executive sponsor want different things and are served by different material. The account itself is a segment. This is where the buyer and user distinction stops being academic: the person who signs the contract and the person who logs in every morning rarely rank the same problems.
Separate products or markets.
Separate product lines with separate audiences are separate sets, each sized on its own terms. One combined set of eleven called the company's personas leaves every entry slightly wrong for whoever picks it up.
A library you filter rather than a set you memorize.
There is a serious argument that the conventional ceiling of ten is an artifact of how personas used to be produced and read, when the whole set had to fit in the heads of the people in the room. The seven-plus-or-minus-two memory heuristic gets cited in support of small sets, and it does constrain how many viewpoints one person can juggle in a workshop. It says nothing about how many can sit in a maintained, filterable library.
A larger library holds up on two conditions: no single decision uses all of it, and every entry is still genuinely refreshed. The second is the one that fails. A bigger set is a capacity claim, true only as long as the refresh commitment is.
The teams that have this under control can usually name the persona they retired most recently. It was a small-business variant that failed all four questions and got folded into the persona beside it, and its six interview transcripts are still attached to the survivor, where anyone who thinks the merge was wrong can read them.
Link personas to journeys, research, and the decisions they shape, so the set stays worth the upkeep.
Frequently asked questions
How many personas is too many?
Too many is more than your team can refresh on the cadence it committed to, which for most teams lands between five and seven. The symptom shows up before the count does: people start asking which persona a piece of work is for and nobody answers.
Do two personas need different demographics?
No. Behavior, goals, and constraints separate personas, and demographics only describe them. Two entries differing on age, location, or job title are one persona with a range recorded on it.
Should every persona get its own journey map?
No. Maintain the journey once and use persona-scoped views on it, unless a persona moves through genuinely different steps rather than the same steps differently. Parallel maps per persona end up disagreeing with each other.
Is each role in a B2B buying committee a separate persona?
Usually yes, for the roles you design, sell, or support differently, which is three to five in most enterprise deals. The account is a segment, not an entry of its own.
How many personas should you start with?
One, built on real research, beats four sketched from assumption. Add the second when a decision comes up that the first cannot answer.
Do personas and segments need to match one to one?
No, and expecting them to is a common source of persona bloat. Segments cost nothing to hold and can be far more granular. Personas cost something every quarter, so the set is a chosen subset.
