Scott Watermasysk Husband, Father, and KickoffLabs co-founder. Interests: basketball, bootstrapping, keyboards, training, and Building new things

My Definition of an MVP


MVP (minimum viable product) is certainly open to interpretation. When done right, it can be valuable tool to help you understand your market and justify continuing to down your current path.

Too much focus on MVPs is on the product and experience. Far too little focus is on will someone actually hand over the cash (saying you would pay is not the same as you will pay).

So without further ado, here is my definition of an MVP:

The smallest thing that solves a customer problem enough that they are actually willing to pay for it....and you take the money.

Your customers need to use the product. Telling them about it and getting feedback does not hold up. It is the experience. The joy (in use and time saved). The feeling of a product that really matters. This cannot be faked.

Does this mean you can't build an MVP in a weekend? Maybe...but it really depends on the product (and your skills).

Looking back at 7 years or so of KickoffLabs, the best thing we did was not only ship quickly (about ~3 months or so of development), but we also enabled customers to pay us for the service on day one. This enabled us to prioritize all the feedback we were receiving.

What about really large complex apps? Enterprise apps?

In my heart of hearts, I still believe that if you can break this down to something small your (enterprise) customers can use you will be much better off. However, I get that there are classes of apps that do not fit this model. Rob and Mike on StartUps For the Rest of Us recently had a great discussion finding product market fit for an enterprise product. If this sounds like your product, it might be worth taking this approach...and it is certainly worth the listen.