MVPs, or Minimum Viable Products are great. The trouble is most entrepreneurs over complicate them. They focus on solutions and not problems. That may be great if you have enough data. Many times you don’t. You need some sort of product in order to get data to improve. Hence the stupidly simple MVP. The stupidly simple MVP is the absolute least amount of work that you need to do to prove your product-market fit.
There are some rules.
- No Code
- No Software
- Pen and paper
- Real people
Part of the attraction of being an entrepreneur is the desire to build things. Building is far more important than anything else. Once you have a good plot of land, it’s in the right place, its got customers, you have design and the foundations are in place. If you don’t have those in order then the building becomes a lot more stressful than it has to be. It really sucks when you have gaps between your walls, or the door frame is a metre wider than the door.
The stupidly simple MVP helps with this problem. It gives the entrepreneur something to build but it keeps him away from flights of fantasy and grounded firmly in the real world. Simply put he has to build a product that can work with pen, paper and a phone.
These aren’t arbitrary constraints. Software is a set of algorithms. An algorithm is a recipe, a set of instructions. A lot of those instructions are to provide features that are not vital to the essential purpose of the process. For example if you are coding for a questionnaire you only need to code for the ‘submit’ button because you are using software to run the algorithm. It only has value to the programmer, not to the functioning of the programme. It’s a layer of totally unnecessary complexity.
Pen, paper and phone (P3) forces us to focus on the critical aspects of what we are trying to achieve. In most cases that is how do we gather information from the customer, act on it and then pass information back to the customer. For physical products we may need to add a loop so we have
- Get information from customer
- Act on it
- Send physical product to customer
- Send information to customer (the physical product could be the information)
Right away you have a stupidly simple MVP of a retail store. This you can then start modelling, role playing, with the team, to understand interactions. With a few iterations you can start offering this to the customer and making sales.
I was running through with with a mentee recently. He was doing an Uber for X type of business and fretting about coding the app and project managing it. Within 15 minutes we had developed a stupidly simple MVP that he was able to start testing in hours.
It went something like this
- Stand in front of mall and talk to people (modelling marketing)
- Ask for phone number (signup)
- Send out regular whatsapp blast (engagement)
- Act on incoming message (app automation)
- Send out information that they require (vendor-supplier matching)
That destroyed a shed load of assumptions, unearthed some new information that changed the app design significantly and most importantly got them their first few thousand customers. The day after they did this they also got some great attention from an investor. No deal, just credibility because they knew they had something that they could monetise – with cold hard data – even before they had built anything.
Is this stupidly simple MVP too stupidly simple? The product is chucked out before even being built. There are two objections.
First the product is too X to have this treatment. To me this is a red flag. That screams
I know what the solution is and I cannot see any other way that this product can be built so help me God!
It is a failure of imagination. If you cannot cut all the extraneous detail away from your idea and see how to test it in its most basic form, a stupidly simple MVP, then you do not understand your business model.
The second is that it is too simplified. You cannot learn something without building something. This misses the whole point of entrepreneurship. The point is to solve a problem. More specifically the point is to solve a problem in the simplest and least expensive way possible. The earlier and simpler your tests the faster the development process is. You save vast amount of money and time.
Almost every startup that have worked with (in the thousands now) that has built a product early has failed or had a much harder path than necessary. Almost every entrepreneur who has used the stupidly simple MVP and done something in the real world, consciously or unconsciously, has had a much easier path.
Simplicity is the route to insight. A stupidly simple MVP makes it f****ing obvious that you have a problem. It makes it clear that you cannot blame the problem on the code or the software. It makes it clear that you have a problem with your business model. That is priceless.
Let me know how your stupidly simple MVP worked in the comments below and feel free to ask me any questions
