So far I have been a failed entrepreneur. I have built three SaaS based product prototypes which nobody has bought or shown any interest in.
The first product I built never saw the light of the day because while building it I got so overwhelmed by the amount of features and complexity that I had to abort it mid-way. The second one did come out of the coding juggernaut and was elevated to a hosted application but none of the early users could understand its functionality and workflow, hence we eventually scrapped it.
In between I got myself a copy of the Lean Startup book by Eric Ries and was fascinated by his research around the concept of MVP (Minimum Viable Product) and his approach of rapid prototyping to validate the value and growth proposition of a product idea.
Finally based on the wisdom gathered from the book and the lessons learned from the previous two failed endeavours we tried to build our third product and we eventually succeeded in showing and convincing the potential customers about its functionality and usability. But we made one more critical mistake and ultimately we had to scrap this idea too.
Based on my failed experiences in building MVPs, here are a set of pitfalls which I have identified as “must avoid” in order to be able to build a successful product or idea prototype.
#1 No clear demarcation between essential and non-essential features.
It is always tempting to think about the possibilities your idea or product can offer to the world. But realizing them takes a herculean design and coding effort which is not worth the time unless you know the viability of your idea at the first place. Hence before you embark upon building the MVP for that awesome idea of yours, have a very clear list of minimum features which will showcase the idea and can elicit an interest in the minds of the viewers about its value proposition.
#2 You are building an MVP for the last three months and its nowhere near completion.
An MVP which takes more than three months to develop is probably not an MVP. This is actually a consequence of the previous point. If you get swayed by the potential features of your product idea then you tend to have an ambitious plan to build those features, which takes time and is obviously impractical in the face of uncertainty of your product’s viability. I feel, in a way this is also the result of the big company syndrome. Those of us who have worked in large established companies would have worked in product development teams where the product release cycles are spread across many months or maybe quarters. But there are two key differences between a product developed in an large established company vis-à-vis a start-up. Firstly, the established company has a well established market and is aware of the potential demand. Secondly, it has far more resources to develop and churn out features in a big way.
In comparison, a start-up is always at a disadvantageous position hence it makes more sense to develop a product in a small way, by focusing on the minimum viability and in quick succession.
#3 You are using third party APIs and tools which you do not know.
This can be a real bone of contention while developing any software based product. The decision of whether to use an existing third party tool or develop your own can be time consuming. However I have found a general rule of thumb which has helped me to expedite this decision making. A third party API/tool can help you either in a specific way ( for example a 3D graphics library to assist in drawing 3D graphics objects ) or in a generic way ( example, an application framework ) . If the specific capability of the tool is something which you cannot live without then it makes sense to spend some time and effort to learn it. However, if you are planning to use a generic application framework which you do not know then it is better to avoid it. You can always create your own generic framework as per your need and evolve it later rather than wasting time in learning a new framework.
Another major pitfall of using unknown third party tools is that you have to adopt to their way of thinking which can cause you to deviate from your ideation track.
#4 You are paying too much importance to non-functional requirements.
Just like the non-essential features, we also tend to get bogged down by the non-functional requirements of our product such as scalability, reliability, input validation etc. At an MVP stage none of this matter more than proving the worthiness of your idea, hence you should avoid falling into the trap of trying to design your product to address these requirements. However, once your idea is proven and more and more users flock to use your application, you must address them and typically this results in a partial or complete refactoring. So be prepared for that.
#5 You haven’t planned to validate the MVP.
An MVP is an unproven product. And the thing which can prove it is not your assumptions and affirmations but its worthiness & acceptance in the minds of your potential users. Hence the single best way to prove it is to proliferate it in as many channels as you can possibly think of. The most immediate way of doing this is to showcase it to your friends, peers and acquaintances. Beyond this, the internet itself provides a much larger channel. So you must have a plan to promote it in such a way that you can accentuate the features of your MVP and expect to elicit some interest from the masses. And this planning should be ideally done before you complete the MVP.
#6 Bonus pitfall
The critical mistake we committed with our third product was that one part of this product offering was based on a mobile app for which we completely depended on an external app developer. And by doing so, the turnaround time for getting changes and fixes on the app became such an impediment that it could not elicit a continued interest in the minds of the potential users. Hence the moral of the story is “Never outsource the development of core components of your product”.
Ultimately, the success of your MVP depends more on the novelty it brings forth or the intensity of the problem it solves rather than avoiding the possible pitfalls listed above and beyond. So you, as the MVP creator must be upfront willing to learn and improve the various ways of bringing forth the value proposition of your MVP in whatever way possible. And for that you must be willing to risk a small amount of time and money to try it first. Without trial, there is no error and consequently no learning.
I am curious to know if any of you readers have faced similar pitfalls or have any experiences to share which can add to this list. If yes, the please provide your valuable opinion which can help the future entrepreneurs.