Tired of ads? Enjoy an ad-free experience by signing up.
  • Insights
    This article was written by a TIA community member. Insights pieces undergo the same rigorous editorial process that newsroom-produced articles have.
Nacho Bassino · · 4 min read

Real MVPs vs what everyone calls an MVP

wireframe

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

Wrapping up

Stay ahead in Asia’s tech landscape

You've reached your 2 free content limit for the month. Sign up for free to read the full story.

🏄 For casual readers / 👶 Free

Basic

US$0

Free forever

Get instant access to this article and more every month

0 premium content

Unlimited news briefs

5

5 articles

Ad-free reading experience

Just US$0 per day

⌛Sign up in 20s. No payment details needed.

📖 For learners / 👍 Starter

Lite

US$4.92/month

Billed annually at US$59/year

Get instant access to this article and more every month

4

4 premium content

Unlimited news briefs & articles

Ad-free reading experience

Just US$0.17 per day

Cancel anytime

Our subscriber community includes professionals from these companies:

Stay updated on the go with our mobile app.

Get latest insights with smoother, more personalized experience through TIA mobile app.

Community Writer

Nacho Bassino

Head of product development at Almundo.com. Teaching and sharing all I know @LeanExperimentation.com. I'm specialist in product management and product discovery, with 14 years of experience in digital products.