Your developers are building features based on tickets that read like technical shopping lists. “Add export functionality.” “Implement SSO.” “Create dashboard widget.” They knock them out efficiently, close the tickets, and move on to the next one.
Meanwhile, your customer success team is fielding the same confused questions over and over. Your users are clicking the wrong buttons, abandoning half-finished workflows, and finding creative workarounds for things that should be simple.
The disconnect isn’t because your developers don’t care. It’s because they’ve never heard a customer say “I don’t understand what this button does” while staring at something that took three weeks to build.
A feature specification can tell you what to build. A design mockup can show you how it should look. Neither can properly convey how a customer feels when they can’t figure out how to use it.
When we worked with SDES to digitize their Functional Academics program, the objective was pretty straightforward: replace their paper-based system with a digital platform. But when we watched teachers try to use early prototypes in actual classrooms, we saw them getting frustrated—not because the software was broken, but because we’d designed flows that made sense in a conference room but ignored the reality of teachers juggling multiple students with different needs at once. The interface we thought would make their lives easier, actually made their jobs harder. It wasn’t until we saw them try to use it in context that we truly understood what they really needed.
Developers who only see the spec think they’re building what was requested. Designers who only validate mockups in isolation miss how the feature fits into the actual workflow. But when your entire product team—design, product, and engineering—watches users struggle with the current system, everyone understands they’re solving a problem that’s causing real frustration every single day.
That shared context changes everything about how the team approaches solutions.
When your team sees a user’s face fall when they realize a task will take an hour instead of five minutes, they don’t need a project manager to tell them it’s important. They know.
Here’s what happens when the full product team watches live user testing: Everyone starts suggesting simpler solutions.
Not because they suddenly became lazier, but because they understand the actual problem. Designers see that the user doesn’t need a beautifully crafted multi-step flow—they need to complete one task quickly. Developers realize that the user doesn’t need fifteen configuration options—they need one thing to work reliably. Product understands that adding another feature isn’t solving the core workflow issue.
When we developed the bodymapping SDK for Prism Labs, we watched users struggle through early versions of the scan capture flow. The challenge was guiding someone through a precise bodyscanning process while standing several feet away from their phone—at points unable to even see the screen for visual cues. Our developers saw users getting confused about positioning. Our designers watched people give up mid-scan because the instructions weren’t clear enough at critical moments. That shared observation led the whole team to rapidly prototype and iterate together: engineers built in better pose detection, the designer refined the guidance system, and product focused on fixing the steps that caused the most confusion. The result was a high scan completion rate—not because any one discipline had the answer, but because everyone had watched real users struggle and collaborated on solving it.
When your entire product team regularly interacts with customers, something crucial develops: the ability for the team to have better conversations about solutions.
A designer who’s watched users get lost in a complex flow can explain to engineering why the proposed six-step wizard needs to be three steps. An engineer who’s seen users struggle with slow loading can explain to design why that beautiful animation is actually amplifying frustration. Product can prioritize features based on observed pain points rather than whoever shouted loudest in the last planning meeting.
This isn’t about designers overstepping into engineering or developers second-guessing design decisions—it’s about the whole team using shared context to build better products together. When a spec calls for a complex configurator, a team that’s watched users together can have a real conversation: “Do they actually need all of these options, or are we overbuilding this?"
The question “Can we solve this with something simpler?” is much easier to ask when the entire team has seen firsthand that users are already overwhelmed.
You don’t need to invite your entire product organization to every user interview. Start small and build the habit:
➙ Rotate team members through customer care sessions.
One person from each discipline—design, product, engineering—sits in on support calls or chat sessions. They observe, they don’t problem-solve in real-time. They’re there to understand the emotional experience, not debug it live.
➙ Run frequent live user testing sessions.
Get 3-4 customers on video calls walking through your product while your whole team watches. Record it for anyone who can’t attend live. The designer who watches users miss an important button, the developer who sees users confused by an error state, and the product manager who hears users describe a completely different mental model—they’ll all remember that in the next planning session.
➙ Share customer feedback in team meetings.
Not metrics—actual quotes and observations. “Sarah from Acme Corp spent 15 minutes trying to find the export button” hits differently when the designer who created that interface and the developer who built it are both in the room.
➙ Create space for cross-functional suggestions.
When a spec or design seems complex, ask the whole team: “Is there a simpler way to solve the user’s underlying problem?” The answer might still be no, but teams with shared user context will surprise you with collaborative solutions no single discipline would have found alone.
When we partner with companies on product development, this is exactly the dynamic we bring to the table. We regularly suggest simpler approaches that get you to the same outcome faster and cheaper because we are focused on understanding and solving user problems, not just building features.
When it comes to picking a development partner, you want a partner that fundamentally cares about your problem, not just billing hours.
