Stop building for “the user”
How to use customer personas to build a better product
Your B2B SaaS onboarding is fine on paper. There's a welcome email, a setup checklist, a tooltip tour. Someone in a product meeting looked at the completion rate and called it good.
Six weeks later, the account is gone.
You go back through the record and piece together what happened. The champion who signed up was an ops manager. She connected the integration, created a workspace, hit the main dashboard and saw a screen full of metrics that meant nothing to her team yet. She shared the link with three colleagues. None of them logged in. She came back once more, looked at the same empty state, and stopped coming back.
Nobody cancelled. The account just went quiet.
Here is the thing: the ops manager was never your typical user. She was the buyer and the internal champion, but the people who needed to get daily value from the product were her team — and your onboarding never spoke to them at all. It assumed one kind of person moving through one kind of journey. There were at least three different people in that account, each with a different reason to use the product and a different threshold for deciding it was worth their time.
This is not a retention problem. It is a persona problem.
Not the fictional kind, with stock photos and personality trivia. The kind that forces you to be honest about who is actually inside your product, what they are each trying to do, and where your experience is silently failing them.
You probably know less about your users than you think
Most founders can describe their ideal customer in broad strokes. SaaS companies, fifty to two hundred employees, operations or growth teams, some version of the problem we solve.
That is a market segment. It is not a persona.
The difference matters because a segment tells you who might buy. A persona tells you who is actually inside the product on a Tuesday afternoon, what they are trying to get done, and what would make them close the tab or keep going.
In B2B SaaS, those are almost never the same person. The buyer who approved the purchase is not the admin who set everything up. The admin is not the end user who has to find value in the product every week to justify the seat. And none of them is the executive who will look at a utilization report three months from now and decide whether to renew.
Each of those people has a different definition of success. Each of them experiences different friction. Each of them can kill the account in a different way at a different time.
When teams collapse those roles into a single "user," product decisions start to get fuzzy. Onboarding tries to speak to everyone at once and resonates with no one. The dashboard gets built for power users while the casual users who make up eighty percent of seats feel lost. The messaging talks about features the champion cares about while the daily users are still trying to figure out the basics.
The fix is not more research. It is sharper thinking about who, specifically, you are designing for at each moment in the journey.
Build around the job, not the profile
The most common failure in persona work is that teams describe the person but skip the motion.
They write down the role, the company size, the seniority level. What they leave out is what that person is actually trying to accomplish right now — and what it would feel like to make real progress toward it.
Clayton Christensen had a useful way of putting this: people don't buy a quarter-inch drill because they want a drill. They want a quarter-inch hole. The drill is just the current best option for getting there. When you build around the tool instead of the job, you end up optimizing for things nobody actually hired you to provide.
The same failure plays out in persona work constantly. A persona that says your user "values efficiency" and "prefers collaborative tools" tells you almost nothing useful. It cannot help you decide what to build, what to simplify, or where the product is breaking down.
What you actually need to know is what that person is trying to move toward, and what would have to happen for them to feel like the product helped them get there.
For a first-time ops admin onboarding a team into a new SaaS tool, that might mean: getting the core integration connected before she has to demo anything internally, so she doesn't show up to a meeting with an empty product. For an end user joining the same tool three days later, it might mean: finding something relevant to their work in under five minutes, without having to ask anyone for help. Those are concrete. You can design around them.
A useful format for writing this down is the job story: "When [situation], I want to [motivation], so I can [outcome]." It forces specificity in a way that role descriptions don't. "When my manager asks me for the weekly pipeline summary, I want to pull it in two clicks, so I can send it before the standup." That is a job. "Values efficiency" is decoration.
What a useful persona actually contains
Most persona templates ask for too much of the wrong things and not enough of the right ones.
Here is what I would put in a persona card for product work. The image below shows what this looks like in practice for a B2B SaaS ops admin — the kind of person who sets up the account but often isn't the one getting daily value from it.
The fields that drive real decisions are: the role and its function (not the job title, which varies too much), the context they arrive in (evaluating, inheriting, under time pressure), the job they are trying to do, their definition of success, their buying influence, the anxieties that make them hesitate, and the specific moments in the product where they tend to stall.
That last one — evidence of getting stuck — is the most important field and the one teams fill in least honestly. It should not say "finds setup complex." It should say: "Four of the last six ops admins we spoke to stopped at the integration step and did not return for at least three days. Two of them sent a support ticket. One churned." That is a field that can change what you build. The vague version cannot.
How to build one that is not fiction
The danger with persona exercises is that they drift toward plausible-sounding invention. Teams fill in attributes because empty boxes feel uncomfortable. Soon they have a detailed character that nobody has actually met, and a long list of traits that no product decision depends on.
The deeper problem is not that this can be inaccurate. It is that it trains the team to treat customer understanding as a design exercise rather than an operating discipline.
Start with interviews, not templates. Talk to five or six people in the specific role you are trying to understand. Ask about something concrete and recent: "Walk me through the last time you had to [relevant job]. What were you trying to do? What got in the way?" You are listening for three things: the actual job, the anxiety that slowed them down, and the specific moment things broke.
Then pressure-test that synthesis against your support tickets and churn notes. Interview data is richer. Support data is truer at scale. If you are hearing a pattern in interviews but it barely shows up in tickets, it might be real for a vocal minority. If it shows up in both, you have something to act on.
Write the persona with evidence attached. Not "anxious about getting team buy-in," but: "Five out of seven admins we interviewed said they waited until they had something concrete to show before inviting their team. Here is what one of them said verbatim." The evidence is what keeps the persona honest over time. Without it, the artifact slowly gets rewritten toward whatever the team already believed.
Keep the format simple enough to edit. A shared doc beats a polished PDF. A PDF from four months ago is an archive. A shared doc is a working hypothesis.
One persona is almost never enough
In B2B SaaS, the account you are trying to retain usually contains at least three distinct experiences happening in parallel — and they do not always reinforce each other.
The admin who set up the account needs the product to feel worth the effort of the configuration she just did. The end user who joined two days later needs to find something relevant to their actual work quickly, or they will treat the tool as optional. The buyer who signed the contract needs visible evidence that the team is getting value before the renewal conversation comes up.
Each of those people can decide the product is not working for them. Each of them does it at a different moment, for a different reason, and their signal often does not show up clearly in aggregate metrics until the account is already at risk.
The practical test: take your last five churned accounts and try to identify which role went quiet first. In most cases it was not the admin, and it was not the buyer. It was the end users who quietly stopped logging in during week two, months before anyone noticed the account was at risk.
That is the role most B2B SaaS products underinvest in designing for, because the admin is more visible at setup and the buyer is more visible at renewal. The end user, the person who has to find personal value in the product repeatedly, often gets the least intentional design attention.
Personas only work attached to a journey
A persona by itself can still stay abstract.
The real jump happens when you connect it to the customer journey — the sequence of moments a user moves through from signed up to this is now part of how we work. The journey tells you where the experience unfolds. The persona tells you who is inside that moment and what it means from their side.
This combination breaks apart problems that look unified from the outside.
"Activation is weak" sounds like one issue until you separate the roles. The admin is overwhelmed by setup and delays inviting the team. The end user arrives before the product is ready and sees nothing relevant. The buyer is watching for proof of adoption that no one has designed a moment to create. Those are not one problem, and a single onboarding fix will not solve all three.
A concrete exercise: take your two or three core personas and map them across your key journey steps. For each combination, ask two questions — what does success feel like for this person at this moment, and what tends to go wrong? You do not need elaborate tooling for this. A shared document with two columns per persona is enough to make the gaps visible.
What you will usually find is that most of the ambiguity in your product discussions is concentrated in a few specific cells: the admin at setup, the end user in the first session, the buyer at the thirty-day mark with nothing to point to. Once you can see it that way, the decisions become much less abstract.
The test that separates useful personas from decorative ones
One question works well here: can anyone on the team point to a specific product decision that changed because the persona existed?
Onboarding was split into two paths instead of one because the admin journey and the end user journey have almost nothing in common for the first week. A feature was deprioritized because it solved a problem for the buyer but added friction for the end users whose adoption the buyer was trying to prove. The empty state was redesigned because it was showing global metrics that meant nothing to someone who had just joined a workspace with no history yet.
If none of that is happening, the personas are probably sitting nearby the product work without actually shaping it.
Personas should make the product more specific. When they do not, they are usually just slides.
Keep them editable, not ceremonial
I dislike personas that feel official.
Someone ends up owning them. A workshop gets scheduled. A polished deck gets produced. The artifact becomes too formal to challenge casually, which is almost the opposite of what a growing product team needs.
Personas should be editable by reality. Support should be able to surface a friction pattern for a specific role and have it land somewhere. Sales should be able to flag when a buyer segment is being misunderstood. A founder should be able to notice when the team is overfitting to a vocal user and quietly drifting from the actual target.
A hypothesis you keep updating is more useful than a portrait you keep framing.
My bias: three sharp personas the team genuinely uses beat ten elaborate ones nobody can remember. The goal is compression — taking real customer complexity and making it simple enough to guide decisions without flattening away what actually matters.
When that works, personas stop being a workshop artifact. They become the shared vocabulary that makes product conversations more honest about who, specifically, is being served by a decision and who is not.
That is already worth the work.
All of the things I described above — building personas around real jobs and anxieties, keeping them connected to journey steps, grounding them in evidence rather than guesswork, and using them to drive specific decisions — that is exactly what Custory is built for. If you want a structured place to actually do this work rather than just think about it, give it a try.
Filip Šanda
Co-founder & CEO