How I actually build them, and why most persona docs stop being useful the day they're written
Ayush Sharma · Product & Operations Lead, Medoc Health IT
Unlike Jobs to Be Done, personas were never a foreign concept to me — every course, every template, every onboarding deck talks about personas. That familiarity is exactly the problem. Because everyone's seen a persona template, most personas get filled in like a form: a name, a stock photo, an age range, three bullet points about "goals" that could describe almost anyone. I've written those. They get built once, dropped into a slide, and never opened again — which tells you they were never really about understanding anyone. They were about having a slide.
The personas that actually change what gets built look nothing like that. They're built from real conversations, they stay specific to a role you can find in the room, and they get revisited when the product moves into a new context.
A persona is a grounded description of a type of person who interacts with your product — their role, the context they operate in, what they're trying to accomplish, and what erodes their trust when things go wrong. It's meant to be stable: the same billing clerk persona should hold whether it's a normal Tuesday or a chaotic one.
That stability is the point, and also the limit. A persona tells you who you're building for. It doesn't tell you what to build in any given moment — that's a different question, answered by a different tool.
This is where most teams blur the two together, and it costs them. A persona is a person; a job is a situation. The same billing clerk (one persona) has a completely different job on a routine day than she does when an insurance approval changes mid-treatment — same person, two jobs, two different feature answers. If you only have a persona doc, you'll design for "who," in general, and quietly guess at "why now." Both are needed. Neither substitutes for the other.
<aside> 💡
Read more about how I use JTBD alongside this →
Jobs to Be Done: The Most Underrated Lens in Product Work
</aside>
Cardboard-cutout version:
Persona: Priya, the Billing Staff 28 years old, works at a hospital, uses computers daily, wants the software to be "easy to use" and "fast." Frustrated by "bugs." Tech-savvy, prefers mobile.
Nothing here is false, and nothing here is usable. It could describe almost any hospital employee anywhere. There's no situation, no specific frustration, no reason a product decision should go one way instead of another because of it.
The version I actually build:
Persona: Billing & Pharmacy StaffDaily, high-frequency user — the person whose job breaks first if the system doesn't fit their real workflow.
Context: Handles GRNs, POs, stock entries, and patient billing every single day. Often the first to notice a workflow gap, because it blocks a transaction that's already in progress, with a patient or vendor waiting.
Goals: Wants to finish a bill or stock entry in the same number of steps — or fewer — than the paper or Excel process it replaced.
Frustrations: Edits that should be simple (adding an item to a GRN, correcting a bill line) require workarounds, or aren't possible at all.
What actually earns trust: Fast, visible fixes to the small stuff. This group notices — and remembers — exactly how long a reported issue takes to close.
No age, no stock photo, no invented hobby. Everything in it is either something I heard directly from field feedback or something I can defend from watching the role do its job. It's usable because a PRD writer or an engineer can read it and know something concrete they didn't know before.