“MVP” has become an industry buzzword. It’s cool these days to build an MVP if you’re a startup. It’s cool to write a new feature as an MVP. It’s cool to call your new cookie recipee an MVP.

But is that a good idea?

First, I estimate that 95% of the time I hear the term “MVP”, it’s acutally being misused.

When Eric Reis, author of The Lean Startup, coined the term, he had this in mind:

The minimum viable product is that version of a new product which allows a team to collect the maximum amount of validated learning about customers with the least effort.

The MVP is a learning too. It’s intended for market validation. It’s designed to learn about your customers.

So do you need that?

How certain are you that the thing you want to build will solve a real problem? How certain are you that people will use it?

If you’re already highly certain that your product, service, or feature idea is a good one, and that your customers will use it, you probably don’t need an MVP.

If you’re setting up a Kubernetes cluster for internal use, you probably don’t need an MVP. You presumably have a good understanding of what problems it solves, and that your company needs to solve those problems. Doing a half-assed job and calling it an “MVP” isn’t serving anyone.

On the other hand, if you have a new idea for a new Kubernetes custom resource definition that can automatically order pizza for the Ops crew any time a deployment fails, you probably don’t have anything like a solid idea that people will pay for that. Investing in an MVP to prove the concept is probably a good idea.

In short, don’t assume you NEED an MVP, just because the misused buzzword is en vogue.

First determine what questions you need answered, then decide if an MVP is the right tool to answer those questions.