To plan or not to plan

So there you are, getting started building an MVP for your new product. You have a pretty good shared vision of what you're trying to accomplish, and a rough outline of what your MVP must provide in order to validate some of your assumptions. Then you start thinking too much.

"Well I need to be ready in case the user does X". "What if Y happens? We need to built that in". "If the MVP takes off, this step will be too slow, we need to automate this".

And by the time you realize it, what should have been a quick and dirty MVP has turned into a major engineering challenge that must deal with a dozen fringe cases and automate a bunch of rarely used flows. Not only that, but you have spent valuable time planning for all this, when you could have spent your time doing more useful things like talking to your earlyvangelists or actually building the thing.

As for time spent planning, I always like to remember a rule from economics - the law of diminishing returns. This law states that "in all productive processes, adding more of one factor of production ... will at some point yield lower per-unit returns". In practice what this means is that there is an optimal amount of effort you should dedicate to planning. Any effort spent beyond this amount does not bring a proportional return in terms of added precision to your estimates or, more appropriately in this case, in reduced risk. In fact, the most benefit is brought by the initial efforts of planning, so when you are really time-constrained (ie, you have fast-moving competitors or are working on your startup in your spare time) you should do as little planning as you can possibly get away with.

Plans give you a false sense of security, in that once you plan something you feel like you know what will happen - and of course you never do. This does not mean you should not plan, but it does mean you should take plans for what they are: an estimate of how you imagine things will work out once you start actually doing them. And there's nothing like reality to mess up a perfectly good plan, so the less attached you are to your plans the quicker you'll realize when you should ignore them.