The ‘good enough’ principle has been around for a few years now, especially in the software development world. It’s part of the agile approach and is one of the secrets behind the successes of giants like Google, Microsoft and Facebook.
No ad to show here.
In many ways, the approach is counter-intuitive. Most of us were brought up to strive for perfection, but the fact is that it takes a lot of time and energy to achieve perfection, and the risk is that by the time you do, the thing you have created is out of date.
The quest for perfection the first time round almost always leads to costly delays and slow time to market.
The rationale behind the good enough principle is that customers (or early adopters at least) will use a product that meets an important need, as long as the product is good enough. In other words, it doesn’t need world-class functionality, it doesn’t even need to look that good. It simply has to do a great job at meeting the basic need it was created to meet.
But diving in and creating a new product or piece of software when it hasn’t been fully defined is daunting. I wouldn’t be surprised if there were people reading this article who have some great ideas but are too scared to start developing them.
The beauty of the good enough approach is that it enables you to get real customer data and feedback very early on, so that you can build and tweak the product as you go.
Usually, we create what we call a ‘minimum viable product’, something that is complete and robust enough to go to market, with just enough functionality. Once it has been used and tested, a new layer of functionality is added, tested and released to market. And so the cycle continues.
Google is a great example of a big company that has mastered the art of ‘good enough’. It is constantly introducing new services and products, which often remain in beta for years, even after millions of people start using them. By getting customer feedback early on, it can make constant incremental improvements to the products until they meet the need they were designed for, at the level that Google has become famous for.
Shifting the focus away from perfectionism does not however mean that quality can be compromised. Quality is never optional. When we work towards ‘good enough’ and early launches, we do so by doing less, not doing worse.
For example, you can build a beautiful Porsche with all the bells and whistles, but if every piece of the engine isn’t in working condition, the car is completely useless. You’d be better off in a go-kart or on a bike, at least they would get you where you need to go.
The good enough approach also enables faster, better decision making – vital in the ever-shifting world of customer demands and economic conditions. “Product development is not like building a road or a bridge, where there are few variables. Things change all the time, sometimes at the speed of light, and if you miss the opportunity to react fast, you could lose out.”
How good is good enough?
“Good enough” might seem like a subjective measure, and in many ways it is, but a product is only considered good enough when the positive consequences of creating it are greater than the negative consequences.
Producing ‘good enough’ products is an art
Getting the balance right requires a solid understanding of agile development processes, the problem at hand, and the tradeoffs available to you at every stage of development. Discipline and communication are key to keeping the project on track over what can often be a lengthy development process. But most importantly, never forget the requirements of your intended market.
Wider implications
The good enough approach is valid within a business too. In fact, it leads to much greater collaboration and productivity. Rather than slaving away on a project in isolation until it’s ‘perfect’, encourage staff to share their work as soon as they think it is good enough.
Sometimes it’s uncomfortable, but in the long run, involving others early and getting feedback is always worth it.
