The Minimally Viable Feature Approach "Product people - Product managers, product designers, UX designers, UX researchers, Business analysts, developers, makers & entrepreneurs August 08 2013 True Agile, Feature, Minimally Viable Feature, Mvf, Product Management Best Practices, Mind the Product Mind the Product Ltd 415 Product Management 1.66

The Minimally Viable Feature Approach

BY ON

1703103-photo-of-an-electrical-switch--science-experiment--educational-relatedMinimally Viable Feature approach (MVF) is creating enough of the feature to test the adoption and usefulness before expending lots of resources on fully building out the feature. In the case of ProdPad, we created the simplest form of the roadmap we could, with just enough functionality to be useful and yet provide users with a good sense of what the roadmap did.

The roadmap design in ProdPad was such a radical departure from traditional roadmaps that we had no idea whether it would a) work and b) be accepted by users. If we spent lots of time building out a roadmap that then tanked, it was time and effort we couldn’t replace – a killer in a bootstrapped startup. So we went with the minimally viable feature or MVF approach.

We learnt a lot about the roadmap and this has fed into the recent updates to it – all for half a day’s original development.

Why use the MVF approach?

MVFs are particularly useful for products that have moved out of the MVP or minimally viable product stage. Once you reach that point, people start thinking in terms of fully realised features as they plan. These fully realised features will often take significant amount of resources and time to develop and deliver.

Using the MVF approach means you can test before you devote resources to further developing the feature. It allows you to learn as quickly as possible as cheaply as possible.

But will they even use it?

Even if you have half your users asking for a feature it doesn’t necessarily mean they will actually use the feature. What people say they will do is often radically different from what they actually do.

MVFs are a great way of continuing learning as quickly and cheaply as possible, even in mature products. Once a feature shows traction, then you need to double down on that feature and build it out to nurture that traction and realise the value the feature brings to the product. I’ve seen situations where a company didn’t focus effort on a MVF that had a lot of traction, which meant the company failed to capitalise on that traction to create a more valuable product.

When building a new feature, build as little as possible to prove that the users will actually use it.  Get their feedback on what works and what doesn’t, and put that to good use in building out your feature into a fully-fledged facet of your product.