The Golden Nail

The Golden Nail

Introduction

You have probably heard some variation of the phrase “…a hammer looking for a nail…”. This concept is referred to as “Maslow's Hammer” or the “golden hammer”. It describes a situation in which you become so enamored with a tool, that you look for any excuse to use it. In my time in the startup world, this has quickly become one of the most challenging things I have had to overcome when trying to decide what to build next.

The challenge is that often when you feel like you are solving a problem, you are in reality forcing a problem to fit your ready-made solution. This is further complicated by the fact that the processes we have in place to surface & address problems, often make it easier to fall into this trap. We have a tendency to jump on potential solutions before we truly understand the problem we are attempting to solve, especially when the potential solution presents itself early on in the process. In our efforts to move quickly, it is easy to try & solve a problem with a solution we have already worked out, than to dig deeper to see if it really solves if our hammer truly fits the nail.

“In our efforts to move quickly, it is easy to try & solve a problem with a solution we have already worked out, than to dig deeper to see if it really solves if our hammer truly fits the nail.”

The solution, suprisingly, is to focus on the problem itself. Thorough examination of the problem at hand will almost always lead to a better solution, often times with less effort than trying to make our solution fit the problem.

Being Problem-Focused

In a world where we are constantly being reminded to be solution-focused, this may seem quite counterintuitive. We tend to get bogged down in the problem we are facing, rendering us unable to lift our heads abover water long enough to actually find a way out of the problem.

Ironically, the same can happen when we focus on the solution side of the equation. So enamored with what solutions are available, it is easy to lose sight of the actual problem we set out to solve. Often trying to justifiy the use of a “obvious” solution, rather than implementing what may be a boring, albeit much better one. These hammers are often just laying around waiting for a nail. If the problem looks even close to what we built the solution for, we are all too quick to fix it, even if it turns out to be an ill-suited, more complicated solution.

“If the problem looks even close to what we built the solution for, we are all too quick to fix it, even if it turns out to be an ill-suited, more complicated solution.”

When we make the problem the focus, we are forced to ensure that the we are truly solving it, & not just that our solution sort of works. The key is to not get bogged down in why we have the problem (which is why we are often told to be solutions focused), but instead catalog the problem, so we can solve it completely & efficiently. We must shift our goal from finding that golden hammer, & to instead look for that golden nail.

Unfortunately, the processes many of us have in place lend themselves to making that difficult. Often filling are heads with seemingly elegant, obvious solutions, these processes often lead us astray. The good news is, with a small shift in perspective, we can leverage our current processes to better identify real problems and elevate the experience for our users.

Every company has their own set of processes to identify & solve users' problems. I am going to use an example of one we frequently use & discuss how we fixed it to help us better solve our pain points for our customres. My hope is you can take the lessons we learned, & use them to adjust your own process.

“The good news is, with a small shift in perspective, we can leverage our current processes to better identify real problems and elevate the experience for our users.”

Why Don't We Just Ask Them?

At Piqora we take an obvious, but useful approach to identifying user issues: We just ask them. We do this through phone calls, emails, surveys, & polls. Seems pretty straightforward, but were we asking them the right questions? On the surface this seems simple, you present your users with a list of potential features, & ask them whether you should build them. You gather your responses, walking away with a great list of new features that will make your customers incredibly happy. All you have to do is build the features your customers are asking for & you will succeed. Break out the champagne & start celebrating!

Sadly, this approach is the perfect way to waste a bunch of time building elaborate features our users may never touch. The problem, you will quickly find, is a majority of our users will say “yes” to pretty much any shiny & new thing we propose. When presented with a list of cool sounding features with no qualifiers, it is likely you would have a hard time finding anyone who would say no. It is the equivalent of asking if someone if they would like a free Ferrari.

Let's look at why this feedback isn't actually useful to us. Pretend for a second that we went back & asked our customers a few more questions. What if we followed up by asking how they would use that feature they just told us they absoluetly wanted? I would wager that a good portion have no real idea of how they would use it. Some may not even know what that feature would do. While on the surface this doesn't seem like a problem, ultimately we have a limited amount of bandwidth, & building something we aren't sure will actually get used is not an effective use of our time. That Ferrari might be less tempting if you can't drive a stick.

“The problem, you will quickly find, is a majority of our users will say “yes” to pretty much any shiny & new thing we propose.”

How about another question: How much would your users be willing to pay for this feature? This takes the previous question a step further. Now not only are we interested in if they would use the feature, but if they would use it enough to be willing to pay for it. Even if you company doesn't charge for its product, this is still important. This type of response shows you what features create value for our users. Feature that our users will use enough to create value for them are the things we should be building. Our Ferrari, that you might not be able to actually drive, now comes with a price tag.

Now I would never suggest we approach our users with these questions. In fact, the approach I outlined above has a major flaw. It assumes that we are really good at guessing what features will solve our customers' problems. But what the example does do, is call out the things we should be thinking about when formulating the type of questions that will unearth these features we should be building.

Feel Their Pain

But how exactly do we formulate these questions? The key is to understand our users' pain points. Ask them about their frustrations with your product, what tasks they wish they could get done through software, what other tools they use similar to ours, because we aren't completely solving their particular use case.

These questions accomplish two very important things. Most obviously they surface the problems we need to solve, but they also serve a less obvious function. They avoid us getting caught up in an easier, but possibly incomplete, solution. If our questions are phrased in a way that asks customers to offer their own solution, we are more likely to latch onto that hammer before we even know if it is the right one.

“The reality is, our customers are probably not the best people to be solving their own problems.”

The reality is, our customers are probably not the best people to be solving their own problems. There are often better, simpler ways to solve these problems. We just need to do our best to understand the problems we are trying to solve, so that we can propose the right solution. We also have to do this while avoiding false solutions that can lead us down the wrong path.

Conclusion

Not everyone takes the same approach as we do to determine what to build for our customers. However, I would bet the goals of any such process are the same: Build things that will solve problems & build value for our users.

If we adjust our processes to discover the real problems our customers are facing, while avoiding the pitfalls of false solutions, we can go a long way to building “the right things”. Being truly problem-focused will ultimately solve more of our users' pain points, in better ways, with a lot less effort.