As entrepreneurs, we often sweat about what the first version of our product should look like. We all want it to be so beautiful and highly functional that users fall in love with it instantly. However, many founders have fallen into the trap of building and iterating till no end in search of that elusive perfect product state before ever releasing it to actual users.
The core philosophy behind the quote by Reid Hoffman is that the sooner we can validate our assumptions and gain more understanding about how our users react to our product, the better. It reflects the “Release Often and Iterate Fast” mantra increasingly followed by many in the entrepreneurial community. There is an immense risk in spending time and money in building product features that don’t solve the core problem that you are you trying to solve for your users, or worse end up turning away your users because you released a bloated product. If a startup is successful, no one will remember how your product looked the day you launched. And if it doesn’t become successful, well then it doesn’t really matter. Think about this, how many launches of successful startups do you remember?
Below are examples of two of the most successful consumer internet startups in the world — Twitter and LinkedIn, and how their product looked when they launched. Their product design did not really set the house on fire but what it did do was allow them to launch early, gain valuable feedback from their early users and accordingly iterate into hugely successful products.
It is very important to remember that releasing early does not automatically mean releasing a buggy product. The reason to launch early is for you to validate your core assumptions with your users and basis that take the decision whether to continue down the same path or take a slightly different one. For this to be true, it is very important that your users are able to understand your core value proposition and derive value from the product you have released. Remember you are launching a “Minimum Viable Product” and not just a minimum product.
For us at UpGrad, it was important to test how students interact with the platform, how effective is the learning experience, what should be the process of content development, how do we structure our support team. We very quickly realized that it would take us a long time to build our student platform from scratch which supports the learning experience we were designing (engaging content, peer collaboration, active and regular interaction of students with the platform etc.). So rather than wait to build the entire platform in-house, we decided to launch our first program ealry using a third party platform, while regularly building and plugging elements that we assumed would drive engagement. Sure the user experience on the third party platform was nowhere close to perfect, but it has given us valuable learning as to what drives and does not drive students to engage with our product, and we will be using all this learning while building our own platform for the next set of programs.
It is easy to say but it is a lot harder to actually put this into practice — to release a product that may be in your eyes raw or ugly. When you have a big vision and it has only been partially translated into a product, you would inherently be afraid to show it to users. But by waiting to have a better product before you show it to anyone, you can seriously compromise the intelligence you can gain and the early traction you can build. You will be surprised how often users don’t mind a minimum viable version of your product and look beyond the initial flaws and understand the broader problem your product is trying to solve.
