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.
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.
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 what we like to call visceral pain. This is a pain so acute for one or more customers that when the feature is delivered, they will immediately start using it.
Minimize investment - Just like in Lean where you aspire to prove critical assumptions with the least possible investment, you want to deliver an MVF with the minimal expenditure of resources and time. Some of our MVFs take a day or two; others a week or two. We have never allowed an MVF to go longer than two weeks.
Deliver real value to 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.
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 or beta quality product. An MVF must be delivered to a production-level of quality.
Start a feedback loop - The primary purpose of an MVF is to start a feedback loop that will allow you and 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 - Once you start an MVF, you must keep an ongoing dialog with customers using the feature as you iterate toward completion. Iterative development by itself will not ensure your success. The iterative development of an MVF must be able to adapt to respond to the feedback that comes from customers who have started to use the feature.
Don’t fragment during iteration - 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 - not fragmented.
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 repeat the iterative process until full delivery has been achieved. While you could expend the time / effort to deliver the full feature after an initial MVF, it substantially increases your risks of building something that does not matter.
Adjust longer range plans - 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.
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.