{"id":14270,"date":"2026-08-15T13:41:10","date_gmt":"2026-08-15T08:11:10","guid":{"rendered":"https:\/\/www.scaler.com\/blog\/?p=14270"},"modified":"2026-08-15T13:41:30","modified_gmt":"2026-08-15T08:11:30","slug":"how-deep-user-personas-actually-change-what-you-build","status":"publish","type":"post","link":"https:\/\/www.scaler.com\/blog\/how-deep-user-personas-actually-change-what-you-build\/","title":{"rendered":"How Deep User Personas Actually Change What You Build"},"content":{"rendered":"\n

Two teams ship the exact same feature. One gets adopted within a week. The other quietly dies in a changelog nobody reads. Usually the difference isn’t the code, it’s that one team could answer \u201cwho is this for, and what are they actually trying to do\u201d with something better than a job title and an age bracket. That’s the entire pitch behind a user persona. It’s also exactly where most personas go wrong.<\/p>\n\n\n\n

Most personas are decoration. A laminated card, a stock photo, a made-up age, a city, three bullet points that could describe forty million people equally well. A persona built from real research is a different animal. It can settle an argument in a prioritisation meeting that would otherwise drag on for another two sprints.<\/p>\n\n\n\n

This covers what a user persona actually is, what earns a spot on the template, how to build one from research instead of guesswork, a worked example from an Indian lending app, a quick self-audit checklist, and, because nobody else on page one of Google seems willing to say it, when personas quietly mislead you.<\/p>\n\n\n\n

<\/span>What Is a User Persona, Actually<\/strong><\/span><\/h2>\n\n\n\n

A user persona is a research-based, fictional profile representing a real behavioural pattern among your users: their goals, context, constraints, and the outcome they’re trying to reach. It exists so product decisions get concrete instead of hypothetical. Instead of designing for \u201cthe user\u201d (a phrase that stretches to fit whatever you already wanted to build, conveniently), you design for someone specific.<\/p>\n\n\n\n

Two words in that definition are doing all the work: research-based and behavioural pattern.<\/p>\n\n\n\n

Research-based means it’s a synthesis of evidence, not a guess dressed up in a nice font. Behavioural pattern means it represents a way of behaving, not a demographic bucket. Age, income and city tell you almost nothing about how someone actually uses a product. Behaviour tells you everything.<\/p>\n\n\n\n

Nielsen Norman Group<\/a> put it well: every piece of information on a persona should have a purpose. If a field wouldn’t change a decision, it shouldn’t be on the page. That single line is basically the backbone of this whole article, so keep it in your back pocket.<\/p>\n\n\n\n

\n \n \"Scaler\n <\/a>\n<\/div>\n\n\n\n

What a User Persona Is Not<\/strong><\/h3>\n\n\n\n

Four quick distinctions, since your manager will use these words interchangeably and it’ll bite you later:<\/p>\n\n\n\n

\u25cf        Not a market segment. A segment is a countable group (\u201cwomen, 25\u201334, metro\u201d). A persona is one characterised person representing a behaviour.<\/p>\n\n\n\n

\u25cf        Not an ideal customer profile. An ICP is about the account worth selling to, company size, budget, industry. A persona is about a human using the thing.<\/p>\n\n\n\n

\u25cf        Not a target audience. Audience is a reach concept, useful for media buying. A persona is a design and prioritisation concept.<\/p>\n\n\n\n

\u25cf        Not an avatar with a stock photo. A face, an age and a city is a costume. It is not research.<\/p>\n\n\n\n

Where This Whole Idea Came From<\/strong><\/h3>\n\n\n\n

Software designer Alan Cooper started this in the early 1980s by role-playing a specific imagined user while designing a project management tool, and later formalised it in his book The Inmates Are Running the Asylum. His argument, still true today: designing for one specific, named person beats designing for a flexible abstraction that bends to fit whatever the team already wanted. You can read Cooper’s own account of the method<\/a> at a Stanford HCI seminar, straight from the source.<\/p>\n\n\n\n

Worth knowing: this was invented to fix an engineering problem, teams unconsciously building for themselves, not a marketing one. That’s why the fields that actually matter on a persona are behavioural. The demographic stuff crept in later, mostly from marketing decks.<\/p>\n\n\n\n

<\/span>Why Shallow Personas Fail (and Deep Ones Actually Change Something)<\/strong><\/span><\/h2>\n\n\n\n

Here’s the test the rest of this article keeps coming back to: a persona is only worth building if you can name a decision it would change. If it wouldn’t move a single prioritisation call, congratulations, you’ve made a poster.<\/p>\n\n\n\n

The Demographic Trap<\/strong><\/h3>\n\n\n\n

Teams collect the attributes that are easy to collect: age, city, income band, job title. Survey tools hand these back automatically. Then, somewhere around the second sprint planning meeting, someone realises none of it predicts behaviour.<\/p>\n\n\n\n

\u201cRohan, 26, Bengaluru, \u20b912 LPA, likes cricket and OTT\u201d describes several million people who all behave completely differently inside your app. Compare that to: \u201cchecks the app only on the 1st and the 25th, because that’s when salary lands and rent is due.\u201d One sentence, and it already tells you something about notification timing, billing cycles, and support ticket spikes.<\/p>\n\n\n\n

The rule: keep an attribute only if changing its value would change what you build. Age matters for a health app. It’s dead weight on a B2B analytics dashboard.<\/p>\n\n\n\n

From \u201cWho They Are\u201d to \u201cWhat They’re Trying to Get Done\u201d<\/strong><\/h3>\n\n\n\n

The upgrade path looks like this: demographics, then behaviours, then goals, then the actual job the user is hiring your product to do (yes, that’s jobs-to-be-done sneaking in early, more on that later).<\/p>\n\n\n\n

A good persona is falsifiable. Research can prove it wrong. A demographic card can never be wrong, which is exactly why it’s useless, it can’t lose an argument because it never made a real claim.<\/p>\n\n\n\n

For Indian products specifically, context and constraint deserve a permanent seat at the table: device tier, network quality, data cost sensitivity, shared-device usage, language, who else can see the screen. A template written in California has no field for \u201cshared family phone,\u201d and that routinely decides whether your product actually works here.<\/p>\n\n\n\n

The Three Decisions a Deep Persona Actually Changes<\/strong><\/h3>\n\n\n\n

\u25cf        Prioritisation. When two features look equally valuable on paper, the persona’s constraint breaks the tie. Core user on a low-RAM phone with patchy 4G? Offline resilience beats a fancier animation, and now you can defend that call with evidence instead of taste.<\/p>\n\n\n\n

\u25cf        Positioning and messaging. The persona’s own words become your product’s words. If people describe the problem as \u201cI don’t know where my money goes,\u201d don’t sell them \u201cunified financial analytics.\u201d Nobody talks like that.<\/p>\n\n\n\n

\u25cf        Roadmap sequencing. Personas reveal which segment is a bridge to the next one, and which is a dead end. Serving the segment that brings its own network compounds. Serving a high-revenue but isolated segment usually doesn’t.<\/p>\n\n\n\n

There’s also a persona nobody talks about enough: the anti-persona. It tells you who you’re deliberately not building for, arguably more useful than knowing who you are. Deciding what to skip is half the job, and honestly the harder half. If you’re figuring out what that job even covers, Scaler’s PM roadmap<\/a> is a decent map of the terrain.<\/p>\n\n\n\n

\n \n \"Scaler\n <\/a>\n<\/div>\n\n\n\n

<\/span>Types of User Personas (Pick the One You Actually Need)<\/strong><\/span><\/h2>\n\n\n\n

\u201cTypes of personas\u201d gets used to mean two different things: the academic research perspectives, and the business function the persona serves. Most teams only need to know which one they’re being asked for.<\/p>\n\n\n\n

The Four Persona Perspectives<\/strong><\/h3>\n\n\n\n
Type<\/strong><\/td>Built from<\/strong><\/td>Best used when<\/strong><\/td>Main risk<\/strong><\/td><\/tr>
Goal-directed (Cooper)<\/td>Interviews on what the user wants to accomplish<\/td>Designing workflows, deciding scope<\/td>Can under-weight emotion and context<\/td><\/tr>
Role-based (Grudin, Pruitt & Adlin)<\/td>Data about the user’s organisational role<\/td>B2B products where the role defines the workflow<\/td>Ignores variation within the same job title<\/td><\/tr>
Engaging (Nielsen)<\/td>Narrative built on research data<\/td>Team keeps ignoring dry research decks<\/td>Story can outrun the evidence if nobody’s watching<\/td><\/tr>
Fictional \/ proto<\/td>Internal knowledge, no fresh research<\/td>Day one, as a hypothesis to test<\/td>Teams forget it was a guess and ship from it anyway<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n

Named attribution matters here. The four-perspective framework comes from Lene Nielsen’s work via the Interaction Design Foundation<\/a>, and the goal-directed approach traces back to Cooper.<\/p>\n\n\n\n

Quick word on that last row: a proto-persona is fine as a hypothesis. It becomes dangerous the moment the team forgets it was never validated. Give it an expiry date, if it’s still sitting there unvalidated after one research cycle, delete it.<\/p>\n\n\n\n

User Persona vs Buyer Persona vs Customer Persona<\/strong><\/h3>\n\n\n\n
Term<\/strong><\/td>Who it describes<\/strong><\/td>Owned by<\/strong><\/td>Question it answers<\/strong><\/td><\/tr>
User persona<\/td>The person who uses the product<\/td>Product \/ design<\/td>What are they trying to get done, and what’s stopping them?<\/td><\/tr>
Buyer persona<\/td>The person who decides and pays<\/td>Marketing \/ sales<\/td>What triggers a purchase, what blocks it?<\/td><\/tr>
Customer \/ consumer persona<\/td>Usually a loose synonym for buyer persona<\/td>Marketing<\/td>Who do we target, and with what message?<\/td><\/tr>
Audience \/ marketing persona<\/td>The content-consumption view of the same person<\/td>Content \/ brand<\/td>What do they read, watch, trust?<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n

In B2C, these often collapse into the same person. In B2B they almost never do, and mixing them up is a rookie mistake. Take a school-management SaaS: the user is the class teacher marking attendance every morning, the buyer is the administrator worrying about compliance reports and pricing. A feature that delights the teacher might not close the deal at all. Quick sniff test: if you can’t tell within ten seconds whether a persona describes a user or a buyer, it isn’t finished.<\/p>\n\n\n\n

<\/span>What Actually Belongs on a User Persona Template<\/strong><\/span><\/h2>\n\n\n\n

Everyone lists fields. Almost nobody audits them. Here’s the only test that matters: would changing this value change a product decision? If not, cut it, no matter how nice it looks on the slide.<\/p>\n\n\n\n

Field<\/strong><\/td>Weak version<\/strong><\/td>Strong version<\/strong><\/td><\/tr>
Name + descriptor<\/td>\u201cRohan, 26\u201d<\/td>\u201cSunita, first-time investor who checks returns weekly\u201d<\/td><\/tr>
Context of use<\/td>\u201cUses mobile\u201d<\/td>\u201cAndroid, 3GB RAM, drops signal on the commute, shared family phone\u201d<\/td><\/tr>
Goal \/ job to be done<\/td>\u201cWants to save money\u201d<\/td>\u201cNeeds to know, before the 5th, if she can afford this month’s SIP\u201d<\/td><\/tr>
Current workaround<\/td>\u201cUses competitor apps\u201d<\/td>\u201cTracks expenses in a WhatsApp message to herself\u201d<\/td><\/tr>
Pain points<\/td>\u201cFinds it confusing\u201d<\/td>\u201cAbandons KYC because the PAN photo fails three times in bad light\u201d<\/td><\/tr>
Motivations \/ triggers<\/td>\u201cWants growth\u201d<\/td>\u201cOpens the app the day salary lands, ignores it otherwise\u201d<\/td><\/tr>
Constraints<\/td>\u201cPrice sensitive\u201d<\/td>\u201cWon’t link a bank account without a visible RBI-regulated badge\u201d<\/td><\/tr>
Verbatim quote<\/td>Invented line<\/td>A real sentence from an interview, cited<\/td><\/tr>
Evidence base + date<\/td>Missing<\/td>\u201cn=14 interviews plus 3 months of event data, March 2026\u201d<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n

That last row is the one nobody includes, and it’s the one that actually makes a persona trustworthy. Without a dateline and an evidence base, you can’t audit it, and you definitely can’t retire it when it goes stale.<\/p>\n\n\n\n

What Gets Cut<\/strong><\/h3>\n\n\n\n

Stock photo, favourite brands, hobbies, a personality slider chart, an MBTI label (please, no), a \u201ctech savviness: 4\/5\u201d bar, and a precise salary figure nothing downstream uses. If your persona has a Myers-Briggs type but no evidence base, you’ve built a horoscope with a UI mockup.<\/p>\n\n\n\n

To be fair to the photo defenders, some teams say it aids recall. Fine, keep one if it doesn’t smuggle in unexamined assumptions about class, caste, gender or age, but it’s decoration at best, never a substitute for the fields above it.<\/p>\n\n\n\n

One practical note: where the persona lives matters more than how it’s designed. A gorgeous persona sitting in a Figma file nobody opens is, functionally, a deleted persona.<\/p>\n\n\n\n

<\/span>How to Build a User Persona From Real Research<\/strong><\/span><\/h2>\n\n\n\n

Research scope is set by the decision you need to make, not by curiosity. Here’s the six-step version that skips nothing important.<\/p>\n\n\n\n

Step 1. Name the Decision First<\/strong><\/h3>\n\n\n\n

Write one sentence before you talk to anyone: \u201cWe are building this persona to decide ______.\u201d Onboarding redesign, pricing tier, which segment to serve first, whatever it is. This sentence decides who you recruit and what you ask. \u201cWe’re doing personas because the process says so\u201d produces exactly the laminated card you’re trying to avoid. This is also, frankly, the exact reasoning skill interviewers probe for, the kind of thing a business analyst’s toolkit<\/a> leans on constantly.<\/p>\n\n\n\n

Step 2. Run 8 to 15 Interviews<\/strong><\/h3>\n\n\n\n

Recruit for behaviour, not demographics. Recent purchasers, churned users, people using a workaround, non-users who have the exact problem. Ask about the last specific time something happened, never what they’d hypothetically do with a feature. Then, genuinely, shut up and count to five after you ask a question. Uncomfortable, but it works.<\/p>\n\n\n\n

Stop when two consecutive interviews stop surfacing anything new. Usually somewhere around 8 to 15 people for a single segment, not a hard law, just a heuristic that tends to hold up.<\/p>\n\n\n\n

Step 3. Add Surveys, Sampled Properly<\/strong><\/h3>\n\n\n\n

Surveys size the patterns interviews already found. They don’t discover new ones. Write the survey after the interviews, not before. Keep it under five minutes, avoid leading or double-barrelled questions, and don’t accidentally survey only your most engaged users, the single most common self-inflicted bias in product research.<\/p>\n\n\n\n

Step 4. Ground It in Actual Behavioural Data<\/strong><\/h3>\n\n\n\n

Analytics stop your persona from becoming folklore. Look at activation and drop-off by cohort, feature adoption by segment, device and network mix, churn timing. When the interviews and the event data disagree, the data wins on what happened, and the interview wins on why it happened. A PM who can pull their own event data with a bit of SQL<\/a> moves noticeably faster than one who files a ticket and waits three days for an analyst to get back to them.<\/p>\n\n\n\n

Step 5. Synthesise, Don’t Just Collect<\/strong><\/h3>\n\n\n\n

Pull observations onto individual notes, one per note. Group by similarity of behaviour and motivation, never by demographic. Name each cluster by what it does. If two clusters would lead to the same product decision, merge them, they’re not actually different personas. Most products need two to four personas total: one primary, one or two secondary that must never be broken, optionally an anti-persona. Past four, the team quietly stops using any of them. This clustering step is where raw notes turn into something you’d actually present, the same instinct behind any decent business analytics workflow<\/a>.<\/p>\n\n\n\n

Step 6. Write It, Date It, Show It, Version It<\/strong><\/h3>\n\n\n\n

One page, present tense, in the user’s own words. If it needs a second page, it’s a research report, not a persona. Socialise it, invite engineers and business stakeholders into at least two research sessions, people tend to defend conclusions they helped reach. Put a \u201clast validated\u201d date on it and a review cadence, and archive old versions instead of quietly editing over them.<\/p>\n\n\n\n

<\/span>A Worked Example: an Indian Lending App<\/strong><\/span><\/h2>\n\n\n\n

Picture a Delhi-based consumer lending app. Strong sign-ups, decent traffic, and a KYC completion rate that falls off a cliff at the last step. The team already has a persona. It hasn’t helped anyone with anything. (Composite example, not a real company.)<\/p>\n\n\n\n

The Weak Persona<\/strong><\/h3>\n\n\n\n

\u201cRahul, 28, Delhi, works in IT, earns \u20b98 LPA, tech-savvy, wants quick loans, likes convenience.\u201d Every word here is either unverifiable, non-actionable, or true of tens of millions of people. Which backlog item does this change? None. Not one.<\/p>\n\n\n\n

The Deep Persona<\/strong><\/h3>\n\n\n\n

After twelve interviews and three months of event data, the picture looks different. The goal isn’t \u201cwants a loan,\u201d it’s bridging a specific \u20b915,000 gap before a medical bill hits. The workaround is borrowing from a colleague, free but socially expensive, and it turns out to be the real competitor, not another lending app. The context: a shared Android phone, KYC attempted at night in bad lighting. The trigger is an unplanned expense, not a marketing push. The constraint: won’t proceed without a visible, RBI-recognised trust marker on screen.<\/p>\n\n\n\n

What Actually Changed on the Roadmap<\/strong><\/h3>\n\n\n\n

\u25cf        The KYC document-capture flow got rebuilt for low light with inline retry guidance, jumping ahead of a planned rewards feature in the queue.<\/p>\n\n\n\n

\u25cf        Trust signalling moved from the About page (where nobody read it) to the loan-amount screen, right where the hesitation actually happened.<\/p>\n\n\n\n

\u25cf        The acquisition message shifted from speed (\u201cloan in 5 minutes\u201d) to discretion, because the interviews showed the real thing being avoided was the awkward conversation with a colleague.<\/p>\n\n\n\n

Nothing in the deep persona was a new idea. It was a set of facts that made an existing debate decidable. For context on how fast internet and payment behaviour keep shifting here, IAMAI-Kantar’s Internet in India series<\/a> and NPCI’s published UPI data<\/a> are worth a look before you assume last year’s persona still holds.<\/p>\n\n\n\n

<\/span>A Ten-Point User Persona Quality Checklist<\/strong><\/span><\/h2>\n\n\n\n

Run through this in five minutes, honestly, before you present anything:<\/p>\n\n\n\n

1. \u00a0 Can you name a specific decision this persona would change?<\/p>\n\n\n\n

2. \u00a0 \u00a0 Is every field traceable to evidence, an interview, an observation, a data point?<\/p>\n\n\n\n

3. \u00a0 \u00a0 Does it describe behaviour and goals, not just demographics?<\/p>\n\n\n\n

4. \u00a0 \u00a0 Is the goal written in the user’s words, not the team’s?<\/p>\n\n\n\n

5. \u00a0 \u00a0 Does it name the current workaround, the thing you’re really competing with?<\/p>\n\n\n\n

6. \u00a0 \u00a0 Does it capture context and constraints: device, network, language, money, permission?<\/p>\n\n\n\n

7. \u00a0 \u00a0 Does it carry an evidence base and a \u201clast validated\u201d date?<\/p>\n\n\n\n

8. \u00a0 \u00a0 Is it one page?<\/p>\n\n\n\n

9. \u00a0 \u00a0 Is it distinct from your other personas, would it actually lead to a different decision?<\/p>\n\n\n\n

10. \u00a0 Have engineers and business stakeholders seen it, and can they name it without looking?<\/p>\n\n\n\n

Fewer than seven yeses means you’ve got a proto-persona. Label it as one until it earns the upgrade.<\/p>\n\n\n\n

Worth saying for anyone early in their career: a well-built persona with a visible research trail is a strong portfolio piece for a PM interview, precisely because it shows the reasoning chain, evidence, synthesis, decision, that case-study rounds probe for. If you’re aiming to break into product roles, this breakdown of getting into product-based companies<\/a> is a useful next stop. Walk the interviewer through the decision it changed, not the artefact itself. Nobody wants a tour of your Figma file.<\/p>\n\n\n\n

<\/span>When User Personas Mislead Teams<\/strong><\/span><\/h2>\n\n\n\n

Here’s the part nobody puts on their persona template: personas fail confidently. A wrong persona doesn’t create doubt, it creates a team perfectly aligned around the wrong thing, which is somehow worse than no alignment at all.<\/p>\n\n\n\n

The Averaging Problem<\/strong><\/h3>\n\n\n\n

Merge several real users into one \u201ctypical\u201d user and you can end up with a person who exists nowhere, same idea as designing a cockpit for the average pilot and finding it fits nobody. If your persona is the arithmetic middle of your users, it may describe none of them. Fix: build around modes, the most common distinct behaviour patterns, not means. A cluster genuinely split two ways is two personas, not one blended one that satisfies nobody.<\/p>\n\n\n\n

Never Validated, or Never Updated<\/strong><\/h3>\n\n\n\n

The expiry rule again: a proto-persona older than one research cycle and still unvalidated should be treated with suspicion, not authority. NN\/g’s own diagnosis of why personas fail<\/a> comes down mostly to adoption problems: built in a silo, no leadership buy-in, never actually used.<\/p>\n\n\n\n

Staleness is the quieter killer. A persona built pre-launch and still on the wall two years later describes users who’ve since moved on, especially in fast-growing Indian consumer products where the second million users rarely behave like the first hundred thousand did.<\/p>\n\n\n\n

When Jobs-to-Be-Done Fits Better<\/strong><\/h3>\n\n\n\n

Give this one its due instead of dismissing it. The JTBD argument, most associated with Clayton Christensen’s work in Harvard Business Review<\/a>, is that who a customer is predicts poorly what they’ll buy. What they’re trying to get done predicts it far better. The same person hires a product for different jobs depending on circumstance.<\/p>\n\n\n\n

Practical resolution: use JTBD when the question is what to build, since the job is stable and circumstance-driven. Use personas when the question is who you’re building it for and how it needs to feel: context, constraints, trust, language. They’re complementary, not rivals.<\/p>\n\n\n\n

Can AI Just Generate the Persona For You?<\/strong><\/h3>\n\n\n\n

Worth addressing head-on, since someone on your team will try it, probably this week. An LLM can produce a fluent, well-formatted, plausible-looking persona in about eight seconds, and that speed is exactly the risk. It’s synthesising the internet’s average assumptions about a user type, not evidence about your actual users. Fluent isn’t the same as true.<\/p>\n\n\n\n

Where it genuinely helps: drafting screener questions, transcribing and tagging interviews, a first pass at clustering open-ended survey responses, summarising support tickets, or pressure-testing a persona you already built (\u201cwhat would prove this wrong?\u201d). AI tooling has moved fast enough in Indian workplaces that it’s worth understanding where it fits, Scaler’s AI workforce research<\/a> is a decent read on that shift.<\/p>\n\n\n\n

Where it doesn’t help: replacing the interviews. AI can accelerate synthesis, it cannot originate evidence. Anything it hands you before you’ve spoken to a real user is a proto-persona with better grammar than it’s earned.<\/p>\n\n\n\n

<\/span>Frequently Asked Questions<\/strong><\/span><\/h2>\n\n\n\n

What is a user persona?<\/strong><\/h3>\n\n\n\n

A research-based fictional profile representing a real behavioural pattern among your users: their goal, context, constraints and the outcome they want. It replaces \u201cthe user\u201d with a specific someone, so decisions become concrete and arguable.<\/p>\n\n\n\n

What are the 4 types of personas?<\/strong><\/h3>\n\n\n\n

Goal-directed (Cooper), role-based (Grudin, Pruitt & Adlin), engaging (narrative-driven), and fictional or assumption-based. The first three are research-grounded. The fourth is a hypothesis, and should stay labelled as one until it’s validated.<\/p>\n\n\n\n

How do you create a user persona?<\/strong><\/h3>\n\n\n\n

Name the decision it needs to inform, run 8 to 15 behavioural interviews, size the patterns with a sampled survey, ground it in analytics, cluster by behaviour rather than demographics, then write it up on one page with a date and evidence base.<\/p>\n\n\n\n

What’s the difference between a user persona and a buyer persona?<\/strong><\/h3>\n\n\n\n

A user persona describes the person using the product, owned by product and design. A buyer persona describes the person deciding and paying, owned by marketing and sales. In B2B these are usually different people.<\/p>\n\n\n\n

How many user personas should a product have?<\/strong><\/h3>\n\n\n\n

Two to four, for most products: one primary, one or two secondary that must not be broken, and optionally an anti-persona. Past four, teams quietly stop using any of them.<\/p>\n\n\n\n

What should a user persona template include?<\/strong><\/h3>\n\n\n\n

Name and descriptor, context of use, goal, current workaround, pain points, motivations and triggers, constraints, one verbatim quote, and an evidence base with a date. Cut anything that wouldn’t change a decision.<\/p>\n\n\n\n

Can AI generate a user persona?<\/strong><\/h3>\n\n\n\n

It can draft one fast, but it’s working off general assumptions rather than evidence about your users. Use it for screeners, tagging interviews and clustering responses, not for replacing the interviews themselves.<\/p>\n\n\n\n

The value of a persona was never in the artefact. It’s in the decisions it makes possible. Depth doesn’t mean more fields, if anything it means fewer, each one backed by something you actually went and found out. So pick a decision you’re stuck on. Go find eight people who’ve lived through that exact situation. The user persona will more or less write itself after that, and the deciding part gets easier too.<\/p>\n\n\n\n

Turning research like this into prioritisation, positioning and roadmap calls is the day-to-day job of a product manager, and it’s what Scaler’s online PGP in Business & AI<\/a> is built to teach, through structured discovery projects and mentorship from people who’ve actually done this for a living.<\/p>\n","protected":false},"excerpt":{"rendered":"

Two teams ship the exact same feature. One gets adopted within a week. The other quietly dies in a changelog nobody reads. Usually the difference isn’t the code, it’s that one team could answer \u201cwho is this for, and what are they actually trying to do\u201d with something better than a job title and an […]<\/p>\n","protected":false},"author":230,"featured_media":14271,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"footnotes":""},"categories":[431],"tags":[566],"class_list":["post-14270","post","type-post","status-publish","format-standard","has-post-thumbnail","category-product-management","tag-user-personas"],"acf":[],"_links":{"self":[{"href":"https:\/\/www.scaler.com\/blog\/wp-json\/wp\/v2\/posts\/14270","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.scaler.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.scaler.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.scaler.com\/blog\/wp-json\/wp\/v2\/users\/230"}],"replies":[{"embeddable":true,"href":"https:\/\/www.scaler.com\/blog\/wp-json\/wp\/v2\/comments?post=14270"}],"version-history":[{"count":1,"href":"https:\/\/www.scaler.com\/blog\/wp-json\/wp\/v2\/posts\/14270\/revisions"}],"predecessor-version":[{"id":14272,"href":"https:\/\/www.scaler.com\/blog\/wp-json\/wp\/v2\/posts\/14270\/revisions\/14272"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.scaler.com\/blog\/wp-json\/wp\/v2\/media\/14271"}],"wp:attachment":[{"href":"https:\/\/www.scaler.com\/blog\/wp-json\/wp\/v2\/media?parent=14270"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.scaler.com\/blog\/wp-json\/wp\/v2\/categories?post=14270"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.scaler.com\/blog\/wp-json\/wp\/v2\/tags?post=14270"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}