Your Personas Don't Predict Anything

Somewhere in your organization, there's a document that describes your users. It has names like "Marketing Mary" or "Developer Dave" or something equally cringeworthy. It lists their age, their role, their company size, their goals.

It tells you nothing about what they'll actually do.

This is the fundamental problem with personas: they describe attributes instead of behavior. And attributes don't predict behavior.

A 35-year-old product manager at a mid-size SaaS company could be shopping for a new analytics tool because her current one makes her look unprepared in front of leadership. Or she could be perfectly happy with her current setup and ignoring every ad you run. Same persona. Completely different likelihood of doing anything.

The persona can't tell you which one she is. Because the persona describes her demographically, not in terms of what she's trying to accomplish or what situation she's in right now.

Demographics Are Not Motivation

Personas were supposed to build empathy. Put a face and a name on the user so the team would design for a real person instead of an abstraction.

The problem isn't the intent. The problem is what personas actually contain. Age. Title. Company size. Industry. "Technically savvy." "Values efficiency." "Frustrated by manual processes."

None of that predicts anything, or gives you insight into motivation. Plenty of people who value efficiency keep using inefficient tools for years. Plenty of people who are frustrated by manual processes never switch. Frustration isn't action. Preferences aren't behavior.

Past behavior is the best indicator of future behavior. What someone actually did — what triggered them to look for a solution, what they tried first, what made them switch, what almost stopped them — is what tells you what they'll probably do next.

Personas don't capture any of that. They capture a static description of a person who doesn't exist, assembled from averages that don't describe anyone real.

Same Persona, Different Jobs

Here's where it gets expensive.

Two product managers at the same company. Same title. Same experience level. Same "persona." One is hiring your analytics tool because she needs to prove a recommendation to leadership before the quarterly review. The other is hiring it because he needs to catch a problem before his boss sees it.

Same persona. Completely different jobs.

She needs confidence-building outputs — clear visualizations, defensible data, a narrative she can present. He needs early warning signals — anomaly detection, quick scans, alerts before things escalate.

They have different anxiety profiles. Different definitions of success. Different features that matter. Different reasons to stay and different reasons to leave.

If you design for the persona — "product manager at a mid-size company who values data-driven decisions" — you design for neither of them. You build a generic analytics experience that technically serves the description and specifically serves no one's actual job.

Different Personas, Same Job

The reverse is just as common and just as invisible to persona-based thinking.

A marketing director at a 500-person company and a freelance consultant running a one-person practice can be hiring the exact same product for the exact same job: "figure out what's actually working so I can stop wasting money on what isn't."

Different demographics. Different company size. Different workflow. Different budget. Same job. Same desperation. Same switching trigger — the moment they realized they were making decisions based on a gut feeling and couldn't defend them.

A persona model puts these two people in completely different segments. The JTBD lens puts them in the same one — because they're hiring the product for the same reason, triggered by the same struggle, measuring success the same way.

Which grouping produces a better product? The one that organizes around why people act, not what they look like on paper.

What Personas Can't Show You

The deepest problem with personas isn't that they're wrong about what they describe. It's that they don't describe the things that matter — motivation and behavior. They can't tell you why someone acts, what triggers them to look for something new, or what they'll do when they find it.

Plus, they're static. They describe a person as if they exist in a permanent state — always this age, always this role, always these frustrations. But hiring a product isn't a permanent state. It's a dynamic moment. Something changed. Something made the status quo unacceptable.

Personas can tell you someone is "frustrated with manual processes," but they can't tell you what finally made that frustration intolerable this week instead of last month, what they did about it, what they tried first, or what made them keep looking.

The JTBD lens focuses on that action  and the forces that produced it.

What pushed them away from the old way? Not "frustration with manual processes,"  that's a persona attribute, and it's been true for years without producing action. What specifically happened that made this week different from all the weeks they tolerated it? A missed deadline. A visible mistake. A new boss who expects more. A competitor's report that made theirs look amateur.

What pulled them toward something new? Not "desires a more efficient solution," that's a generic platitude. What did they see, hear, or experience that made a better future feel reachable? A demo. A colleague's recommendation. A screenshot that made them think "wait, it can do that?"

What habit almost kept them from switching? Not "resistant to change." That explains nothing. What specifically was comfortable enough about the old way that they almost didn't bother? Their templates. Their muscle memory. The fact that everyone on the team already knew how to use it.

What anxiety almost stopped them? Not "concerned about ROI." That’s a checkbox on a persona card. What specifically scared them? That the migration would break something. That they'd look foolish for championing a switch that didn't work. That the new tool would turn out to be harder than what they had.

Traditional personas capture a static before picture with no meaningful context.

The Practical Difference

The difference between organizing around personas and organizing around Jobs shows up in what gets built, how it gets marketed, and who it reaches.

Persona-driven roadmap: Build features for "Marketing Mary" — she wants dashboards, integrations, team collaboration. Each feature sounds reasonable. None of them are grounded in a specific moment of struggle that would make someone switch to get them.

Jobs-driven roadmap: Build for the job "prove my recommendation is right before I have to present it." That produces a focused experience with a clear entry point (the moment the meeting gets scheduled), a clear output (a defensible, shareable analysis), and a clear success criterion (she walked in confident and walked out credible).

The persona-driven version produces a feature list. The job-driven version produces an experience that matches a real moment in someone's life.

Persona-driven marketing: "The analytics platform for data-driven marketing teams." Describes a category. Attracts browsers.

Job-driven marketing: "Stop guessing which campaigns are working. Know before the meeting." Describes a struggle. Attracts people who are already in pain.

Persona defenders will point out that good personas include behavioral data — not just demographics but goals, motivations, and frustrations.

Fair enough. But even behavioral personas describe behavior in the abstract: "frequently uses competitor analysis tools," "typically collaborates with 3-5 stakeholders." Those are still attributes.Yes, they’re behavioral attributes instead of demographic attributes, but it's still showing you a static description of a type of person.

The JTBD lens doesn't describe types of people. It describes types of situations; i.e., the specific circumstances that trigger someone to hire a new solution.

The same person can be in different situations on different days. Tuesday she's doing competitive research (one job). Thursday she's building a board deck (different job, different requirements, different definition of success).

The persona stays the same. The job changes. And the Job is what determines which features matter, which experience works, and whether the product feels like relief or like overhead.