The concept of Minimal Viable Feature (MVF) is a significant milestone in product development. Release something that you think solve a problem and listen for the feedback. While the concept itself is great, the devil is in the details. In general, it is quite hard to learn how to define MVF. It is an art, not a science. In this article I will share my experience and some patterns I learned.

#1 Cut. The. Scope.

The most common mistake in MVF definition is bloated scope. There is always a desire to put one more thing into the feature and make it more useful and more appealing to the end user. No Product Owner can resist this intention and in almost every single feature I lead I added some unplanned user stories. In fact there is nothing bad with this approach, you discover new information and change plans. However, there is a real danger to push feature beyond MVF and delay its release. 9 months feature? We had it in our company.

Now we have a 3-months rule for every MVF. There should be serious reasons to spend more than 3 months on MVF implementation. MVF goal is to prove concepts and discover "unknowns", don't blow it to MMF.

#2 Feature kick start

Everybody should understand why we add this feature into a product. There is only one reason to add a new feature — it solves some important problem that quite many users face quite often. In the simplest case you have hundreds of requests that picture problem in bright colors and all you have to do is invent a solution. In a more complex case users don't fully understand the problem and throw out various solutions that in fact don't solve this particular problem. Only experience and system-level thinking can help to spot such cases. In the worst case you have no feedback and rely on your intuition to define the problem. This is a dangerous practice that can lead to extreme results: genius insights or total fuck-ups.

On a Feature Kick Start meetings we have people from marketing, development, testing, design and sales. All bring valuable information about various facets of the problem.

These meetings have several goals:

Clearly define the problem we solve. Define a scope of MVF. Decide what we don't know and what feedback we will accumulate now and after MVF release. Bring development team and sales people to a common understanding about the feature.

#3 Huge upfront UX is bad

We tend to have UX and Development as a completely separate activities. Sometimes we spent months on a feature UX, built prototypes, tested them and then boom... priorities changed and feature is no longer needed so much. Almost all the time we spent was just a waste. Let's say we get back to the feature next year, but now we have new information and UX we did a year ago is obsolete now, so we have to start over again.

Now we start UX when feature is actually starts. It means Feature Team almost completed previous feature, so it has some spare time to dig into the new feature and discuss its design, flows, etc. It may happen that developers don't do much for some time, since UX is not ready. However, there are often many things they can do: fix some old bugs in background, prototype new feature, try some technical and architectural ideas, implement something we 100% certain about. So while in theory it looks like you are not "utilising 100% of resources capacity", in practice single-feature flow for a Feature Team shortens cycle time and reduced waste activities.

#4 MMF is inevitable

Usually MVF solves a part of a problem and some cases are missing. Usually the solution itself is not the best. In most cases MVF is not a "complete" feature and you should finalize it. We call this finalization Minimal Marketable Feature (MMF). At this point feature provides a complete solution to a problem, the solution itself is beautifully designed, it is on par or outperform similar solutions in competitive products.

It may happen that new feedback will reveal that MMF is still not enough, so then you can iterate and release as many improved features as you need. This process is not formalized in our company.

#5 Real feedback is slow

We hoped to have 2-3 weeks delay between MVF and MMF and we thought it will be enough to accumulate enough feedback. We wanted to have process like that:

However, in most cases it takes 2-4 months to generate good amount of relevant feedback. It takes time to accumulate and reveal common patterns. For example, we re-designed navigation and allowed users to create their own Groups and Views inside these Groups (BTW, it was the case when we throw out UX done 9 months before feature start). It took us 5 months to actually understand what mistakes were made and what problems most companies have with this new flexible navigation. It appeared, the navigation was too flexible, so now we are reducing this flexibility and add some restrictions.

We changed the process and now we plan for 3 months delay between MVF and MMF. This gap is used by another MVF, so on a high level we release first minimal feature, that release second minimal feature and then based on generated feedback we complete both features.

#6 Real feedback comes from real usage

Don't get me wrong, I'm not against prototypes, wireframes sharing, surveys, etc. However, my experience showed that the only way to get a really relevant feedback is to release something in a product. All other ways of feedback generation are flawed. Real users bring so many unexpected and interesting insights.

When we started UX process adoption on our company 6 years ago, we tried almost any possible way of feedback gathering. We created several solutions to a single problem and run usability tests, ran surveys, interviewed customers, ran UX groups and shared concepts and ideas. We still use most of the methods from time to time, but our current approach is extremely lightweight and balanced. In general, we build light prototypes only when we just can't select a solution from two options (50/50 votes inside our team). We never build full interactive prototypes that replicates future system behavior, but just share sketches and main concepts. With right questions asked this simple method allow us to get a very nice preliminary feedback.

TL;DR