A persona is a name badge, not a data source.
“Operations Olivia, 34, likes efficiency” tells your team a second user type exists. It does not tell you why Olivia picked your competitor last quarter, what spreadsheet she built to work around your product, or what she would actually pay to stop doing that. At its worst, a persona is corporate fan fiction: tidy, plausible, and disconnected from what people do.
I run 15 or more voice-of-customer interviews per launch, every launch, a habit I carry from leading the Prism co-pilot launch at Pixis. That discipline turned into exactly five roadmap features, not fifty, because saying no to the other forty was the actual skill. This post is the version of that discipline you can copy.
So that’s today’s post.
Today’s Post
How to replace a decorative persona with evidence, in six moves.
- Why a persona is a shorthand, not a source of truth
- Jobs-to-be-done: talk about progress, not demographics
- Why behavior beats self-report, and how to pair the two
- Running an interview like journalism instead of a sales call
- What to do when what people say and what they do disagree
- How much research is “enough,” by the kind of question you are asking
1. A persona is a shorthand, not a source of truth
Treat a persona as a communication tool, not a discovery. It summarizes what you already learned somewhere else. If the underlying learning was thin, the persona is wallpaper with a name on it.
Good teams retire a persona the moment reality moves past it. Weak teams defend a persona because a workshop produced it and nobody wants to redo the slide.
When someone says “our persona would want this,” ask one question: which observation supports that claim? If the answer is a single anecdote or silence, you do not have user understanding. You have a guess wearing a costume.
2. Jobs-to-be-done: talk about progress, not demographics
Jobs-to-be-done gets summarized as “people don’t want a quarter-inch drill, they want a quarter-inch hole.” The sharper version for you as a PM: people hire a product to make progress in a specific circumstance. The job is the progress. The demographic label is decoration.
A parent buying a meal kit on a Wednesday at 6 p.m. is hiring it to end decision fatigue that night, not to “eat healthy” as a lifestyle. A finance manager adopting a new analytics tool is hiring it to survive a board question next month, not to “modernize the stack.”
Three questions surface the real job every time:
- What were you doing the last time this problem hurt enough that you acted?
- What did you try before us, including a spreadsheet or a manual workaround?
- If we disappeared tomorrow, what would you do instead?
Notice the pattern. All three anchor on the situation and the substitute, never on an attitude.
3. Behavior beats self-report, and you should pair the two
People are unreliable narrators of their own habits. Not because they lie to you, but because memory and identity get in the way. They round frequency up, they downplay the workaround they built, and they describe the person they wish they were.
So pair every interview with observation wherever you can: session replay where it’s ethical and permitted, a site visit, a support call you shadow, an onboarding attempt you watch live, a verbatim support ticket. A user telling you checkout is “fine” while abandoning at the same step every time is not lying. “Fine” is a compression artifact; the behavior is the actual signal.
This is the same instinct behind instrumenting a real behavior instead of a login. On the Pixis Prism launch, we measured trial-to-paid conversion and onboarding time directly rather than trusting what users said about the trial, and the launch moved 25% and 40% on those two numbers respectively.
When you can’t observe directly, approximate it with an artifact: an export, a screenshot of a spreadsheet, a photo of a whiteboard. If a user hesitates to hand you that artifact, the hesitation itself is data, usually about trust or internal politics.
In B2B, add the workflow context: who approves the spend, who owns the metric, who inherits the tool after rollout. A delighted end user blocked by procurement is a different insight than a champion who controls budget. In B2C, look for the substitute you’re not tracking: a free app, an offline habit, a “good enough” workaround that competes harder than the logo on your competitor list.
4. Run the interview like journalism, not a sales call
A bad interview is a pitch in disguise. You lead, you steer toward validation, and you leave with a slide that says users love it.
A useful interview reads like journalism. You want the story: sequences, exceptions, and a number when you can get one. “How often does that happen?” “When was the last time?”
Ask about past behavior, never a hypothetical future. People are bad at predicting what they’ll do next. They’re better, though still imperfect, at recounting what they already did.
Five prompts do most of the work:
- Walk me through the last time that happened.
- What was the hardest step, and why?
- What workaround did you build for it?
- Who else had to get pulled in?
- What would have to be true for you to switch?
Watch for social desirability bias. People want to look competent and reasonable to a stranger asking questions. They’ll downplay how often they ignore an alert, break a policy, or care about price. A neutral tone and a request for an example instead of a rating gets you closer to the truth.
Listen more than you talk. If you’re speaking more than 30% of the interview, you’re performing, not learning. That’s the same ratio I hold myself to across the 15-plus interviews I run per launch.
Take notes that keep the verifiable detail: a number, a named tool, the exact sequence of steps, the exact phrase someone used. “They want simplicity” is not actionable. “They copy IDs into Slack because search can’t find a partial match” is.
5. What people say and what people do diverge, and the gap is data
When a statement and a behavior conflict, don’t jump to “they’re lying.” Usually they believe what they said. The gap is information: an incentive in the room, missing context, or a question you framed badly.
Write both down: the quote and the metric. Then decide which one your decision actually depends on. For adoption and retention, behavior usually wins the tiebreak. For positioning and language, what people say still matters, because words shape perception even when behavior hasn’t caught up yet.
A common pattern: a user asks for ten more features while only using two. That’s not hypocrisy. It’s an aspirational self-image running into a real constraint, usually time. Product strategy has to serve the actual two features people use; marketing can speak to the aspiration. Mix the two up and you ship bloat and still disappoint the customer.
6. Empathy is accurate modeling, not a feeling
Empathy is not a feeling you carry about a user. It’s accurate modeling of their constraints: time, skill, risk, internal politics, switching cost, and whatever else is competing for their attention that week.
Warmth builds rapport in the room. It does not replace rigor. If being “empathetic” makes you reluctant to push for a real answer, you’ll leave every interview with polite fluff instead of a decision-grade insight.
The strongest researchers stay warm and still ask: how do you know, can you show me, when exactly did that happen. That’s not cold. It’s respect for what’s actually true.
7. How much research is “enough” depends on the question
There’s no single number that works for every question you’re asking. Three rules of thumb:
- Early discovery on a messy problem: five to eight deeply contextual conversations often surface the major themes. You’re mapping the shape of the problem, not estimating a percentage of the population.
- Evaluative research, like a usability test: a small sample still finds the big issues, and a second round beats one giant study.
- Quantitative estimation, like a conversion lift or a segment size: you need real statistics and proper sampling. Twelve interviews are not a substitute for that math.
The failure mode on one side is using “we talked to ten people” to justify a precise forecast. The failure mode on the other side is running zero conversations while you wait for the perfect study design. Match the research method to the decision it’s actually informing.
Takeaways
Final Words
Personas were never the problem. Treating them as evidence was. Trade the name badge for a real observation: watch one session, run one journalism-style interview, or pull one export before you write the next persona slide.
User understanding is the foundation, but it is not the same thing as problem discovery. You can understand a person deeply and still chase a problem that is not worth your company’s bet. Next lesson covers how to validate that a problem is real, sized, and solvable before you fall for a solution.
Reply and tell me the last time a persona sent your team the wrong way. I am collecting examples for a follow-up.
Cheers, Hoshank