There’s a diagram doing the rounds that demonstrates what a Minimum Viable Product (MVP) is (and isn’t). It shows that a MVP shouldn’t be just about functionality but also about reliability, usability and user experience. Building a MVP is one of the first steps after which you have to measure, learn and iterate. However, just getting to an MVP can be difficult and how you do it can affect ongoing development.
The diagram is a clever way of showing what’s sometimes hidden when first thinking about a new product. It digs deeper into the what side of a MVP. i.e. What the product should be. I have found that, in practice, creating a MVP is a delicate balance because it not only concerns what but also how these things are implemented.
I have seen my clients’ MVPs (server-side and apps) scrapped and started again and I have also seen them used as the basis for further iterations. I have seen large amounts of effort on over-thought through, over-generalised and over-tested MVPs be dropped. Conversely I have seen under-thought through, under-designed, under-tested MVPs with lots of technical debt become the basis of future development. Perversely, the flexibility of the latter approach seems to foster more success and these are the projects that then end up having to build on sand. So, also think how (well) as well as what.