I have been battling how MVP is used in the software industry for years. I have blogged about it, argued my case with clients and colleagues and in general been pretty dissatisfied with the results. My erstwhile CEO said, ‘Its what the industry think it is so give up and follow the pack’. I thought about it and decided, no, I am not giving up! An MVP can be created without writing a single line of code. If you don’t believe me read on!
Let me first put forward the position I was asked to accept. The Minimal Viable Product is widely accepted in the software industry as the first time the solution can be released with acceptable business value. Often, this is the only significant functional release and the MPV concept has been used to cut functionality from the original idea down into something that’s financially acceptable. I have seen this time and time again, where clients ask themselves what’s the smallest delivery that they can get away with.
I will be open and honest with you, I think that’s simply rubbish! I have no idea where that definition came from, but it’s not from Frank Robinson, Steve Blank, Eric Reis or any other MVP guru. Defining the smallest thing that we can get away with was being used well before MVP was ever invented. The MVP was never intended to be used this way! That first commercial release is an MMP or Minimal Marketable Product. It’s not the MVP!
So what is MVP then? It’s the smallest thing you can build to test or prove an assumption and gain validated learning. Its an experimentation tool that you use to get real customer feedback on assumptions that you have made. The important factor here is that you attempt to do this as early and as cheaply as possible. That’s way, way before you invest in production quality code of any form. Marty Cagan has even changed the definition of MVP to Minimum Viable Prototype to make sure that there is no confusion between an MVP and a real marketable product. Marty says you need prototyping to help resolve product discovery risk. This covers value risk, will anyone want it, usability risk, can people work out how to use it, feasibility risk, can we actually make it and business risk, will it fit into our corporate landscape. He says the MVP is just another type of prototype. This all sounds pretty sensible to me.
I have just completed an innovation course with Hyper Island, an industry renowned centre of excellence. They use the MVP label (but still use product over prototype) but have no misunderstanding, this gets used very early, when you haven’t invested in production quality at all. The use of MVP, as a concept, is fundamentally different from how I see it being used in the software industry.
So, are we prepared to build production-quality software that solves the wrong problem? Are we happy to plough ahead spending huge sums of money on projects underpinned by unvalidated assumptions? Are we prepared to predict what people want because we know better? Whether you like it or not, most organisations, and I do accept there are lots of exceptions, do exactly that!
So next time you are about to charge into a project and use Agile principles to build production- quality software from day one, with no idea of the answers to Marty Cagan’s product discovery risks, remember you have a friend in MVP. Build experiments with real users, use prototyping tools, validate your assumptions and build some confidence before you invest in expensive code. And don’t stop there! Keep experimenting with real users throughout the build process.
So the MVP is a powerful tool, as are all prototyping techniques. I challenge you to see if you can address that product risk before you invest in code. Ask yourself if you have to invest half or more of the project budget before you get users to validate those risks. I bet you the answer is no. Yes, you can build an MVP without a single line of code and that’s my challenge!