Building the Right Thing vs Building the Thing Right

By Isaac Davenport, PhD

In workplaces with many different departments, there is a tension between building the right thing and building the thing right. Sales and marketing teams sometimes promise clients products and solutions that may not be realistic, and engineering teams may not be able to understand exactly what problem clients are trying to solve. Sure, at the end of the day, you and your team will end up with a finished product or solution. But if that finished product doesn’t address the right problem, what you’ve got is an elegant bridge to nowhere. 

As an engineer, I see this all the time. Engineering teams can often feel as if they lack control over what the finished product should be, so they become overly focused on what they can control: making sure whatever they do build is flawless. The problem, of course, is that this commitment to building the thing right can lead teams away from ultimately building the right thing. Here’s how to approach this tension between teams in your organization. Despite your team’s different roles, all want the same things: to create something useful and to make clients happy. 

Building the Thing Right 

At our core, we engineers want to produce elegant, maintainable and well-crafted solutions. We want to reduce, rather than grow, technical debt. Our egos (sorry, fellow engineers, but you know it’s true) and professionalism drive us to develop products using the latest and greatest tools, frameworks, protocols, libraries, chips and materials. If there’s a newer and better way to do something, you can just about guarantee engineers will move to that newer, better way. 

Basically, we want to learn and use the most up-to-date tools and techniques. No one wants to be in charge of maintaining a design that has drifted into “the big ball of mud” or “pile of spaghetti” design pattern. Using the best tools at our disposal to build the best version of whatever it is we’re tasked with is the ultimate goal for engineers.

Building the Right Thing

Of course, a commitment to building the right thing on a micro level loses an essential macro and high-level perspective. And sometimes, what’s needed on a macro level just isn’t feasible or communicated clearly to engineering teams. Agile, as a project management approach, is useful in quickly developing solutions to problems and getting those solutions delivered. But if someone’s key focus is to keep clients engaged and happy, and not necessarily to ensure that the solution they’re seeking is even technically possible, you’ll end up with the solution not really solving a problem. 

To bridge this gap, I usually suggest that teams include engineering staff in product- or solution-scoping calls. These types of hybrid, cross-functional teams are popular in today’s organizational structures and for good reason: they reduce barriers between team members, and they help create alignment from the get-go. 

And to help facilitate this alignment, I work with my engineering team members at Actall to develop their skills in empathy when interacting with clients, which is absolutely key to helping clients solve their “real” problem—especially when they can’t articulate their problem in strict engineering terms. 

Simply being in the field as part of scoping calls can help with empathy. So can getting into the “jobs to be done” mindset: What job, really, does the client need to be done? A classic example is someone purchasing a hammer. They’re not just purchasing a hammer, they’re purchasing a way to hang a picture. That’s the job to be done. 

“Struggling moments” are also helpful in building empathy. Where does the client struggle doing their job now? After digging in a bit during these struggling moments, which may even include how the user feels about the job they are trying to do, I often see unexpected pain points or solutions arise—and great opportunities to solve real problems. 

Wrapping Up

So, what should organizations do? For engineering teams, it comes down to focusing on building what the client actually needs—even if that means using a tool from the last decade’s tool kit, or hacking in a prototype of a feature that might really solve a client’s problem. Basically, put “building the right thing” ahead of “building it right.” 

For sales, marketing and customer service teams, it’s essential to bring the engineering team in early, and to work with them on skills related to connecting with clients. 

For an organization as a whole, it’s important to set a realistic pace for product or solution development. No more promising the moon when you can barely get two feet off the ground. And, as always, creating cross-functional teams helps bridge departmental gaps, improve communication and deliver what clients really need: solutions that work. Happy building.