Why do so many startups delay launching their minimum viable product (MVP)? Believe it or not, the main reason – in my experience – is down to anxiety over its perceived lack of features, which leads to the biggest form of waste in any lean startup: over-engineering.
I know, crazy eh? Actually it would be mildly amusing if it were not tragic.
Even though most startup founders possess a plethora of information around and about Lean Startup methodology, they still manage to forget one of its key teachings. Which is? Eliminate waste of course.
And how can you NOT do this. We’ll let’s explore exactly that.
Failure to launch vs. being a Lean startup
Call it perfectionism or whatever you like, when it comes to finalizing and launching their MVP, more often than not, startup team leaders let their anxiety get to them. They fear that their MVP may not be “feature-rich” enough, or good enough. And the result is that they end up trying to pack too much into it. In short, they over-engineer and create features that they don’t even know are needed by the customer – yet.
Being an investor, a mentor or a coach, how can you help those people deal with this anxiety and effectively apply the principles of lean startup?
I assume that the science of psychology has a lot to say about confidence and determination on this. And I’m pretty sure that in the near future, investment teams will also count psychologists among them. At Starttech Ventures this is something we shall definitely do. But, before that addition to the team takes place, I think asking the following specific question can be very helpful:
“What can we not do?”
In other words, how can our product or MVP be minimized? Or how can the functionality be reduced, how can the website be simpler. Even better, how can the UI have fewer choices and how can the whole thing be easier for the user, for the developer, for everyone involved?
By and large, the answer for any startup will not be more, it will be less.
As described in Lean Startup, the MVP should only have functionality which facilitates the experiments necessary to run the “build-measure-learn” cycles. And in various agile research and reading material, one can find two very eye-opening phrases:
(a) Agile is about the art of maximizing the work not done, and,
(b) Agile promotes having barely sufficient documentation (likewise any other kind of process, tool or anything; use whatever is truly necessary and try to keep them barely sufficient).
When the struggle is real, do less
The moment then that you will meet with a startup team struggling to launch their MVP and promising themselves that they’ll do it “just after implementing X feature” or “immediately following the completion of Y integration”, do not doubt that they need help.
So what you should do is ask them: “What if we don’t do this? Will we still be able to learn something meaningful from the early adopters?” I truly believe that in the vast majority of cases or scenarios, the answer will be positive. And then, the right thing to do will be to skip a certain piece of extra work and move on with launching that MVP. This is what lean startup and product development efficiency is all about.
The moral of this story? Just do less. Or, perhaps, even less than that.
