Minimum Viable Product: Build, Measure, Repeat

Most 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.

❡