Building an MVP, the ‘Fake Door’ way

Image credit: niserin / 123RF Stock Photo

Considering the amount of digital ink spilled to explain it, we are all familiar with the term MVP. Minimum Viable Product (or Minimum Lovable Product, as Henrik suggests) is the smallest product that brings value to our users, lets us validate our initial assumptions, and adopt for the future. An MVP should be small and delivered relatively quickly so that we won’t lose too much time and money in case we fail to validate our assumptions.

It is all very nice in theory, but in reality, building an MVP still requires time, effort, and usually R&D resources. Small as it can be, we don’t want to waste our efforts on a false assumption.

In this post, I want to describe another way to answer the most important question before we start building an MVP :  Do people really want our product/feature? This concept is called a “Fake Door,” which is an MVP before the (real) MVP.

MVPs, the usual way

For the sake of this post, let’s say that we have created a wonderful app, which our users love. Everything is great, but the app is absolutely free, and we are getting hungry. It is time to make our users pay for some of the new advanced features.

How do we start?

1. Choose the single premium track , which means there’s  no need to introduce different tracks with different features and prices from the beginning
2. Decide on the payment option that is easier to implement, whether  one-time, monthly, or yearly
3. Integrate PayPal as a single payment processor , as  we don’t want to support different payment solutions from the beginning
4. Build a premium features page, where we introduce the track and the ability to start paying for it
5. Build a permissions system that will allow specific features for paying users only
6. Create a few advanced features for the premium track
7. Send an email to all users and tell them about the new premium track

This is our MVP. They are the minimum requirements that we’ll evolve over time, and should be enough for the beginning. After we build and deliver it, we’ll measure, learn, and adopt. So, after approximately a week or two, we’ll be live and running. Lean startup by the book!

Are those really the minimum requirements?

Sounds that way, right? All the above items are essential for the MVP and for us to start learning, right?

Wrong! Let’s say we build the MVP. Then, we wait. We wait for a day, two, three, a week, and guess what? Not a single user decided to pay. This entire MVP relies on a single assumption that we can only validate after the entire MVP is ready :  Are users willing to pay for our product?

Why do we need to integrate PayPal if the users are not interested in our premium features? Should we build the permission system before we validate this assumption? Probably not.

With that in mind, let’s examine another way to build our MVP, and this time, let’s use a real-life example.

MVPs, the “Fake Door” way

Buffer started with a free version of their product, and after a while, decided to introduce premium paid tracks. However, instead of developing all the “minimum requirements” from the start, they decided to validate their assumptions one by one without actually delivering value to users. They moved using the smallest possible test at a time.