Minimum. Viable. Product.

I’m working through some Coursera content on Product Management by Alex Cowan, and I have some fundamental differences of opinion. In this segment, I share my perspective on what makes a Minimum Viable Product, or MVP, and relate why Alex’s rendition of an MVP is rather a Proof of Concept, or POC.

An MVP is a Minimum Viable Product. Let’s start from the end. It’s a product. It’s something with functionality and likely features. This thing may be physical or virtual, analogue or digital, and it may feasibly be a service, so don’t get hung up on the notion of product. Most people don’t have difficulty in understanding the ‘product’ aspect of MVP, except where the product is digital content or data.

---

» EDIT 20 May 2021: I recommend reading, Making Sense of MVP, an article articulating the concept of MVP by Henrik Kniberg, which was shared by a trusted colleague.

---

Keep in mind that a product may be an entire product, or it may be an extension of an existing product. Even a larger feature set can be considered as a product, and taking an MVP approach to exploring and releasing it may make sense.

The V in MVP is for Viable.

The V in MVP is for Viable. It’s not enough to have a product if it serves no purpose — Rube Goldberg notwithstanding. What makes this product viable? Why would someone be interested in this product? It doesn’t need to be a product you are selling or marketing. Perhaps it’s a feature set for an internal audience. One still needs to consider viability.

I could conceive of a digital clock as a product that outputs random times. This might qualify as a product, but the viability is suspect.

M, for Minimum, is the final aspect of MVP. We’ve got a product, and that product is viable, but the value of an MVP approach is to release the least amount as we can to realise value sooner and not over-invest in a product that is not well-received. The goal is to not over-architect and develop a product where many of the features aren’t being used. We can assess adoption and satisfaction in batches.

M [is] for Minimum.

This next part is important and is a place where Alex and I apparently disagree. An MVP is a core and hopefully extensible product. Whilst we both agree that this is exploratory, it is not throwaway work. If our MVP is adopted, it is a foundation from which to extend. The big miss in Alex’s proposal is the V.

With MVP, the product needs to be viable. Not the concept — the product.

If we are just trying to determine interest, capture feedback, and better understand the customer, this would be a Proof of Concept — perhaps even an interactive prototype. If we are building an MVP, we are using live data in a production environment with real users or customers. We may limit access or employ it as part of an A|B test, but it’s a real product with a minimally viable feature set.

In place, we want to capture enough feedback to understand whether to persist, pivot, or perish. The happy path is to persist. The product is well-received, and we can make a further decision to expand or extend. Good job.

We may learn that the product is generally OK, but something is not quite right, but we can tweak. Perhaps, we’ve learnt that people didn’t quite want thing X, but with a few amendments, we could repurpose it for thing Y. It wasn’t the homerun we were hoping for, but we’ve reached base, so we can see what the next batter can do to drive us home.

Or we might perish the product. Our formulated hypothesis was wrong. The use case we assumed to be there, simply wasn’t. No one wants our randomised clock. Let’s quit while we’re ahead. Now we can refocus and expend our energy elsewhere.

To be fair to Alex, I understand his sentiment. He is trying to avoid an endowment effect — a cognitive bias, where once a person has something, they feel a sense of ownership and assign value to it. Translated, this means that even if the product isn’t successful, some people — I’m talking about product managers and development team resources — will still retain some nostalgic appeal. Some people may still fondly recollect their Edsels and Yugos. Alex’s sentiment notwithstanding, if you aren’t testing a developed product — not necessarily fully developed — in a real environment with real customers, prospects, or end-users, your feedback may be biased.

I don’t disagree with Alex that a Proof of Concept is a good idea to attract feedback response, but let’s not call it an MVP— what Alex terms a concierge product — and not a POC.

In closing, I offer an unsolicited, unpaid endorsement for Coursera and Alex’s course material. Whether you already operate in the Product Management or Product Owner space, are looking to get into it, or just interact with people in it, I recommend checking it out.

And check out the next segment, where the topic is responding to reasons why MVP is not for everyone.