- Insights This article was written by a TIA community member. Insights pieces undergo the same rigorous editorial process that newsroom-produced articles have.
Real MVPs vs what everyone calls an MVP

Photo credit: Pixabay.
We keep using the term MVP in the wrong way.
There have been a lot of debates, articles, and information about what should be called an MVP (I even introduced “MVE” for experiments). But I want to focus on a particular misuse I see in most companies, especially when the term is mentioned by a non-product person.
What most companies do:
- Define a potential project/feature
- Start talking about it, defining it some more, and getting a more detailed idea of what is expected
- By the time they want to start working on the project, they’ve all fallen in love with it and it becomes gargantuan
- So, some features are cut off and an “MVP” is released
That is certainly not an MVP.
In this sort of definition process, we are working toward a “Release 1” or sometimes what is called a Walking Skeleton.
To do an MVP, we need a hypothesis that we want to validate, and our focus should be on learning and iterating by developing and adding features.
Let me provide two examples.
Case 1: A catalog manager
As an ecommerce company, we were connected with many providers. We needed to show our customers which products were available for purchase. Without going too technical, we got products from our providers, along with the prices, availability details, product descriptions, images, etc.
We had this need for a product that would allow a commercial team to manipulate the product information (everything except price and availability) in order to make the descriptions, images, specifications, etc. more accurate and attractive for our customers.
So, the usual process came in: We identified the need and started discussing what we needed to do. Then, a lot of great ideas started coming up. We talked about things like adding videos, merging multiple descriptions from providers, and other things that should add value to the solution.
When the time came to actually build the tool, before going through a six-month construction process, we decided to proceed with just a few features, which were the more important ones. We worked on the tool for around one and a half months and called it the MVP.
That was it. There was no hypothesis. There was no way to measure the success of the project. There were no learning processes in place. We built it and moved on to the next thing.
And the question that I heard two months after the project was launched wasn’t “How much better are you selling now that you have the tool?” but “When are you going to be able to add videos?”
Case 2: Automatic pricing policy
Stay updated on the go with our mobile app.
Get latest insights with smoother, more personalized experience through TIA mobile app.






