Have you ever started a project, be it personal or professional, software or not, but it lost steam even before the first version? Or, if the project got to the finish line, you already hated it for taking too long and being much more demanding than expected? Asking for a friend.
In all seriousness, been there, tried that, more times than I care to admit. And I have seen it happen to other people as well. It is an unpleasant place to be with no great options: muddle through, reduce the scope, or even abandon the project.
It happens for many reasons, but if my experience is any indicator, the main one is that these projects are too complicated from the very beginning. They are trying to cover too much ground and implement too many features from the get-go. All the things you planned may be good and all, but they take time and effort delaying the moment the project sees the light of day and starts giving results.
Of course, agile practices and delivering in stages help, but it is not a panacea – projects still fall into this trap. To better fight the urge to overcomplicate I regularly use the question I first heard on the Tim Ferris Show:
What would this look like if it were easy?
This question is deceptively simple, but the illusion dissipates once you try answering it. In any undertaking it is very easy to begin from the place of complexity: “We need this, this and this. Oh, this is also a good idea." However, you can most likely start with only a few core things as if what you are trying to do were easy.
When applied this way the question “What would this look like if it were easy?" transforms into “What else can I remove without compromising the project?". It forces you to identify what is important, concentrating on the why of the project.
Again, it feels like a truism – do what is important and do not do what is not. Regardless, it is surprisingly difficult to adhere to. Time and time again I find myself fighting good ideas that are not important.
This question is so impactful because it moves you towards multiple good principles and practices:
-
It forces you to focus on what is the most important – the primordial idea that 80% of results come from 20% of efforts.
-
Reducing the scope of the project fights optimism bias: in the beginning, everything seems to be easy and fast to do. Under this impression, it is easy to overpromise and take too much responsibility. Complications will not make you wait for long. As somebody said:
When a project is 80% finished, there is only 80% left.
-
You get to the results faster. Less you need to do => faster you finish the project => sooner you start benefitting from it.
-
Faster product delivery also shortens the feedback loop: you will start getting real feedback and adjusting your course accordingly sooner.
-
YAGNI – You aren’t gonna need it – many good ideas do not pan out. While it is good to think ahead and prepare for the future, there is no free lunch – you spend time on what may turn out to be of little to no use.
-
If you ever get to what you postponed, you will know more about the real problem and have a better idea of how to solve it.
-
Less time you spend on secondary things, more time you have for the core activities/functionality (‘do fewer things but better’ idea) or for another project altogether.
-
You avoid premature optimization. Sometimes good enough is good enough, especially in the very beginning.
-
You hedge your bets: the project may flop and you can lose the time and resources you spent on it. Narrower project scope => smaller investment required => lesser the risk and easier it is to diversify it.
Sure, this approach requires much effort and discipline, plus you risk oversimplifying and missing crucial details important for the project’s success. But it is a necessary evil that can be reduced by customer development and planning. I would argue that a project is much more likely to fail because it was trying to achieve too much from the very beginning, than because it had cut out something crucial.
Some food for thought instead of a conclusion:
If you’re not embarrassed by the first version of your product, you’ve launched too late.
Everything should be made as simple as possible, but not simpler.
It seems that perfection is attained not when there is nothing more to add, but when there is nothing more to remove.