{"id":13541,"date":"2017-09-25T16:53:53","date_gmt":"2017-09-25T15:53:53","guid":{"rendered":"http:\/\/blog.intercom.com\/?p=13541"},"modified":"2020-07-30T12:57:50","modified_gmt":"2020-07-30T11:57:50","slug":"does-your-solution-solve-the-right-problem","status":"publish","type":"post","link":"https:\/\/www.intercom.com\/blog\/does-your-solution-solve-the-right-problem\/","title":{"rendered":"Does your solution solve the right problem?"},"content":{"rendered":"

The most productive engineers I\u2019ve ever worked with aren’t the engineers who pull all-nighters or clock in 80 hour work weeks. Nor are they the engineers who can effortlessly craft an elegant five lines of x86 assembly to succinctly and efficiently solve a problem.<\/p>\n

They are the engineers who always seem to be solving the right problem in the first place. If the mythical 10x engineer<\/a> really does exist, it\u2019s the engineer who is 10 times more likely to solve the right problem.<\/p>\n

While we might always set out with the best of intentions to solve the right problem as engineers, there are many mistakes we can make that will send us in the wrong direction.<\/p>\n

What solving the wrong problem looks like<\/h2>\n

Imagine you’re working for Silicon Valley’s newest, hottest unicorn start up. Your job is to build the best new to-do product since man first put pen to paper and the bullet point list emerged. The great visionary of the company, the VP of Product, walks up to you and tells you that it\u2019s time. You\u2019re going to build the killer new feature: notifications on your phone to remind you to tackle a task on your to-do list.<\/p>\n

The idea comes to you straight away. \u201cLet\u2019s build a notification delivery framework in a Go microservice.\u201d This seems like a solid idea, because you’re going to avoid the legacy cruft of this monolithic application that you’ve been working with for years, the one that’s been driving you nuts. And you’re going to perfectly encapsulate this simple task of sending notifications in its own little service. What’s more, you’re going to write that in a language that’s perfectly suited to this network-call-heavy workload. And you’re going to make it so that you can add notifications to this thing in the future.<\/p>\n

On the surface this seems like a really good idea, right? Your startup ends up with a key piece of technology that will solve important problems for years to come.<\/p>\n

But this statement terrifies me. It has a bunch of warning signs that you\u2019re about to go off and completely waste a whole lot of time, effort and money solving the wrong problems. So, what does it mean to solve the right problem?<\/p>\n

Software engineers aren\u2019t paid to simply produce lines of code.<\/p>\n

To borrow an idea voiced by Tyler Treat<\/a>, Phil Haack<\/a> and likely many others, software engineers aren\u2019t paid to simply produce lines of code. If we take a step back, we\u2019re really paid to build features, make things more efficient, make them scale bigger and bigger, and fix issues or prevent outages. The code is a byproduct of solving these problems.<\/p>\n

But more than that, engineers are ultimately paid to contribute to the success of the organization we work for in very real world terms. Engineers are paid to solve problems that increase revenue, decrease costs, increase customer satisfaction, decrease churn. When your work is focused on moving these kinds of metrics, then you know you\u2019re truly solving the right problem.<\/p>\n

So, back to your perfect notifications solution. Are you solving the right problem? I\u2019m going to go through three mistakes that I see here. Mistakes that I\u2019ve seen engineers hit over the years when starting a new project. Mistakes that tell me that you are not solving the right problem.<\/p>\n

Mistake 1: Technology-driven development<\/h2>\n

The first thing you’ve done is jump to a very technical solution \u2013 build a notification delivery framework in a Go microservice \u2013 very quickly. You\u2019ve received a high-level feature request and you\u2019ve immediately made a language and architecture choice without pausing for breath. By jumping to a particular technology, you have skipped over a bunch of really important questions:<\/p>\n