Bridging the Gap: Why Developers and QA Teams Need Direct Access to Users
The joys of usability testing
On most software product teams, it’s standard practice for sales, customer support, product managers, researchers, and designers to regularly observe and interact directly with users & customers. But what about the people writing and testing the code? Sadly, they’re often the furthest removed from users—the very people they’re building for… by design.
The Problem: Disconnected Builders
Developers and QA engineers often rely on second or third-hand insights from designers, product managers, or researchers. As a result, they rarely, if ever, see the human impact of their work or fully grasp the real problems their product is built to solve.
This disconnect from users leads to:
A Lack of Empathy: Without firsthand exposure to the people they’re building for, developers and QA teams are unlikely to feel as invested in ensuring that the product addresses user needs and meets their expectations.
Misaligned Solutions: Building technically sound—often overly complex—features that miss the mark because they don’t easily & effectively solve users’ problems.
Resistance to Change: When late-stage changes are driven by user feedback, those furthest from the problem can feel frustration or resistance to making changes.
Untapped Creativity: Developers and QA engineers possess valuable problem-solving abilities and creative thinking that can significantly enhance product solutions. When they’re disconnected from users, teams miss out on leveraging that potential to build more thoughtful, user-centered features.
The Agile Barrier
One of the biggest obstacles to connecting developers with users is the way most modern software teams operate: the Agile methodology itself.
Today’s Agile frameworks favor developer productivity—measured by story points and velocity—over building for customer outcomes. The push for maximizing output leaves little room for “non-productive” activities like participating in interviews or monitoring usability sessions. Too often teams fall into a cycle of shipping features quickly, without truly validating that those features meet real user needs. Everyone on the product team—not just product managers and UX designers—should have regular opportunities to “get out of the building” and interact with users in their natural environments.
What Needs to Change: Baking Empathy into Agile
To balance productivity with user connection, teams need to bake time into sprints for developers to:
Go onsite and observe users in their environment.
Watch usability testing to see how real people interact with the product.
Participate in user interviews to hear pain points firsthand.
Create Structured Opportunities: Incorporate user interaction as a recurring sprint task—like a “user empathy ticket”—so it’s consistently prioritized. Rotate participation so all developers and QA engineers get exposure without slowing down progress.
Measure What Matters: Instead of just tracking story points, measure the quality and impact of features post-release to understand how user insight affects success. Make empathy-building activities a recognized, tracked, and valued part of the development process.
Building products that matter and transforming users into fans isn’t just about writing efficient code—it’s about solving real problems for real people. Time for product teams to rethink how they balance productivity and empathy within Agile practices. If your team doesn’t prioritize connecting developers and QA engineers to users, you’re building with one arm tied behind your back. Make user connection a core element of your Agile process for everyone on the team.
