I’m a Kiwi developer in Seoul, and the product I work on is a community for people who are serious about skincare and cosmetics. I am not that person. My skincare routine is sunscreen, on a good day. Which means my instincts about what our users want are wrong often enough that I’ve learned to stop trusting them.

If you’re building for an audience with different needs, backgrounds, or preferences to your own, your gut is miscalibrated. Here’s what I do about it.

Research beats instinct

#

When your gut is tuned to the wrong user, the only fix is contact with the real ones. Surveys and interviews give you the raw material — people will tell you exactly what frustrates them if you ask open questions and then shut up. Lurking in the forums and communities where your users already hang out is even cheaper, and the daily complaints and enthusiasms there tell you more than any workshop. Existing reports and studies round it out; they’re mostly useful for checking whether the pattern you spotted is real or just the three loudest people.

An example persona

#

Here’s the shape I’d boil that research into, for a community app like the one I’ve described. Min-ji is made up for this post; a real persona should come straight out of your interviews and forum reading.

A persona earns its keep when it feeds the backlog. Each goal or frustration turns into a user story in the usual “As a …, I want …, so that …” shape: As a shopper with sensitive skin, I want to filter reviews by skin type, so that I only read about products from people whose skin reacts like mine. If a story can’t be traced back to a persona, it’s worth asking who it’s really for.

Get inside their head, then into their routine

#

Empathy mapping sounds like consultant theatre, but the exercise of writing down what a persona thinks, feels, says and does forces you to notice where you’ve been projecting your own preferences. The sticky notes aren’t the point. Catching yourself assuming is.

The stronger version is immersion: use the products your users use, watch the content they watch, go where they go. Actually trying the routines our users discuss has taught me more about what the product needs to explain than any spec document ever did.

Prototype, test, listen, repeat

#

No amount of research survives first contact with a prototype. So build the smallest testable version, put it in front of actual target users, and treat their confusion as data, not as them “using it wrong”. Keep real feedback channels open after launch too, because understanding isn’t a one-time achievement — the audience shifts, trends move, and last year’s insight quietly goes stale. The loop doesn’t finish. That’s fine.

Borrow better-calibrated eyes

#

Some gaps you can’t close alone. Colleagues who actually belong to the target group will spot things you’d never see, and I lean on mine constantly. When the gap between you and your audience is a canyon rather than a crack, hire for it — a consultant if you must, or better, a team member who simply is the user.

Underneath all of it is one discipline: remembering the goal is to make something that resonates with them, not something that pleases you. I still catch myself designing for me. The research, the testing, and the borrowed eyes are just ways of catching it early. Do that consistently and you end up with a product that works for the people actually using it — which was the whole point.

I’ve been finding that line the hard way. I’m a developer who ended up leading a project team, not someone who trained for this, so most of what follows was learned by getting it slightly wrong first.

What empathy in leadership actually means

#

Empathy in leadership means understanding how the people on your team are actually doing, and letting that carry real weight when you make decisions, give feedback, or decide how the team works. It isn’t agreeing with everyone, and it isn’t being pleasant in meetings: you can understand someone’s situation completely and still say no. When people can tell their situation gets factored in, they relax, they speak up earlier, and the work genuinely goes better. That part of the standard advice holds up.

Too little hurts. So does too much.

#

The failure everyone warns you about is the cold manager who treats people as resource allocations. That one’s real: ignore what’s going on in someone’s life and they go quiet, morale drops, and you find out about problems months late.

The failure nobody warns you about is the opposite. If you accommodate everything, boundaries blur. Deadlines turn into suggestions. And the people quietly holding the standard start to resent covering for the ones who aren’t held to it. I’ve caught myself over-accommodating because it felt kind in the moment — it wasn’t kind to the rest of the team.

Examples of empathy in leadership, done well and overdone

#

The difference is easier to see side by side. None of these are rules, just the shape I’d aim for:

Everything in the overdone column has one thing in common: it feels kind in the moment, and it pushes the cost onto later, or onto someone else.

Check-ins do most of the work

#

What keeps me somewhere near the right balance isn’t a philosophy. It’s a recurring calendar slot. Regular one-on-ones mean small problems surface while they’re still small, instead of arriving all at once as a resignation letter.

Mine loosely cover the same ground each time: what’s blocking you, what’s gone well lately, how the team is working together, where you want to grow, and what I could be doing differently.

The most useful question I’ve found is a plain one: “Is there anything you need from me or the team to help with your tasks?” It sounds mundane. It isn’t. It signals that I expect to be part of the solution, and the answers are almost always concrete things I can actually fix — access to someone, a decision that’s been floating, an hour of pairing.

Being straight when the answer is no

#

Check-ins generate requests, and you can’t grant them all. How you handle the ones you can’t is where trust gets made or lost.

What works for me: take the request seriously and say so, explain why it can’t happen right now, offer whatever partial alternative exists, say when you’ll look at it again — and then actually come back to it, even if the answer hasn’t changed.

None of that makes a “no” fun to deliver. But people handle an honest “no, and here’s why” far better than a vague “we’ll see” that’s never mentioned again.

That’s about as close to a formula as I’ve got: care about how people are doing, be honest about what the work needs, and check in often enough to notice when you’ve drifted too far in either direction.