Dear Mary-the-Marketer, you don’t exist — signed, every PM
So you built the perfect tool for your incredibly well understood user base. You know exactly who they are, what they need, and how they think.
And yet somehow, your product isn’t flying off the shelves the way you imagined it would. (No Product Market Fit for you, it seems.)
But you don’t quite get it. It just doesn’t add up — after all, you know absolutely everything there is to know about your users, and you’ve even compiled that understanding into picture-perfect (and picture-complete) user personas:
- Marketer Mary is a leader on her team. She juggles multiple campaigns, attends an average of 13 meetings per day (leading 4 of them), and works weekends to get ahead. More importantly, she’s a coffee aficionado who always has a fresh brew in her hand. She needs help managing her work or else she’ll spill her drink! (Oh, and she also loves the amazing deals she gets on Temu.)
- Sales Rep Sam is an eager 20-something trying to prove he can make it big, but is only willing to do so at a company that spends as much time fighting climate change as building their Software-as-a-Service. And the effect that has on how he works — well, let’s just say his 9–5 is a bit more whenever-he-happens-to-not-be-browsing-SJW-subreddits, so he better be efficient with his time.
- And Developer Dan, he’s a classic Millennial (and a new father to boot) that understands the power of technology, but gets super frustrated when he struggles with the inadequacies of legacy systems (especially since his unbalanced, avocado toast-heavy budget weighs so heavy on his mind) — without a system to automate his automations, he’d be dead in the water.
Here’s the thing: Mary, Sam, and Dan? They don’t exist.
And yes, I know you know that. But do you really know that?
While these personas are supposed to be making it easier for you to figure out what to build, the only thing they’re really doing is giving you an excuse to build the things you already want to build.
And even worse, it’s giving you an excuse to not talk to your real users. You know, the Marys, Sams, and Dans that actually have login credentials.
It’s time to change who you’re building for.
User personas aren’t people
[spoiler] Soylent green? Now that’s people.
User personas, on the other hand? Not people.
We’ve all been there. The conference room filled with sticky notes, the truly earnest discussions about our users’ hopes and dreams, the carefully crafted profiles complete with stock photos and imagined daily routines.
It feels good.
It feels thorough.
It feels like we really understand our users.
…
But we don’t.
Instead, we’ve created these comfortable fictions that let us avoid the uncomfortable reality that real users are weird, and unpredictable, and rarely fit into our neat little persona boxes.
The problems with user personas run deep:
- They oversimplify complex humans into stereotypes (as if everyone in marketing is a TikTok addict who loves inspirational LinkedIn posts)
- They become a substitute for actual stories from actual users about actual experiences (“Developer Dan would love this” vs. “here’s what an actual developer told us”)
- They create false confidence in our understanding (suddenly everyone becomes an expert on exactly what users want, despite not having talked to one in months)
- They make us lazy about user research (why waste time talking to people when you can just reference the persona doc from six months ago?)
- They emphasize aspirational behaviors over actual ones (“loves staying organized” vs. “has 1000 unread emails”)
- They encourage us to build for averages that don’t exist (just like how the average person has less than two legs)
Every persona you create puts another layer of abstraction between you and your actual users. The more detailed your personas become, the further you drift from reality.
Results of building for figments of your imagination
Building these fictional personas isn’t just ineffective — it can be actively harmful on your journey to build that visionary product of yours.
- You miss real pain points: While you’re busy solving Marketer Mary’s imagined problems, you’re missing the actual, messy, complicated problems you real users face.
- You build unnecessary features: It’s easy to convince yourself that your persona would love a feature. It’s harder to find real users who actually need it. (And to make matters worse, all those unnecessary features unnecessarily complicate your features that are actually useful.)
- You lose empathy: Real empathy comes from real interactions. Personas create emotional distance between you and your actual users. How do you feel about your robot vacuum? That’s how much you care about Developer Dan.
- You waste resources: Every feature prioritized for non-real-humans means resources not spent on real user needs. And that’s a pity, because resources are really tight these days.
All of this culminates in the opportunity cost of every real problem you’re not solving while you’re busy chasing imaginary ones.
Build for real humans
The path to building better products isn’t through more detailed personas. It’s through getting your hands dirty with real user and the real ways they interact with your product.
Make the transition from imagination to reality.
Step 1: Talk to real users
Product teams love to hide behind analytics because numbers feel safe and provable. And it’s hard to blame them. Nobody can really fault someone for making a decision quantitatively based on real hard data, whereas on the flip side, if a PM goes with their gut and it turns out to be wrong, they’ll have a lot of explaining to do.
All that said — this is the game.
Real insights come from real conversations that force you to confront the messy reality of how people actually use your product.
So:
- Schedule calls with users who recently submitted support tickets — their pain is fresh and real
- Spend time in your users’ workplace watching how they actually use your product in their environment — something may be obvious to you, but is it so obvious when someone is distracted by three other systems, or on the factory floor, or live testing an autonomous laundry-folding robot?
- Have engineers talk directly to users, instead of just handing them sanitized research reports that they can read but not really feel
- Field customer support tickets for a week each quarter — or heck, even just a day — to hear problems firsthand; you will be amazed by the smallest, most inconsequential (to you) details that trip people up
The best product insights often don’t come from formal research sessions — that’s like testing the “real-world” microbial defenses of a cleaning product in a sterile cleanroom. No — they come from genuine conversations where users feel comfortable enough to tell you what they really think.
Step 2: Embrace the chaos
Your users’ workflows are chaotic, inconsistent, and — let’s face it — completely illogical sometimes. Instead of trying to force them into your idea of how things should work, learn from how they actually work.
- Document unexpected ways users are using your features — just because you didn’t think of it, doesn’t mean it’s not valid
- Look for patterns in “incorrect” usage — they often reveal unmet needs
- Pay special attention to workarounds users figure out — they’re telling you what’s missing
- Study users who are pushing the limits of your product — what is just barely at the outer limits of possible, and what crosses over that line into the impossible (but still, previously unbeknownst to you, desirable)
- Welcome edge cases as learning opportunities instead of dismissing them as outliers
The “wrong” ways users use your product are often more informative than the “right” ways. Your job isn’t to correct their behavior — it’s to understand why they’re behaving that way.
Step 3: Build for someone specific
Get past those abstract personas you spent so much time carefully constructing, and build something a human will use, wants to use, will feel the pain of using.
- Choose a user who you feel represents a valuable segment of your target market — someone you’ve confirmed exists and hurts because you’ve talked to them yourself and have seen their pain
- Watch them do-the-thing (where the problem lies)
- Absorb the experience the user is going through — stop taking notes for a minute and allow yourself to truly step into the user’s shoes — go through what they’re going through, feel what they feel
- Design, productize, and iterate on a complete solution to their workflow — we’re not just talking about the core problem here… remember that whatever you build has to fit contextually into the rest of the product, and make sure the solution doesn’t come with a brand new set of pain points (in other words, build experiences, not features)
The experience of thoroughly solving a real problem for a real person is truly enlightening. It forces you to stop making excuses, get down to brass tacks, and meet the user where they’re at.
(This may feel counterintuitive — and to be clear, I’m not advising always building perfection — but it’s good practice to truly understand all aspects of the pain. You can get back to the very important skills of descoping and ruthless prioritization later.)
Step 4: Test with real people
And do it fast.
Don’t wait for pixel-perfect mocks, feature-complete prototypes, or completely bug-free feature.
The earlier you get real feedback, the less time you waste building the wrong thing.
- Create a small group of go-to “friendly users” who are willing to look at works in progress
- Show users those pre-mock sketches, those rough prototypes, those buggy features
- Pay close attention to where users get confused, where things don’t click — and don’t just rely on their words, watch their facial expressions and ask them to explain when they’re not being vocal enough
- Be willing to adjust your entire approach based on the real feedback from the real human who really experienced your real future — do not hand-wave away their very real concerns just because “they’ll get used to it”
It’s an oft-repeated line in product management, but it’s true: if you’re not embarrassed by the early versions you show users, you’re waiting too long to get feedback. Early embarrassment prevents later features.
Time to get real
Your imaginary users are holding you back. They’re making you soft… and overly comfortable… and just downright wrong. They’re turning your product development into a creative writing exercise instead of a genuine attempt to solve real problems.
Your real users, on the other hand, are waiting for you to pay attention to them. They’re struggling with problems you haven’t noticed because you’re too busy solving imaginary ones. They’re trying to tell you what they need, but you’re not listening because you’re too focused on what you think they need.
Kill your personas (don’t worry, it’ll be bloodless). Leave behind the comfort of your imagination, and step into the messy, complex, frustrating, ultimately-rewarding world of building for real humans.
At the end of the day, real people are the only ones who can make your product successful.
And real people can tell when you’re not really building for them.
So build for them.
Speaking of building for imaginary users… Are you tired of fighting with Jira’s UI? I get it. That’s why we’re building Momentum — it’s Jira on the backend, but with a UX that actually helps you do agile. No migration necessary. Curious? Join the waitlist.
Stop building products for your imaginary users was originally published in UX Collective on Medium, where people are continuing the conversation by highlighting and responding to this story.
Leave a Reply