When perfect gets in the way of good
How I try to be more pragmatic and experimental.
I guess you all know the situation in our job as knowledge workers: we face a problem and pretty quickly we are able to come up with a first solution or a concept how to solve it. Quite often, however, after some time we end up in a chaotic situation where we don’t make any real progress anymore. In some cases it even comes to a complete standstill, because the problem we started with has been joined by a colorful bouquet of other problems. We then find ourselves in a chaotic, complex situation where we are literally paralyzed from making any decisions.
In retrospect, the story often goes like this: after our first idea, we start thinking even more about the problem and quickly have more ideas. Especially when we work in a team or in a workshop together on a topic, there will rarely be a lack of ideas. In contrast, what we observe is the fact that many heads and thus opinions are in one room. Over time, more people and opinions are naturally added to a project, which often dramatically reduces the meaningful progress of the project.
One of the reasons for this mess is the tendency to strive for the perfect solution, which either solves the problem once and for all, or is as innovative as possible, so that hopefully a huge success can be celebrated later.
But what’s so problematic about striving for a best possible solution? Isn’t striving for less just lazy and unprofessional?
There is a very old saying that I like to quote every time I see this situation unfold. (commonly attributed to Voltaire)
Perfect is the enemy of good, or more literally the best is the enemy of the good
The underlying thought process is that we could always do a little better. As long as a design is not perfect in our eyes, there must always be a better solution out there. As long as we suspect weaknesses in our concepts, we have to eliminate them. Or do we?
The one thing we tend to forget in all of this is that while we are working on our ideas and concepts, we are not making any progress in the real world. It’s just an idea so far. It’s a concept to look at, but not a solution to the problem in reality.
Since I — like probably so many — was often stuck in these situations, I set out to find new approaches to bring improvements into the world faster, as well as to focus on iteration instead of perfection.
These approaches are in no way new. They are all well-known and infamous in the agile world as “lean principles.” The question I asked myself was: if we know how we should proceed in these situations, why is it so hard to execute then? Why do we keep falling back into the loop of achieving perfection, or witness discussing an initially good idea to death? As there are several causes and individual reasons for each case, however, I have identified a common pattern which is very difficult to combat:
The uncomfortable feeling of uncertainty
The moment an opportunity arises, we are uncertain if it is worth investing in. The moment we share an early rough idea, we are uncertain how the audience will react. Every time we have to decide on a path, we are uncertain if we have thought of all aspects and consequences. Maybe we forgot a point of view, or colleagues and other teams disagree, or who knows, maybe they have a better idea. All these thoughts slowly but steadily drive us to perfect our work.
- If it’s perfect, it will succeed.
- If it’s perfect, the feedback will be terrific.
- If it’s perfect, there won’t be a missing point of view.
In short, we just need more time to work on it… and there we are… full circle.
The only success gained from all the hard work so far is the certainty of having thought through the idea pretty well. However, rarely are all uncertainties resolved, rarely are all bugs and edge cases dealt with, and rarely are we 100% confident that the solution will prove to be a great success. Why? Because no end user has ever really used our solution.
The answer to this situation is to many quite obvious:
Release early and iterate quickly.
Sounds simple, but it’s hard to implement in many projects, because the uncertainty that comes with it is sooooo uncomfortable. After all, being experimental means not only learning to deal with uncertainty, but embracing uncertainty.
So here is what I do:
These days I’m pretty relaxed in sharing an early idea openly. I rigorously limit the amount of design and detail work in the early stages of an idea. I focus on understanding the problem and opportunity, but I’m pretty sketchy in crafting the solution. I force myself to talk to peers, stakeholders and users early on and look for resonance. If there is any chance, I even put out a first solution, just to learn about my core assumptions. All this feels sketchy and extremely uncertain, but makes a ton of difference.
Then I’m watching out for:
- What are the first reactions when I tell my story?
- How does the resonance change when I refine my storytelling?
- Does the idea change anything in terms of priorities (talking to peers) or behavior (talking to users).
If the resonance is a simple “nice idea” but not really triggering any change, then it’s a first indicator telling me to be careful in putting more effort into the idea or go back to the drawing board and try something different.
I know: Easier said than done, but give it a try on your next project … maybe pick one where the stakes are not the highest.
Fun fact: I took the same approach to writing this article. I limited the time to write it and published it at this rough, imperfect stage. So now I’m interested in your feedback. Does anything resonate with you? Does it change anything for you? Let me know in the comments below….
