Is Your “Minimum Viable Product” Really An MVP?
The most significant risk for early-stage startups is that you spend a lot of time, energy, and money building something that no one gives a sh*t about
Note: This article is for aspiring high-growth startup founders. Additionally, this advice is mostly intended for consumer startups and is probably less applicable to larger B2B or hardware startups.
Nearly every time I’m meeting with founders, the conversation goes something like this:
“I have this idea for (or have already built) product X — how do I raise money or build my app or patent my idea? And do you like my idea?”
My answer is almost always some variation of:
“I wouldn’t worry about raising money, hiring a dev shop or other things. I would recommend thinking about your idea as a hypothesis and build something as quickly and cheaply to test that hypothesis.”
We’ll then often discuss ways to create experiments that hardly resemble their grandiose product vision. But the experiments help play an important role in testing key assumptions to move their idea or company forward.
Many of these founders, myself included at one point, have what I call the “I-Need-To-Build-It Disease”. They are so focused on building a fully-fledged product that they ignore key assumptions and waste lots of time and money in the process.
Common signs you or someone you know may have the disease
If you/they are:
Very focused on building a product that isn’t a Minimum Viable Product (MVP). A good rule of thumb is that an MVP should cost less than $100 and not take more than a weekend to build.
Looking to raise money before they have made any money.
Spend anything less than a majority of their time talking with or observing customers or potential customers.
Overly focused on administrative and planning tasks like financial forecasts, business plans, patents, incorporation, etc.
Overly focused on secrecy and are in ‘stealth mode’; widely use NDAs, or think they have ‘secret sauce’. There are good reasons to do these things in some cases, but often they are much more of a net negative than positive.
Love talking about the underlying technology for their business, but spend little time discussing the actual problem the solution solves for real people. This symptom is often the result of overly technical leadership. Don’t get me wrong, technical leadership is critical, but these companies can quickly become solutions looking for a problem. A great piece of advice from Grace Ng with the Lean Startup Machine:
“Every customer has a problem, every problem has a solution. But not every solution has a problem, and not every problem has a customer.”
These founders will have often spent tens of thousands of dollars and have worked on their idea for months either personally building an “MVP” or hiring a development shop to build an “MVP”. Interestingly, when we discuss the Lean Startup, many of them claim to have read it but seem to be doing the opposite of what it recommends. The author of The Lean Startup Eric Ries defines an MVP as:
“The minimum viable product is that version of a new product which allows a team to collect the maximum amount of validated learning about customers with the least effort.”
So how did we end up this way?
For me, I came very close to ending up in this trap — even after reading the Lean Startup and doing a Startup Weekend. I thought I needed to go straight to building my product and building it through custom development because my “MVP” needed to be a custom product.
I interviewed over a dozen developers and development shops and spent over a month working with a designer to create wireframes. I was enamored with creating this idea that I’d been dreaming about for months. It seemed to ‘make sense’ to build a product and the conversations with custom development shops — all seemed to point in the direction of building a custom MVP.
Then one day, I was on the phone interviewing yet another development shop. About 60-seconds into the call the sales rep from Toptal told me I was nowhere close to being ready for custom development.
Instead of selling me something I didn’t need or end the call, he took the time to explain how I should create a simple MVP. By linking a Google Form to a landing page, I could manually match suppliers in a spreadsheet. Boom! No coding required.
But at first, that was the exact opposite of what I wanted to hear. I mean calling people?! The whole purpose of my website was to avoid calling anyone! I had also spent time and money on wireframes and wanted to charge ahead and was upset he didn’t think I was ready yet. But in reality, he was right. I built a landing page with a button linked to a Google Form that weekend.
This experience was eye-opening and allowed me to learn valuable information about my customer’s preferences, build a list of initial customers and generate tens of thousands of dollars in GMV, a very tangible measure that the assumption was probably correct.
As an aside, I did go on to use Toptal several months later and the sales rep was amazed that I actually went out and did what he suggested. I was very happy with the developer I’ve worked with, but looking back, I think that even after waiting, I started on the custom development route sooner than I should have. If you’re thinking of going with a development shop, watch this.
How to get back on track
If your startup is crushing it, you’re probably not reading this. If you aren’t crushing it, below are some ideas to try and get back on track. I would also highly recommend reading or re-reading The Lean Startup, especially chapters 4–6.
A key point to highlight for this entire process, that the greatest risk for the vast majority of pre-product market fit startups is that you spend a lot of time, energy and money building something that no one gives a sh*t about, let alone, is willing to pay for.
This simply cannot be overstated and should be at the forefront of your mind as a founder — especially if you are pre product-market fit.
1. Re-state your idea as a hypothesis
Airbnb’s hypothesis would look like: “People want to book other people's homes and rooms online for vacation, and people are willing to rent out their homes and rooms.”
For a great video from the Lean Startup Machine on how to start this process and the relationship between assumptions and hypotheses, click here.
2. Identify assumptions that need to be true, for that hypothesis to be true
Identify some of the most important assumptions that needed to be true for the hypothesis to be correct. Grace describes assumptions as:
Assumptions: The action, behavior or mentality that the customer has to exhibit in order for the hypothesis to hold true.
Below are some examples of Airbnbs.
Travelers want to book peoples homes for lodging
Renters want to have strangers stay at their home and are willing to have the potential risk of their home and availability online
Travelers are willing to pay online and won’t cut a platform out
Enough of these people exist in the world that we could build a big business
Notice how they are relatively simple and seemingly obvious. However, it is the most simple and seemingly obvious assumptions that often doom the best-laid plans.
3. Develop experiments to test these assumptions
Next, we want to develop experiments to test those assumptions as fast and cheaply as possible. In a three-step process where you decide what you need to Learn to validate the assumption, decide what metrics could be Measured to validate that learning, and lastly what you would need to Build or do, to collect that data.
This process is often referred to as, “Build, Measure, Learn” with the key metric being the speed at which you can execute a rotation through the loop. The Build, Measure, Learn loop is very similar to the Observe, Orient, Decide, Act or “OODA” loop decision cycle coined by Air Force Fighter Pilot John Boyd by which an entity (either an individual or an organization) reacts to an event. According to the OODA loop, the key to victory is to be able to create situations wherein one can make appropriate decisions more quickly than one’s opponent.
A great starting point for initial assumption testing experiments are interviews with potential customers done in a way to test your assumptions. Some good rules of thumb are to avoid front-loading the solution and simply ask them about the current behaviors related to your idea and pain or frustration surrounding the issue that you’re trying to solve. Gain an appreciation for the nuances and strength of the pain.
Only after discussing the problem, then propose different solutions to that pain and feel out their openness to those ideas, what those solutions would need to look like and if they would be willing to pay for it. Attempt to gauge the degree to which they are an early-adopter as well and start seeing if they may be good to reach out to first with your initial MVP. Attempt to see how many other people like them are in the world and if there are other people locally, that are like them and maybe willing to talk with you.
I believe one of the most important things a founder does is know which assumptions to prioritize and then come up with cheap and quick experiments to test these hypotheses and know when enough data points have been collected to move on. Data is the latest hotness in business, so it is tempting to run these experiments longer than is necessary to simply have “more data points”. There is no right answer and only you as the founder will know, but generally, it will come down to — what are the costs of continuing to run the experiment? If I terminate it and make a decision, what is the gravity of that decision?
4. Using an MVP to begin testing the overall hypothesis
Now that you have tested your assumptions and learned more about your customers’ needs and who your customers are, it’s time to finally put together an MVP to begin testing your overall hypothesis. “Finally” maybe two days, two weeks or two months, it’s up to you.
As far as advice on building MVPs, there are several different types, and often multiple are used at the same time to get the desired effect.
Concierge: This method essentially replicates the user experience by manually doing what the service would do, typically via the founder's sweat equity. This method was popularized by Zappos when the founder simply took pictures of shoes in a shoe store and put them online, and then if someone bought them, he would then go to the store and buy the shoes and mail them to test the hypothesis that people were willing to buy shoes online. This is how I would mostly describe our first MVP.
Videos: This method attempts to replicate the experience through a video and was used by Dropbox which is a complex product, but they were able to simulate the experience quickly and easily. I would recommend the video having some follow on call to action such as signing up for a product-launch announcement or pre-order to see if people are really interested.
Tweak an existing product: Take an existing experience or product that is very similar to the experience you’re trying to create and tweak it to approximate your product. For my startup, I took an existing booking software (Calendly) and tweaked it to become a booking tool to test the hypothesis that suppliers were willing to have their space booked through an online experience and have their availability publicly known.
Simple prototypes: Using simple landing pages from Wix or Squarespace. For apps with more complexity, Bubble.is, Sharetribe, Glide, and the many other no-code solutions that exist, you can quickly and cheaply build MVPs to test your hypothesis. No code solutions are getting exponentially better every year, so just Google ‘no code app builders’ to see what the latest and greatest tools are.
The ultimate test of course for the MVP experiment is if people are willing to give you money.
The purpose of charging people at this stage has nothing to do with the money, but everything to do with the act of pulling out a wallet (or not) being the best forcing mechanism for fast and genuine feedback. A customer who isn’t willing to pay is your most valuable resource to either determine if they simply aren’t in your target market or to know what would need to change for them to buy it. Knowing when to start charging is difficult, as every product goes through an R&D phase of polishing it up, but on the flip side no product is ever ‘done’. So you have to be honest with yourself and figure out where that point is.
I think generally when you have a handful of customers using the product as intended, there aren’t reliability issues the customers notice and there aren’t glaring gaps in features — you’re well on your way to start charging customers. When you do start charging, keep in mind a $100 product that is 50% off is 10x easier to sell than a $50 product.
Check out this video from one of the Co-Founders of DoorDash explaining how they launched their MVP in less than an hour.
5. People are paying me, what’s next?
Great! There will come a time when you’ve learned, and people are paying you, and now it’s time to build the custom website or recruit a technical co-founder or raise money by doing a Kickstarter. But often this step should only come after sufficient hypothesis and assumption testing through experimentation and true MVPs.
It is reasonable to think as well this should be a one to two-week process, not a multi-month ordeal. Only you’ll know when that point is, but be honest with yourself and make sure you’re meeting with lots of other early-stage startup founders to keep you honest.