MVP Or Not To Be !

If you read my previous posts you probably noticed that I have a problem with developing products that are not based on REAL need and this NEED is strongly backed up by solid organizational data. Let’s say that you identified a need, you prepared a small business plan to make sure that you are not wasting your money for nothing (product without a basic business plan and an estimated ROI is a waste of money!) , how would you know what is the exact functionality that you need to develop in this feature? We all know that most of the times products are a collection of dozens (and sometimes even hundreds \ thousands) of small features and only small percentage of these features are ESSENTIAL to fulfil the need that you have identified.

A HUGE mistake that I see, especially with young startups is that they want to develop their vision in its full without understanding what is the set of features that are ESSENTIAL to achieve their general business goal. This is the reason why startups investors coined the term MVP – Minimum viable product. The point behind MVP is exactly what we have discussed above, to develop the exact set of features - not more and not less - that is essential to achieve the startups initial business goals. The thing that is standing behind this approach is modesty, an understanding that we don’t really know what will work and what won’t work and therefore we are developing only the necessary set of features. When we will collect more data, we will be able to decide what are the areas of the products that we would like to extend and what areas to leave as is because there is no financial benefit in developing them further. The MVP approach in startups is clear and well known but I would like to ask you what about MVF – Minimum viable feature, should you try to implement this approach also in your well-established 500+ employees organization? In these kinds of companies, the money is usually not a problem, no one will really notice if your development team developed 30%,40% or even 50% more than what you actually need to achieve the company business goals.

Are you as a product manager is even aware what are the business goals of your company? what are the business goals of the products that you are responsible to produce? (If you are not, I would strongly advise you to demand to have this ultra-important data. It will focus you and your team like a laser beam on the right product direction that you should pursue.) Assuming that you know what are the business goals that your new feature should achieve, you should carefully select all the functionality that Is a must in order to achieve this business goal - not more and not less -. Once your "thin" feature went to production wait for few weeks (or months, depends on the amount of traffic that you have) and open your organizational BI and check what is the usage of this feature. If users are using this feature, great, start investigating with the users what are the missing functionalities according to their opinion. Start diving deep into the data to discover what are the NEW needs that arose from this new feature and do the entire MVF process once again. If you checked the organization BI and you saw that the performance of this feature is less than what you have anticipated and it's not producing the ROI that it supposed to, it's time to "kill" it. If you are wondering why to kill it, please ask your QA manager and he will give you the answer right away :-).



Many times, when I’m consulting companies, I see deep trust issues between the product team and the development teams and between the product team and the stakeholders. One big ingredient of this trust issue is that the developers are seeing that they are investing a lot of time and efforts in features that no one is using. From the other side the stakeholders in the organization are constantly complaining that the output of the tech department is not big and fast enough. Yes, it’s not big and fast enough because the product team filled the development with “Full scale dream” features that no one will ever use. Implementing the MVF approach in your product team and even better in the stakeholders mindset will save the organization a lot of time and money , but we all know that this money is the less interesting part , the more interesting part is the amount of money that your organization will produce if it will build products step by step when each step is built on a solid success of the previous step. After all this is what MVF is all about.

57 views0 comments
Never Miss An  Update

Thanks for submitting!

Never Miss An  Update

Thanks for submitting!