Temptations Against MVP And How to Avoid Them
Anil Bhat, the co-founder at FindYogi shares the mistakes they made in the course of their product development...
We knew we wanted to change that. We wanted to be quick in adopting new technology, more freedom to developers to make decisions, experiment etc. Nothing's bad in all this, just that we were trying these things at an early stage when we should have had just one goal – ship.
We started in early October and had couple of quick hires. Things looked positive as the team mix was good and we had atleast 1 person for each function. We got a little too ambitious and thought of making a “Good release” and not an MVP, as is always professed. That is where all the screw up started. From selecting frameworks that nobody had worked on to design considerations, everything was done considering scale.
Here are some mistakes we did and why you should avoid them:
- Trying to design build for scale in prototyping stage – We started with a decision of using some known frameworks and languages we knew well. For web development PHP is the first thing on your mind but we read heard about Facebook moving out of PHP for some of their features and believed PHP isn’t scalable (for Billion+ users), so let’s learn RoR. Similarly, MySQL vs. MongoDB. Django vs. Yii etc. We wasted a lot of time, when the matter of fact is that the thing we should be shipping could be done with some modifications on Wordpress.
- Documents are for big teams – We thought product docs are for large teams. This is how we divided the task.X will write the DB architecture.
- Y will explain the flow to designer and he will start designing. Then why Y can start creating some pre launch buzz.
- Z can start with basic coding and setup. When designer is done with home page (in about 2 days), Z can start coding the pages. Then Y can keep feeding Z and Z continues to build the user facing product.
- Meanwhile, X can work on data scouring and then optimizations like MemCache etc.
For once one might assume that such a product dev. plan will work, but then nobody had programmed the system. There is no common product flow that everyone is following, everyone is just coding. Not sitting idle? Moving forward? Yes, but without a clear destination.
3. Jumping to HTML without freezing Mockups – We started with a wireframe, the designer was tempted to show it to us mid-way, we got excited and then this was the conversation, “This looks good, I think you can start with HTML, the developers are waiting for your design, we need to release fast, we shouldn’t waste time in mock-ups etc.”
The engineer started coding, we see the HTML version for the first time and then “Abey b****, yeh kya banaya hai?”. Boom! “Scrap the whole thing and make it again, first freeze the wireframes end to end then start on HTML.”
4. “Lets table this discussion and move to next topic.” – One always starts a discussion when the default doesn’t work. During such conversations, we would hurdle up and start discussing, “option A or option B?”. Half informed opinions would flow in and then we would almost get into arguments. To avoid the argument we would stop the conversation and move to next top – “theek hai, isko baad mein discuss kartein hain.” Then that topic is never discussed until the dependencies start failing and we have to again start from scratch. If there is a decision to be made, don’t delay it.
5. Top down vs. Bottom up – When you build any product you can work individually on each component, optimize it and then integrate to build the whole piece. The other way is to assume the component is built, integrate it with dummy yet logical functions and then start working individually on each of them. Once done, you integrate and then start optimizing each of them. Top down is the way to go if you want to avoid release stage surprises.
While building a concrete structure you make a strong foundation and keep adding bricks and glasses on top of each other. It is great in a way but then you have little room for failure. A steep uphill to climb, one mistake and you start from bottom. But in software product development it’s more like hiking with pit stops. You climb little hills one after the other. Get to the top of one hill, analyse what you need for the next climb and then start. You should not be worried about the last hill when you still haven’t climbed the first one. This way even when you fall, you don’t go all the way down.
All this while we had a feeling that we were doing something wrong but since it is still happening to us, we know why it is so easy to get tempted to not build an MVP. The irony is that all 3 of us have had experience of making products from scratch and yet we did all these mistakes. Hope there are some signs that you can relate to and not fall in the same trap. Build the 1 feature product and release it. Everything else can follow. Period.
About the author:
Anil Bhat, co-founder of FindYogi – a product comparison engine. Anil till recently was working with Yahoo in their Homepage team, before joining Ankit and Naman.
