"Good Enough" Is A Milestone, Not A Result

In recent history, I've come to recognize two polar opposite perspectives to solving a particular problem. And neither of them are ideal.

Let's begin by playing out a hypothetical situation, starting with any given solution. In this case, how about ... a personal budgeting app.

Johnny (or Bill, or whoever is your hypothetical male character) looks at the budgeting app and says, "It's not good enough." Johnny knows that it does some things really well. It pulls in his statements automatically, it performs calculations correctly, and so on. It frustrates Johnny that he can spend money he doesn't have. That's not how he believes a budgeting app should work. So he finds himself a team and they set out to build yet another budgeting app.

Suzie (or Janice or Meredith) comes along and finds the same budgeting app. She likes the app. She says that pulling in her statements automatically is better than anything out there. She'll deal with the lack of envelope budgeting because everything else is so great.

Johnny and Suzie have completely opposite opinions and reactions to the same product. But, did you notice that both of them agreed on something? They both agreed it did some things well (solved part of their problem), but lacked as a full solution. The difference is that Johnny wasn't satisfied with half a solution, while Suzie considered the app good enough.

The Perfect Solution Is Full Of Waste

Johnny and his team are going to set out to redesign the perfect solution. The issue with his approach is that it's littered with waste.

First, he has to begin by getting up to the level of the solution he is critiquing. This is work that's already been done. And in some cases (like building a budgeting app), it can take a lot of effort just to match the alternatives (or competition).

But more important is that when he gets into designing his perfect solution, he's going to uncover variables and conditions he never anticipated. When you design complex solutions, regardless of the medium in which you solve a problem, you won't account for every condition or every variable. It's just not realistic. The more varying conditions, the higher the number of assumptions you have to make. And the higher the number of assumptions, the more likely the solution is to fail.

Settling Is Lazy And Short-Sighted

Suzie is going to leave the product as it is, use it, and move on with her life. Sometimes that approach is okay. When it's something simple, like where you store your trash can, it's not worth it to spend time designing a good solution when the difference between it and the next best solution is negligible.

But, in general, especially for more complex solutions, there will come a point in time when settling becomes detrimental. Solving half of a complex solution likely means there are inefficiencies within the solution. For example, if the budgeting app doesn't have an annual planning feature, then there's going to be time lost in working around it. There will come a point in the future at which the time Suzie has lost to inefficiency becomes more than time spent to remove those inefficiencies.

Finding The Balance

Life is about balance, and that's no different here.

When you aim to solve a challenge, you should begin by doing the least amount of work possible to solve the bare essential set of conditions. In other words, solve all the important things immediately and deal with some lingering inefficiencies in the short-term.

In other words, the first pass at a solution can, indeed, be good enough.

But, good enough is only a milestone. It is not your solution.

As you practice your solution, consider where your inefficiencies lie. Address them in small batches over time. And as you address these inefficiencies, work to lessen the number of assumptions you build into your solution. You will never eliminate assumptions altogether, but you should do your best to minimize them.

It's much more helpful and rewarding to spend time making something better than dealing with something not being fully right.

And yes, my example was meant to be a jab at Mint.com.