building user personas

I have reviewed more than a thousand persona documents across cohorts at Pragmatic Leaders. Most of them are useless. Not because the PMs were careless — they spent hours on them. They are useless because they describe users without making any decisions.

A persona that says “Rahul, 28, software engineer, likes productivity tools, frustrated by inefficiency” tells you nothing your competitors do not already know. It does not tell your designer what to build. It does not tell your engineer who to optimize for. It does not force any trade-off.

The purpose of a persona is not to describe your users. It is to help your team make consistent decisions when you are not in the room.

That is a different standard. And most personas fail it.

What personas are not

Before the how, the what-not.

Personas are not average users. An average of your user base tells you who your median user is. That person often does not exist. If 40% of your users are students and 60% are working professionals, your average user is a working student — a segment that is probably your smallest cohort. Optimizing for the average means optimizing for nobody.

Personas are not roles. “The IT admin” is a role, not a persona. An IT admin at a 10-person startup in Bangalore and an IT admin at a 5,000-person BFSI firm in Mumbai have completely different contexts, constraints, and definitions of success. The role is the same. The person is not.

Personas are not market segments. A segment is defined by demographics: “25–35 year olds, tier-1 city, household income above 8L, Android user.” That is useful for media planning. It is useless for product decisions. Segments describe populations. Personas describe the specific way a person thinks, works, and makes decisions.

Personas are not stereotypes. I have seen “the young digital native” as a persona in a 2019 product deck. That description covered 400 million people and predicted exactly nothing about behavior.

A real persona is a model — a specific archetype synthesized from actual research. It has a name because humans think in stories. It has a context because behavior is situational. It has frustrations because frustration reveals what someone actually values. And it has a goal that your product either helps with or does not.

The two-track problem in Indian product teams

Most persona frameworks come from the US, where research participants are easy to recruit, users will talk to you freely, and the dominant distribution channel is the web. Indian product context breaks all three assumptions.

Track 1: B2C with India’s socioeconomic complexity

India does not have one middle class. It has at least three economically distinct groups who are often lumped together in persona work:

• Urban affluent (top 5%): English-first, iOS-heavy, willing to pay, high trust in digital transactions
• Urban aspiring (next 20%): Hindi/regional language-first, Android, price-sensitive, adopts digital slowly but loyally once converted
• Semi-urban and rural (the rest): Feature phone or entry-level Android, low data, WhatsApp-native, often makes decisions in family or social groups rather than individually

A fintech app that builds personas for the “Indian urban professional” is collapsing two or three meaningfully different people into one document. When those people want different things — and they will — the team has no tiebreaker.

Track 2: B2B with India’s buying structure

In US B2B, the buyer and user are often the same person or closely aligned. In Indian mid-market and enterprise, the buying triangle is almost always three separate people:

• The decision-maker (CFO, CHRO, IT head): signs the purchase order, cares about cost, compliance, and vendor risk
• The champion (middle manager): evaluates the tool, runs the pilot, cares about solving a specific operational problem
• The end user (IC): actually uses the product daily, cares about speed and whether it makes their job easier or harder

Most Indian B2B products have personas for the end user but not for the decision-maker or champion. Then they wonder why deals stall or churn happens despite good usage metrics. The person who evaluates is not the person who pays, and the person who pays is not the person who uses. You need all three.

What a useful persona contains

Stop at six attributes. Beyond six, no one reads it.

1. Name and a single-sentence context

Not demographics. Context. “Meera is a 32-year-old product manager at a Pune-based B2B SaaS company with 80 employees. She reports to the co-founder and has no formal PM team above or below her — she is the PM function.”

That one sentence tells you: no playbook to lean on, high ambiguity, founder proximity, scrappy execution environment. Every product decision for this persona now has context.

2. The primary job

What is she trying to accomplish in her work — the thing she is measured on, the thing that makes or breaks her quarter? Not “use your product.” The underlying job. For Meera it might be: “Ship features fast enough that the engineering team feels productive and the founders feel like the roadmap is moving, without accumulating so much debt that the product breaks.”

This is the job JTBD would surface. The persona holds it.

3. The specific frustration

Not a generic pain point. A specific moment where things break. “Meera’s biggest recurring frustration is sprint planning — she spends four hours every two weeks figuring out what goes in the sprint, arguing with the engineering lead about estimates, and then having to re-explain priorities to the co-founder who shows up at the demo with different expectations.”

Specific enough that if you read it aloud to a PM in that situation, they would say “yes, that is exactly my life.”

4. What they use today

The current solution. In India, this is almost always a combination of tools, not one product. Meera is probably running product management through a Notion template, a Jira board that is half-maintained, a WhatsApp group with the engineering lead, and a Google Doc shared with the co-founder. That combination is your competition — not another PM tool.

5. The decision filter

What lens does this person apply when they evaluate whether to adopt something new? Meera’s filter: “Will this make my sprint planning easier, or will I spend the first month just setting it up and training the team?” She is not looking for the most powerful tool. She is looking for the one with the lowest adoption tax for a team that has no time to learn new software.

6. The quote

One sentence in their voice that captures how they see their situation. Made up but plausible — synthesized from research, not invented from thin air. For Meera: “I am the only PM here, so every decision either gets made by me or does not get made at all.”

That quote tells your designer and engineer who they are building for faster than three paragraphs of analysis.

How to build one that actually works

Step 1: Do the interviews first.

This should be obvious. It is not. I have reviewed persona documents built from intuition, from LinkedIn browsing, from “we know our users.” That is not research. That is assumption organized into a template.

You need at least five to eight interviews with real users before you write a persona. Not surveys. Conversations. Forty-five minutes each. Ask about their work, their frustrations, their current tools, their definition of a good day and a bad day. Listen for patterns.

In India, getting these interviews is harder than in the US. Users are less accustomed to “customer research” calls. Frame it as a conversation about their work, not feedback on your product. Offer something in return — a report, a summary of what you learned, a coffee. And do not schedule through email if you can help it — WhatsApp follow-ups get four times the response rate.

Step 2: Find the segments by behavior, not demographics.

After your interviews, do not group people by age or job title. Group them by how they behave and what they care about. Two people with the same job title can be in completely different behavioral segments.

Common behavioral splits in Indian B2B:

• Process-first (needs structure, documentation, approval flows) vs. velocity-first (wants to move fast, hates bureaucracy)
• Tool-trusting (open to adopting software) vs. tool-skeptical (will use your product alongside their existing system, never replacing it)
• Individual decision-maker vs. consensus-driven (every change needs buy-in from two or three people)

These behavioral differences predict how someone uses your product far better than their age or company size.

Step 3: Build one primary persona, acknowledge the others.

The mistake is building five or six personas and treating them equally. You cannot optimize for five people simultaneously. Pick the one your product is primarily designed for — the one who, if you get them right, makes your product great. Then write the others as secondary, with a note on where they diverge from your primary.

For a Pragmatic Leaders student management tool: the primary persona is not the student. It is the program manager — the person who tracks cohort progress, manages assignments, handles escalations, and reports to leadership. If the program manager cannot use the tool efficiently, nothing else matters.

Step 4: Validate the persona by testing decisions against it.

Before you publish the persona to your team, take five recent product decisions and run them through it. Does the persona predict the right trade-off? If the persona suggests your user prioritizes speed but your recent decisions optimized for feature depth, either the persona is wrong or your decisions were wrong. Either answer is useful.

The India-specific segments most PM resources skip

Standard persona frameworks, written for US markets, skip the segments that matter most in India. Here is what you actually need to know.

Tier-2 and tier-3 city users: These are not a niche. According to IAMAI, the majority of India’s next 500 million internet users are coming from non-metro markets. They use mobile-only. They have interrupted connectivity. They often share devices. They are WhatsApp-native and suspicious of email. If your product does not work on a 2G connection with a three-year-old Android phone, you have implicitly chosen not to serve them.

The family-unit decision-maker: In consumer finance, health, and education, the person who uses the product is often not the person who decided to buy it. A mother buys an online tutoring subscription for her child. A father decides which health app the family uses. A husband and wife jointly evaluate a home loan app. Personas that assume a solo decision-maker will misfire in these categories.

The WhatsApp-first business owner: SME India runs on WhatsApp. The decision-maker at a 15-person trading company in Kanpur does not use email for business communication. Her customer interactions, supplier negotiations, and team management all happen in WhatsApp groups. If your B2B product requires onboarding via email, you are starting with a channel she does not trust.

The English-reluctant power user: India’s largest professional segment is comfortable in their regional language but uses English software because there is no alternative. They will use your product and tolerate the English UI. But they will refer it to others in their language, describe its value in their language, and complain about it in their language — in communities you probably are not monitoring. Your NPS survey in English is not capturing their real opinion.

Common failures worth naming

The aspirational persona. Built around who you want your users to be, not who they are. I have seen B2B startups build personas for “data-driven decision makers” when their actual users are spreadsheet-and-gut operators who will never open an analytics dashboard. Build for who you have, not who you want.

The persona that gathers dust. A persona document no one has seen since the kickoff workshop. The test is simple: can your engineering lead name the primary persona and describe their main frustration without looking it up? If not, the persona has no operational value.

Five personas with no priority. Every persona equally important, every persona’s needs equally weighted. Teams that build this way end up making no decisions — every feature request can be justified by one persona or another. You need a primary. Everything else is context.

The persona without a context. “Riya, 29, product manager, wants better collaboration tools.” Where does Riya work? How big is her team? What does “better collaboration” mean when her current stack is Google Docs, WhatsApp, and daily standups? Without context, the persona is a description without predictive power.

Test yourself

Where to go next

• The research methods that feed persona work: User Research Methods — how to run interviews, what to ask, and how to get Indian users to actually talk to you.
• The framework that pairs with personas: Jobs to Be Done — personas tell you who; JTBD tells you what they are trying to accomplish. Use both.
• Understanding your market before narrowing to a user: Market Research — sizing, competitive mapping, and where your persona sits in the broader landscape.
• Translating persona insights into what you build: Writing PRDs — how the primary persona becomes the decision anchor for every spec.