The last %
Drawing the line between the shippable and unshippable
Starting new projects has always been easy for me. Since I began programming, I’ve always been creating both to have fun and to learn. That’s how I get better. I take a lot of pleasure designing and programming the beginnings of new projects.
During prototyping, I try to make a decision of whether to continue or drop the project as soon as I can. Only a few of them ever go beyond the prototype stage and when they do, my goal is to ship them sooner rather than later.
When the project is at the usable stage and is somewhat polished already, I show it to some friends to get some feedback. They usually ask me when it’s going to be released and what’s left to do. At first, it’s evident that things are broken and I just tell them that but after a while, I tend to babble something along the lines of: “There’s this feature I would like to have but other than that, it’s mostly done”. That’s always a pretty unambiguous sign that it’s ready to ship and I’m holding it back for the wrong reasons.
Polishing is the extra step that will transform good into great. It is an enormous part of any project and one of the most important ones, but it is also a process that is hard to stop once started. Saying no to the next feature or deciding to push back some incremental improvement to the second version is difficult. It is really scary to know — before you release it — that your creation can be better. I have many projects stuck in limbo at this stage; a stage that I call: the last percent.
Every pixel, algorithm, and animation should be as perfect as they can be, but nothing really is ever perfect, is it? There will always be something to enhance or to add, however minor. The last percent never ends because you will always find something to improve. I’m also scared of shipping because I’m scared of failure. Failure that, I find myself thinking, could maybe be avoided if I just continue to improve this last aspect first.
Releasing your product into the wild is great for various reasons though. It will get you feedback from users so you can focus on the right segments to perfect instead of blindly guessing what’s useful and what’s not. And yet, releasing will also bring you a feeling of satisfaction that comes from people using your product. Trust me, the adrenaline you’ll get will help your productivity.
It’s really hard to define when a product is ready. You might have changed the feature set because of your beta testers or from your own use. If these changes don’t make your product two times better, you should probably delay them.
I’m not saying you should not fix all the bugs and all the details that make you unhappy. Just ignore that little pixel that looks different on a five-year-old browser. Try to limit the feature-set and table the features that don’t make your product better than the current competition. If the feature you want to add doesn’t improve your product by a great margin, you should probably shelve it until after its initial release.
If you need to think too much while answering why your product is not released yet, there’s not much to be done anymore. You should probably ship it. From now on, that’s what I’m going to try to do and you all can help hold me to it.
