The idea when creating a new product is to have the minimum number of features that can still attract and retain users. In Lean Startup parlance this is called Minimum Viable Product (MVP). I pay attention to this movement. I follow a number of bloggers and authors that talk about it, including Steve Blank, Eric Ries and Andrew Chen. I have also played around with a number of Lean Startup models and ideas, fitting those ideas into my experiences.
Build a minimum viable product, gather input and feedback, iterate quickly.
There’s a lot of good stuff in this movement but one that has gone off the rails is that a releasable minimum viable products must be built quickly. It seems that when I read about a new idea it is often accompanied with “look what I did in a weekend” or “it only took us a month to MVP.”
I want to point out that there is no connection between speed and minimum viable product. Some MVPs might take a few days to build; others could take years. The point is to build something that you can start showing to people as quickly as possible. In other words, the focus here is on — as Steve Blank would say — getting out of the building and in front of customers, long before you are comfortable with your product and ready to release.
We have been working on our new product for over a year and a half. That’s a long time. But I started talking to people within two months of the initial idea. And we had coded a basic version we used internally in a few weeks. None of this was ready for primetime, none ready for release. I wouldn’t call any of this a minimum viable product. But we focused on the core of the product, built something we can show off, and got out of the building.
That process — getting out of the building — has had a huge impact. Not only has it helped us refine the product itself but the process of explaining it to others has helped us refine the messaging and use cases as well. As we move toward a shipping product, I know it wouldn’t be the same if not for this process.
I totally agree – but I think the speed part is a response to over analysis, too much upfront design and “oh my gawd we don’t want a black eye if we screw this up”.
In bigco land those three things are rampant …any opportunity to get something of the building (i.e. positioning the mvp and agile dev process) makes us froth at the mouth 🙂