Minimum Viable Product: Build, Measure, Repeat

By Spicer Matthews

Minimum Viable Product: Build, Measure, RepeatMost people building software these days have heard of the Minimum Viable Product (MVP) strategy: construct only what is necessary to get a few users onboard and worry about the rest of the planned features later. The problem is, most of us suck at figuring out just how much is enough for a product to be minimally viable. As a result, we often times err on the side of too much. Cloudmanic Labs has launched a variety of products, and I like to think we are pretty good at gauging an MVP feature list. So recently I sat down and looked at the numbers to see how accurate we were at building an MVP release of Photomanic, our photo application for Evernote launched about a month ago.

We measure the usage of all features, which helps us determine whether we should invest more in a feature or not. One feature I insisted on was the ability to rotate images. I was convinced that without this feature users would not consider Photomanic viable. As it turns out, only 0.84% of the images uploaded to date have been rotated. Yet this feature is the one our development team spent the most time building—and one for which we generated a laundry list of upgrade ideas. Even I rarely rotate images, and I was the biggest proponent of the feature. Clearly, our perceptions of what is important are not always accurate.

Fortunately, we at Cloudmanic Labs believe in power of metrics. Had we not observed this result early on we might have unwisely invested more time in improving this feature. The data clearly suggest that we should dedicate our future resources elsewhere.

Still, the lesson here is to build very little and then measure. Figure out what is important and then direct your efforts based on data instead of shooting from the hip. Build what customers actually want, not what you think they want.