The real “perfect” implementation is somewhere else. This is easily illustrated by the following diagram:

Even if you can go from A to B directly and perfectly, that won’t do it, because, in fact, you want to be at C, but it is impossible for you to have any idea where C is.

2. The practical path to ‘perfection’

I’m sorry to say, but there’s another flaw with your plan: you again! You’re not alone in this one, though: your whole team is guilty! Real projects are fickle, difficult things. It takes all the willpower and social skills of a competent project manager to keep them aiming roughly in the right direction. Even then — especially if you’re lucky enough to be working with very smart people — there will be many side-steps, jumps and skips along the road. These are all perfectly natural and to be expected.

You will discover new things along the way, and that’s a good thing! Those will shift your end goal, and they will shift your direction too. By the end, your history of targets will be spread over a large area.

Your path to your end point(s) is likely to look something like the following picture.

On the good side, this means that your product will be more practically consistent. On the bad side, there’s no telling whether those changes will actually bring you nearer to perfection. Consistency doesn’t make or break a product. Users do.

3. The use(r)ful path to ‘perfection’

What a disaster. Not only you don’t know where you’re going on a high level, but you also don’t really have a clue from week to week. Surely there must be a solution to this quandary. Someone in the world can tell you what the perfect product is. Just hire them and you’ll be sorted.

Problem is, you can’t hire them. The only people in the whole world who can tell you where your product is going wrong are your users. The minute users get into the equation, you suddenly have some way, as uncertain, fickle, and vague as it might be, to tell whether you’re going in the right direction. You need them to provide you with timely, accurate, effortless feedback throughout your development process.

If you followed my tips and released a beta, or even alpha, and listened to your users, your path might look a little bit more like this:

And if you do this, chances are, you will probably turn out a pretty damn good product.

4. But… perfection does not exist?

Now, you might point out that I’ve made a pretty good case for why perfection is very hard to achieve. However, what I haven’t yet done is to explain why perfection doesn’t exist.

There are two good reasons why a perfect product doesn’t exist.

The first one is that there is an enormous variety of users out there. What’s perfect to one will be unbearable to another. You can, with some uncommon concentration of talent, build something that’s almost perfect for a lot of people. Apple have done it. Google have done it. And there are many other unsung heroes (though none seems to be quite as consistent as Apple), delivering fantastic products that are almost perfect for almost everyone. But every single one of these products is flawed in some ways for some people. In this sense, “perfection” is meaningless, a red herring. There is no perfection, only a good fit for a common denominator.

The second one, much more vicious, is that all those diagrams tell a pernicious lie. They completely hide the vicious, dynamic, crowded, unpredictable nature of the marketplace of desires, of what people want and how they want it. People’s needs change. Trends change. Impressions, desires and public perceptions shift each and every day.

Even if you could build a product that would hit the sweet spot in everyone’s heart and feel just perfect to your entire target market, that sweet spot will shift, implacably relegating your ‘perfect’ product to the dustbins of time. In short, even if perfection was theoretically possible, if you built a product that was perfect today it would be imperfect tomorrow.

5. What to do about it?

The main point of this article is to convince you to stop chasing perfection as a concrete goal. Striving towards building the best possible product is a good goal. Striving towards building a perfect product is an illusion, and a dangerous one at that. Striving to achieve perfection (or its sneaky twins, excellence and near-perfection) every step of the way is a deadly mistake.

Once you make it your aim to “build the perfect product”, you find yourself paralised by lengthy design work, longer iterations, and significant periods of “making the features perfect” without releasing anything to the users. This can and probably will kill your startup. Don’t make that mistake.

A much better modus operandi is to aim to move forward a little bit at a time, to build small increments of functionality that you can show to users as soon as possible. This, incidentally, is also the way agile projects are supposed to work (but often don’t). Aim small, shoot often, re-adjust each time. You need to influence the culture of your project so that it’s ok to make mistakes, and to make them often. A development model that allows lots and lots of cheap mistakes is far superior to one that tries to achieve perfection at every step, and thus makes each mistake very costly.

My own projects have fallen into this trap regularly, so I think it’s not an easy one to avoid. In the contagious enthusiasm of having built something that users love it’s easy to fall into the perfectionist pattern and decide that because the users like the system now, we need to ensure that they like every single release of the system. This even applies to other things than products. It takes a lot of discipline to fight that behaviour and say something that may well resonate, to your coworkers, as “let’s build crap”, but in fact means “let’s just release something quickly, no matter how bad it may seem, and see what the users think”.

But if you want your product to succeed, it must be done.