Fixing confusion with MVP
Half knowledge is a dangerous thing. Yeap that's true. Let's look into how this half-knowledge has destroyed the concepts of MVP.
With time we have misunderstood the concept of MVP in development.MVP stands for Minimum Viable Product. This was the culture that became trending from the book named the Lean Startup by ERIC RIES.
The very first thing that comes to my mind when talking about an MVP is, to how much extent a product must be built? Are we going to test it in the real market or getting ready for its alpha model? What are we trying to achieve with this MVP? If the goal is decided, is this ready to be shown to the customer?
Now here are the following points I consider when dealing with an MVP.
1. The product has only the features required by the customer
2. A good set of proof-of-concepts
3. Features based on the priority level
4. Most important an estimate to the time taken by each feature(through its hardly right at time…haha )
The above is also the most points I consider discussing with my team even when dealing with a new feature. Some feature takes a lot of time. If you don't have an estimate of the time taken and whether your team can deliver it in time, it becomes hard for the team to deliver that feature/product in time. This thereby leads to an increase in pressure among team members which results in reduced efficiency. This is one of the most common mistakes that I have noticed in my past experiences.
What's wrong with MVP these days?
MVP seems to be the most obvious solution when there are less time and money. Managers fail to set short terms goals well.
I have even seen managers say to developers “Just make it work first, then let's think about the quality later”. It really seemed an unfair deal to me. Thinking from the customer point of view, no one wants to compromise when it comes to quality. Showing an under-developed product is completely fine, but if it's a build-in hurry and makes no sense to the customer is a serious problem to deal with.
The developer seems to lose interest when there is a very short amount of time. A developer is prone to introduce bugs when dealing with a big feature and especially managers pressure to complete the app in a short time. Bugs are the most obvious thing while coding but why willingly throw a hammer at your own leg.
An app with so many bugs is worse as it doesn’t add any values to your product. Now there's another mistake managers do. They have misunderstood the testing. There are two kinds of testing, one that's done on the user side and the 2nd that occurs on the customer side to measure their feedback. And MVP deals with the 2nd one. I have seen many startups confusing with this aspect. I have had my friends who have there own startups committing the same mistake again and again.
ERIC RIES shows an example of the MVP. Zappos began with a tiny, simple product. Founder Nick Swinmurn's hypothesis was that customers were ready and willing to buy shoes online. To test it, he began by asking local shoe stores if he could take a picture of their inventory. In exchange for permission to take the picture, he would post the picture online and come back to the store to buy them at full price if the users buy it online. Simple !!! Yet effective.
Zappos was a simple product. It only answered one question initially i.e, is there sufficient demand for online purchases. Zappos spent most of its time interacting with its customer i.e, the build-measure-learn loop.
They started with a very simple idea. Their product was a simple one with the most effective solutions. Yet there was no compromise with the quality.
That's the point. Quality!!!
Getting new users into your app is an easy task. But to bring those users back is a tough task. That's only going to happen when your product seems to satisfy the customer's needs.
Yes, all features are important but still they can be divided into three parts i.e, the feature that your app should have(compulsory), the feature that adds additional value(an important one), the features that are a cherry on the cake(optional). But here are another common mistake managers do-while categorizing they push about 70% of tasks into the compulsory list.
MVP is very important
MVP proves to be the most important aspect when a startup is new in the market and is trying its best to prove its value to the community.
It's the best way to measure what works and what doesn’t. Helping the team to that their product will succeed or not in the nascent stage.
Everything is easily available in today's market. One doesn’t need a very big budget to start off with his/her idea. Build the MVP as a learning tool, and once you’ve learned what you need, scrap it.
We learn from our mistakes. But its always a good idea to learn from the failures. Remember smart work over hard work.
Here a link to the awesome book. It really helps to have good knowledge about MVP. But remember to complete the whole book ;).
If you like the blog, please do clap and show ur love by sharing it with your friends. What're your views on MVP, would love to know it. Comment it down in the comment section. Or else reach me out at LinkedIn.
