“They’re Just the Users”

One of the best engineers on my team at Stackify loved writing documentation. He wrote detailed guides and cared about getting it right.

I’ll never forget the day I told him customers were struggling to use what he’d built. We had just launched new security admin controls that he was very proud of.

He looked at me, confused. “It’s all documented,” he said. “Tell them to read the support documentation.” Then he turned back to his screen, like the problem was solved.

RTFM. Read the F-ing manual.

But here’s what I told him: The software should be clear enough and intuitive enough that they don’t need to look anything up.

He didn’t like that. Not because he didn’t care. But because it wasn't his focus. His goal was to build the feature and make it work. It passed tests and followed the requirements.

If you’re being honest, most of us learned to define success the same way.

Like a lot of engineers, he struggled with something you can’t code: Empathy.

Not for the product. For the person who has to use it.

Reality check: Most users don’t wake up excited to use your software. They wake up trying to get something done. Trying to close a deal. Run payroll. Meet a deadline. Too often, your software gets in their way.

When You Start Building for Them

At Stackify, we built tools to help developers find and fix bugs in production software deployments.

But our users didn’t actually want to use our product. If they were, it meant their day had gone sideways. They were chasing production fires and getting pressure from every direction to fix them.

We assumed more usage meant more value. We were wrong.

Customers said, “I just need to know why production is broken.” That’s when it clicked. They didn’t want dashboards. They wanted answers. So we stopped trying to keep them in the product. We focused on getting them what they needed, without even logging in.

We gave them clearer alerts, faster answers, and less noise. The product got more complex under the hood. But simpler for the user.

It became more valuable because we stopped building for ourselves. We realized we were building for someone in the middle of a high-stakes, high-pressure day. Someone who just needed to know what was wrong and how to fix it.

That’s the shift this chapter is about: the moment you stop seeing users as a burden and start treating their pain like it’s your problem.

That shift doesn’t come from process or a better roadmap. It takes empathy, curiosity, and the belief that users aren’t the problem.

They’re actually the reason you have a job.

The Empathy Gap

From school to the workplace, we’re rewarded for solving technical puzzles, not human ones. We’re rarely taught to listen, interpret vague feedback, or imagine what it feels like to use what we built.

Over time, that creates a quiet bias: Technical problems feel like the real work. User problems feel like someone else’s job.

Many of us join a team where the product team owns the roadmap, support owns the feedback, and engineers are cut off from the user.

Your team slowly loses touch with the people they’re building for. It slips out in passing comments. A shrug during standup. A joke about another support ticket. A quiet assumption: if your users are confused, they didn’t try hard enough, or weren’t the right kind of user.

It may sound harmless, but it reveals a lack of empathy.

The moment teams stop caring whether people understand the product, they start building something people struggle to use.

But confusion doesn’t lead to success. It leads to churn. Some users blame themselves. Others blame the product. Either way, they walk away thinking it wasn’t built for them.

Empathy isn’t a nice-to-have. It’s a requirement. It’s the discipline of paying attention to where people struggle, and why.

The goal isn’t “It works on my machine.”

The goal is “It works for the users.”

Empathy also can’t be one-directional. If engineers don’t feel it from leadership, they won’t show it to users.

When engineers feel boxed in, disconnected, or dismissed, they start to disengage, too. Not because they’ve stopped caring. Because they don’t see how it matters anymore.

If no one listens to them, why should they care how the user feels?

Empathy has to flow both ways. When it doesn’t, the product suffers on both ends. We’ll come back to that, because it’s not just users who need empathy.

They’re Not You, and That’s the Point

“If it works for me, it’ll work for them.”

We assume our users think like we do. But they don’t. That’s why their perspective is so valuable.

At VinSolutions, our users were salespeople at car dealerships. You know the type. Talks fast, knows nothing about the car, and somehow sells you one anyway.

A long time ago, we used to joke that our target customer was basically a fifth grader with a hangover. It was a crude exaggeration. But it reminded us of one thing: our users weren’t us.

They weren’t less capable. Just different.

That “fifth grader” line wasn’t about mocking them. It was about humility. It helped us break the default mindset that said, “I know how this works, so everyone else should too.”

It reminded us to get out of our heads and into theirs. To stop building for ourselves. And start building for the person who actually has to use it.

Build Like It’s for Your Own Kids

If I could give you one piece of advice, it’s this: Build like it’s for your own kids.

Not because users need to be coddled. Because great software comes from care, not just competence. You wouldn’t hand your kid an app and say, “Figure it out.” Sure, kids figure out tech fast. But you’d still want them to feel confident, not confused. You’d make it clear, trustworthy, and forgiving enough to recover from mistakes.

That’s empathy in engineering. Not dumbing things down. But making people feel seen, capable, and supported. And when something breaks? You don’t blame them or throw the manual at them. You fix it.

You are not the user.

But you remember what it felt like to be one. Build like you’re designing for a younger version of you.

They’re the Reason We’re Here

If we want to build great products, we need a culture that doesn’t roll its eyes at the user. A culture that takes them seriously. A culture that listens, learns, and cares.

Everything is changing. AI is rewriting the playbook. Roles are shifting. The barriers to building have fallen away.

The people who thrive won’t just be great coders. They’ll know what to build, why it matters, and who it’s for. The real skill isn’t execution. It’s user empathy and product thinking.

And it starts by replacing “They’re just the users” with “They’re the reason we’re here.”

Remember, you’re building products, not just writing code. The future doesn’t belong to teams that build the most. It belongs to the ones that build what matters.

What matters has to be defined together, out loud, and with the user at the center. The user isn’t just part of the story. They are the story.

And that’s not just a mindset. It’s a leadership choice.

At Amazon, they famously leave an empty chair in meetings to represent the customer. A physical reminder that the user has a seat at the table, even when they’re not in the room.

That's leadership that never forgets who they're building for. Protecting that perspective isn’t just an engineering job. It’s a leadership one.

Product Driven Leaders build environments where empathy isn’t optional, it’s expected. They model it. They reward it. And they make sure the user never gets left out of the room.

Everyone wants engineers to care about users. But too often, no one cares about the engineers.

That’s our next problem.