Finding the Minimum Viable Feature (MVF)

Minimum Viable Feature Feedback Loop
I like to think that if software development had Ten Commandments, the first would be: Thou shalt not build something that doesn’t matter. There is no more profound waste of talent and effort than to have engineers build software that doesn’t get used by customers, or add-value elsewhere in a product. Unfortunately it happens all the time in both small and large companies. The result is a lost opportunity, a reduction in market momentum, and usually disappointment from everyone involved.

My Early Mistakes

When I started CloudHealth, I drove a Lean process to build out my early Minimum Viable Product (MVP). I worked closely with each of my early customers to understand their feature needs, and developed solutions that delivered real value for the problems they wanted solved. I regularly would discuss a feature with a customer one day, deliver a minimum version of this feature the next, and then iterate the feature with the customer over the succeeding days until it was complete and fully functional.

But driving a Lean process in a company of one is easy. After I started hiring a team of engineers, I lost touch with what worked for me in the early phases of building the product, and made several First Commandment violations in the next few months. The worst example was a specific feature we can call “Manikin” for the purposes of this post. I gathered data from customers for this feature, defined requirements, and worked with one of our engineers as he delivered a solution that fully met the requirements over the next two months. When he was done, we rolled out the feature, announced it publicly, and made it a part of our sales process. There was only one problem: no customer then or now has ever used this feature.

These and other similar mistakes resulted in a process course correction that resulted in the adoption of the Minimum Viable Feature (MVF) as a cornerstone of our software development process. The basic concept works like this: each time we define a feature, our cross-functional team has an almost fanatical focus on identifying the minimum version of this feature we can ship. While we still write the requirements for what we think will be the fully functional version of the feature, we flag the requirements we and our customers believe will provide a minimum feature. We then iteratively deliver this feature through a series of expanding MVFs until a full feature has been delivered.

Lessons Learned

Here are some of the lessons we’ve learned over the last year in driving MVFs:

  • Start with real pain - An MVF should start with visceral pain. This is a pain so acute that when the feature is delivered, target customers will immediately start using it.
  • Target a known subset of customers - A successful MVF does not have to meet the needs of all customers who have requested the feature. But it does need to provide real value that engages the interest of at least a known subset of the target customers.
  • Minimize initial investment - Just like Lean seeks to prove critical assumptions with the least possible investment, you should achieve your MVF with the minimal expenditure of resources and time. Some of our MVFs take a day or two; others a week or two. No MVF has ever gone longer than two weeks.
  • Deliver real value - While an MVF will have limited functionality, it should deliver real value to its target customers.
  • Production quality - Just because you aspire to deliver a minimum feature does not make it acceptable for it to appear or behave like an alpha product. An MVF must be delivered to production-quality.
  • Start a feedback loop - Once you deliver your initial MVF, you are starting a feedback that will allow the team to deliver a fully functional version of the feature over the coming days / weeks / months. If what you build does not result in feedback from customers within the first few days of delivery, it likely was a badly defined MVF.
  • Continuous customer engagement - Iterative development by itself will not ensure your success. The iterative development of an MVF must be responding to a steady stream of customer feedback from inside the feedback loop.
  • Stay focused - Each iteration of an MVF should successively build on the scaffolding of the previous iterations. The iterations should feel cohesive and directed to your customers.
  • Sustain the investment - Do not invest in an MFV if you are not willing to complete the full feature. A series of half-finished MVFs is worse than not doing them at all. For your customers to be willing to provide you feedback, they must trust that once you start a feedback loop, you will drive it to completion.
  • Follow the customer - I like to say: “We subsume all opinions at the altar of the customer.” By this I mean: it’s great to have a vision for where a feature will go, and important to have conviction around a feature or product - but when your conviction / opinions contradict customer feedback, you have the wrong convictions / opinions. More than once we set out with a clear vision of what we were building, only to find our customers steered us in an entirely different direction.
  • Rise & repeat - Once the feedback loop starts, you should repeat the iterative process until full delivery has been achieved. Iterative delivery of a feature through a series of releases built within a feedback loop will maximize success.
  • Adjust vision - As you iterate through an MVF, it almost always takes you on at least a few unplanned twists and turns. When the changes take you substantially from where you expected to go, it’s important to go back and adjust the vision to match the real-world.

Last Thoughts

Early in the company we had debates about functionality we thought was must-have to ship a feature. These debates were often associated with much passion. Sometimes our passion proved well-founded; other times it was not. Our near fanatical focus on the Minimum Viable Feature (MVF) though has allowed us to minimize the risk of our investments, maximize the leverage on our limited resources, and ensure we never again violate the First Commandment of software: building something that doesn’t matter.