Every product team loves a well-crafted persona: a neat profile that neatly summarizes who they’re designing for. But all too often, that persona is less “real user” and more “wishful thinking.” We scribble down demographic details—age, family status, job title—and voilà: our roadmap is set, our designs are approved, and our marketing copy writes itself. Yet these static snapshots can mask the messy, unpredictable realities of people’s lives. When those realities emerge, it can feel like the rug has been pulled out from underneath your roadmap.
A few years ago, I consulted in a major EdTech in India. Their target user was crystal clear on paper:
Name: “Priya”
Age: 35
Family: Married with two kids, ages 4 and 7
Job: Government school teacher in a Tier‑3 town
Lifestyle: Supportive husband and in‑laws help with childcare
Motivation: Eager to adopt new classroom tools
To anyone glancing at these bullet points, Priya seemed like a dream user: mature enough to understand pedagogy, curious enough to embrace innovation, and well‑supported enough to find the time. It felt like we had struck gold—or so we thought.
When we finally sat down with real teachers, everything about our Priya persona began to unravel.
Assumption | Reality |
---|---|
Age: Mid‑30s | Most women teaching with kids aged 4 and 7 are actually in their late 20s—early marriage and early careers are common. |
Supportive Home Life | Instead of help, many teachers return home to a “second shift” of cooking, cleaning, and childcare—no in‑laws in sight. |
Job by Choice | Teaching is often a necessity—a steady salary that fits within societal expectations, not a passion project. |
Tech Curiosity | Complex tools threaten classroom authority. If students master a tool faster, the teacher’s role feels undermined. |
Leisurely Learning Time | There are no 30‑minute coffee breaks. Any “learning” has to happen in stolen 5‑minute windows between classes and chores. |
Misaligned Motivations: Teaching isn’t “fun.” It’s a job that fits cultural and financial needs.
Scarce Time & Energy: At best, a five‑minute gap to explore a new feature—never a half‑hour deep dive.
Authority Preservation: Tools must reinforce the teacher as the expert, not expose them to potential embarrassment.
The original persona had shaped everything:
✍️ Copy assumed curiosity.
🧭 Onboarding assumed available time.
🔧 Feature complexity assumed confidence.
Once we saw the reality, we had to reframe everything:
Simplify interfaces—no learning curve, no ambiguity.
Design for low attention spans—5-minute windows, not 30-minute explorations.
Reinforce teacher authority—tools had to feel like enhancements, not risks.
What we had built made sense for the imagined persona. But for the real one, it added stress.
Most teams don’t ignore users—they just rush to define them. And once a persona is blessed, it becomes gospel.
Here’s the blind spot:
⚠️ Teams guess their way into personas. Then build real products on imaginary users.
⚠️ They focus on surface traits—age, job title, family—without understanding what life actually feels like.
⚠️ And once a persona is socialized, it becomes sticky. Even when the truth emerges, changing course feels hard.
👉 A persona is not a user. It’s a hypothesis.
👉 A real persona includes constraints, context, and coping strategies.
👉 The job of the product team is to stay curious—especially after the first draft.
It’s easy to fall in love with a persona that sounds good in a slide deck. But product decisions don’t happen in the abstract—they hit the ground in real people’s lives.
When you skip context, you don’t just miss nuance—you risk building entirely for the wrong person.
So treat personas as living documents. Pressure-test them. Revisit them often. Because the cost of getting them wrong shows up where it hurts most: in adoption, trust, and usability.