Reconnecting Engineers to the User

At nineteen, I was building software for ticket brokers. My first job had me writing code in the back of taxis and inside server closets.

But the real impact wasn’t the code. It was how I worked. I sat next to the people using our software. I heard what worked, what didn’t, and what they actually needed.

That’s how I figured out what to build. Not in a planning doc, but in real conversations. There was no roadmap. Just the next conversation guiding the next line of code.

I wasn’t just shipping features. I was solving problems I understood. And I cared more because I could see the impact up close.

It gave me something I didn’t yet have words for: clarity, focus, and vision. I knew what mattered. And I knew how to move fast without wasting time on the wrong things.

Most teams never experience that. Not because they don’t care, but because they’re kept at a distance.

Feedback gets filtered. Problems are described, not felt. That distance leads to rework. That’s why teams build the wrong thing. Or burn out building features no one uses.

This chapter is about fixing that.

Not with theory. With simple habits that bring your team closer to the people they’re building for.

Because nothing builds clarity and motivation like hearing the customer explain their problem and how to fix it.

We’ll break down what that looks like: support rotations, user shadowing, demo days, and more.

The goal is simple. Bring engineers closer to the problem.

When Engineers Hear the Customer, Everything Changes

Most teams think their engineers are solving customer problems.

But when’s the last time those engineers actually heard from a customer, firsthand and in their own words?

I mean, really listened to someone describe their frustration, confusion, or excitement firsthand. It happens less often than we’d like to admit, but when it does, everything changes.

Suddenly, the feature isn’t abstract because there’s a real person behind every decision.

Your team starts asking better questions.

They solve root problems, not just symptoms.

They shift from optimizing for velocity to caring about users.

You can feel the shift when an engineer hears feedback directly.

At one of my early startups, we built software for home service companies. Plumbers, HVAC contractors, and the like. I didn’t know anything about plumbing. But I spent hours talking to them. I listened to what frustrated them and what they wished existed.

I wasn’t gathering “user requirements.” I was building real understanding and empathy. I knew which problems were not important to them and which ones made them pull out their wallet.

That changed everything, for them and for us. And it can happen for your team, too.

It’s easy to assume engineers can’t get close to customers at scale. Or that customer insights belong to the product team. But that’s not true.

The real problem is when customer understanding feels like someone else’s job. Not by accident, but by design.

In reality, the closer your team is to the user, the better product they can build.

The question isn’t whether engineers can hear the customer. They can.

It's whether you make space for it.

Be the User, Shadow the User

You can review feedback and analytics. You can watch recordings. But nothing compares to becoming the user. The moment you become the user, even briefly, you see things you’d never catch from a distance.

One of my first jobs was at a medical lab. I didn’t have to guess how the software was used. I could walk down the hall and sit at the same workstation our lab techs did.

That opened my eyes. User interfaces that seemed fine on paper broke down in practice. Workflows that worked in theory collapsed under pressure. I left those sessions with ideas no whiteboard could’ve produced.

You learn faster when you step into their world.

Some companies go even further. They send engineers on-site to shadow users. Or do the job themselves. Not just interviews, but real-world immersion. Engineers process transactions and fill out forms in high-stress environments, just like the users they’re building for.

One of our customers at Full Scale builds software for parole and probation. They actually have employees simulate being on probation. That way, they can understand what it’s like to be tracked and followed. That creates empathy you can’t get any other way.

If you can’t be the user, then shadow them. Watch how they actually use the product. Not how they say they use it, or how you hope they do.

How do they really use it?

There are tools for this. Screen recordings, session replays, usage metrics, and user flow tracking. What matters is how you use the insights. Watch the clips, share them, and talk about them with your team.

Seeing someone struggle with your product changes how you think.

Stop defending what you built and start defending the users.

That’s what Product Driven teams do, and what yours can do, too.

Empathy Is a Strategic Advantage

Empathy gets treated like a soft skill. Something nice to have. But the real cost isn’t emotional. It’s strategic.

When engineers don’t understand the people they’re building for, they make assumptions. They follow specs without question. Ship features that sound useful but don’t get used. And repeat the cycle. Features ship, but the value doesn’t land.

I’ve felt that on both sides.

I rely on QuickBooks to run my business. But every year, an update breaks everything. They recently changed how reporting works. The one feature I depend on. Now it’s slower, harder to find, and nearly unusable. It tells me no one talked to users like me. Or if they did, they didn’t listen.

As a builder, I've seen the difference. We built software for plumbing companies. For people in trucks, between jobs, tapping screens with big, dirty thumbs. That context changed everything. It had to be fast and simple.

I didn’t understand that until I saw the world through their eyes.

That kind of empathy sharpens judgment and creates empathy. It reduces wasted resources and builds clarity. It shifts focus from edge cases to real ones.

Build Feedback Loops, Not Distance

In a better world, every engineer spends time with customers. They’d sit in on calls. Watch users struggle with real problems. Ask questions. Hear feedback firsthand.

But most teams aren’t set up for that.

Too much distance.

Too many layers.

Too many “that’s not my job” moments.

The good news is you can fix this with simple changes. A few mechanisms that make user understanding normal, not exceptional.

This is where leadership matters. Your job isn’t to control every interaction. It’s to create conditions where engineers hear from users regularly, consistently, meaningfully.

Here are a few feedback loops that work in almost any team.

Share the Meeting Recordings

Have your sales or account teams record customer calls and demos. Then share the best clips with engineering. Not the whole call. Just the highlight reel.

Let them hear what excites users.

Let them hear the frustration in their voice.

Let them hear how the product is positioned. And how it actually lands.

At VinSolutions, we used to share demo recordings with our team. You could see it click for engineers when a customer lit up over something they built. It changed how they saw their work and reminded them that someone on the other end actually cared.

Let Support Speak

Schedule regular syncs between support and engineering. Not to dump tickets. To surface patterns.

What are users struggling with?

What do they keep asking for?

What workarounds reveal what the product should already be doing?

Support isn’t a dumping ground. It’s your frontline diagnostic tool. Use it that way.

Rotate for Empathy

Create a lightweight on-call or support rotation. Even once a quarter.

Let engineers feel the friction. Own the pain. Fix what they broke.

Nothing like being level two support makes you understand the real pain points of using your software.

Involve Engineers Earlier

Bring engineers into customer conversations before the work starts.

Let them hear the problem, not just the feature request. Let them ask why and challenge assumptions. That context creates clarity.

Show the Real Thing

Demo days are one of your most powerful tools, if you use them right.

Don’t use them to celebrate delivery. Use them to connect effort to outcome. Use them to force the delivery of something you can demo.

Let Engineers Feel the Consequences

Some lessons don’t stick until you feel the pain yourself. Not through dashboards or retros. By hearing the customer on the other end of the line.

At Stackify, engineers rotated on-call. Handling alerts, support tickets, and bug escalations. That week, they owned it all. If something broke, they fixed it. If a customer was angry, they heard it. That changed how they worked.

Quality improved. Not because we enforced certain practices, but because they lived with what they shipped.

That kind of accountability shifts everything. It builds focus rooted in clarity, not pressure. And it comes from firsthand understanding of what matters, and what doesn’t.

Support teams aren’t just a buffer. They’re your signal. Your first warning is when the product breaks down in the wild.

When you connect support and engineering, you don’t just fix bugs faster. You build better instincts. Smarter teams. Products that hold up under pressure.

Demo Days That Teach, Not Just Tell

Most demo days are just feature dumps and ticket lists. A quick round of applause. Then everyone moves on.

When done right, demo days connect the work to the problem it solved. And the people it helped. That’s where the value is.

At Basys, a merchant processor, Chris Borchers changed how they ran demos. Engineers didn’t just show features. They explained the pain they were solving. And how their work made it better. It wasn’t just a demo. It sparked real conversations. Engineers saw how their work landed. And what mattered most to the business.

That shifted the energy from “Look what we built” to “Here’s why it mattered.” That framing reinforces product thinking.

It shows teams what success looks like. And shifts focus from output to outcomes. It keeps the vision alive. When teams see their work move the needle, the product vision stops being abstract. It becomes real and personal.

You don’t need to over-engineer it. Invite teammates from across the org. Keep the demos short and focused. That’s how you turn delivery into a learning loop.

Remote Doesn’t Mean Disconnected

User connection isn’t harder because your team’s remote. It’s only harder if you fail to design for it.

Here are five simple ways to keep the loop alive, even from a distance.

Virtual Shadowing

Host Zoom sessions where users share their screen.

Watch, ask questions, record, and share insights with the team.

Remote Support Rotations

Engineers can handle tickets from anywhere.

Let them feel the pain. And fix what they shipped.

Distributed Demo Days

Open up access, record the session, and gather feedback.

You get broader reach, clearer insights, and stronger engagement.

Searchable Feedback

Centralize user insights. Quotes, clips, support patterns.

Make them easy to find and act on.

Intentional Rituals

Alignment won’t happen by accident.

Schedule time to share learnings and build empathy into the rhythm.

---

Remote teams aren’t at a disadvantage. They just have to be deliberate. And when they are, they often have the edge.

The ROI of User Feedback Loops

User feedback loops take effort. They don’t always fit neatly into your schedule. But they change what your team sees. And what they do next.

You're not doing it for the ceremony. You're doing it to lead better, and the payoff makes it worth protecting.

Prevention beats rework

Every missed feature costs you twice: once to build, again to fix. Understanding the problem early saves weeks of waste.

Motivation comes from meaning

Engineers don’t burn out from hard work. They burn out when the work feels pointless. One real user conversation can flip that switch.

Feedback accelerates learning

You don’t have to wait for a failed launch. Watch the signals in real time and adjust faster.

Clarity replaces guessing

You stop chasing internal ideas. Stop polishing features no one uses. Focus on what matters, and know why.

---

None of this happens by accident. It happens when leaders make space for it and treat user connection as essential.

When engineers understand the people they’re building for, they make better decisions. They don’t just ship faster, they ship smarter. And they care more because they can see the impact.

The closer you are to user pain, the better the solution.