The Minimum Viable Product vs The Product

One element of my current role is designing and delivering different features into the business through a series of products. For various reasons I won't be going into too much detail into this, but enough to hopefully make the context relevant. The features are purposely designed around delivering a Minimum Viable Product (MVP) at each product release which generally translates to specific business benefits (which are used to justify the whole thing). The reasons for this are obvious to those working in an Agile world, but for those not: this allows the release of features which can be realised as benefits much quicker than waiting for a complete product with a full set of features. These features are designed around specific business benefits for maximum benefit vs. minimal effort. It also reduces the learning curve as you drip-feed new features which may require new ways of working each time. The business get a constant flow of new benefits and the team working on building the products get to focus on individual deliverables, which hopefully makes working on it more fun as you get regular feedback on the benefits you can deliver.

However!

This creates a problem when dealing with software products. If I choose a specific software product to deliver towards a specific set of features I want to release, I can't half deploy that product, I have to deploy the entire product in order to realise a handful of features. This isn’t necessarily unique to commercial products either, the same applies to open source (OSS) although generally is exacerbated by paying for the product and PS to install it.

Let me get more specific (BTW: you'd be wrong for sending me a message trying to sell me one of these solutions after reading this, or suggesting solutions to the problems I pose here! I'm not looking at these specific problems :-) )...

Let's say I need a storage solution (heresy: Chris Kranz buying storage!); actually what I want is a few TB of capacity delivered to my VMware hosts via NFS. I don't need (or care about) encryption, replication, FC, CIFS, RBAC, how you deliver N+2, and any other of the hundred features that may come with different storage solutions. However what I have to buy is 10's of TB with a dozen features I'll either never use, or not use in the next 12 months. This makes my MVP very expensive and also blows my delivery timeframes, I can't part configure a storage solution, I need to configure and deploy the entire thing in order to get the one little feature I actually need. Buying an EMC, NetApp, HPE, Nutanix, Hedvig, CEPH or any other solution is massive overkill, as great as they all may be!

Let's have another scenario, I want Big Data. Actually I don't at all, I want do some analytics against some usage logs to identify some common errors. I don't need a Big Data platform, I need the ability to analyse 100,000 individual log entries in order to call out some specific error logs. As a software product, I need to install an entire stack, whether that's something like Splunk, Tableau or Elastic Search, I need the entire product installed, configured, clustered and load balanced in order to run my simple 5 minute query once per week. 

In either scenario not only do I need to install a product with more capabilities than I require, I also need the physical resources allocated to it, and professional services (internal or external) required to install, configure and maintain it.

Sure, for either scenario the likelihood of using additional features from the product are valid in the future, but let’s also look at that:

Without making a product selection my roadmap for storage may define that I need to use NFS today, CIFS in 3 months, RBAC and Quota's in 6 months, multi-site in 9 months. But still chances are I'm buying a product with a lot more features than this. This might actually influence my roadmap, I may decide to include FC because the product selected (or selected for me because of incumbents) comes with that feature for free. Now I need to find a way of creating a business benefit and feature from something I never planned to use. Similar for Big Data, lots of future potential, but actually I hadn't planned on most of it.

Generally what I see is requiring maybe 10% of my roadmap feature-set to meet my MVP. For IaaS I might just want the ability to provision VMs to meet my MVP, but that's 10% of what I have planned for my IaaS platform to deliver in the next 12 months. However every product in the market will provide me with 200% of the features and capability I'll ever be able to use.

This in itself isn't really a problem, I don't mind having more capability than I know what to do with, and I honestly do (believe me) understand why the vendors are doing it. Another customer setting next to me will have the same view, but their 10% will be a different feature set, so a vendors product needs to accommodate lots of use-cases and have a wide spread of features, I totally get that!

However, what is a problem is that to realise the 10% that I need for my MVP, I need to pay for 100% and I (generally) need to implement the 200% (the additional features I'll never use, but the product is built to deliver anyway). There's also no way to rapidly consume this, because I have to deploy the entire product, I can't just quickly customise and deploy the small feature-set I need, (generally) the entire product needs to be customised, configured and deployed in order to realise what I need.

So who can do this? GCP, Azure, AWS, and many other cloud vendors.

Back to my storage solution - Just need 2TB of NFS, fine go configure Amazon's EFS, or an Azure file-share (I know maybe not technically NFS). I pay for the specific feature I require, the specific capacity I need, and I'm up and running in minutes (or less).

Analytics? Fine just put that data into Big Table, maybe Cortana, or EMR, and just pay for a small amount of storage required and the individual queries I execute.

These also scale beautifully, and the portfolio of periphery services around each of these allow me to grow my product features in a granular fashion, always watching the costs. At some point in the future you may go through a Dropbox moment and realise the cloud is no longer a cheap way to run at scale, but at the same time, it may take you a few years to get there and you’ve had massive benefits and gains from getting their quickly and with managed costs.

Over the past few years I’ve continually been annoyed with the cloud vs. on-premises arguments given by different vendors, generally revolving around cost vs. scale. A big reality in today’s world, especially with more and more organisations going Agile, is the MVP. I don’t need all the bells and whistles and widgets that a vendor has had to build into their product, and I don’t need the complexity of installing a feature-set I’ll never use. In my humble opinion this is one of the greatest drivers towards cloud consumption and I think a real challenge for the on-premises vendors to try solve. Please, please, please definitely don’t solve this problem with a feature based licensing model, because then you’re making me install the entire product and all the features, which I then can’t use unless I pay more later than I would up-front and giving me a license management problem to deal with (which I’m probably going to need another product to manage that!).

I don’t know if on-premises vendors can solve this. However, I’ve often said there is a unique opportunity for a vendor that can, if you can crack the technology challenges (be innovative, bring something new, but still meet all my fundamental requirements, and give it to me cheaper) and also offer it to me in a consumption model which matches my own roadmap of features (did I also mention cheaper?), then I think there’s a winning formula! I think that’s one of the not-often discussed success of cloud computing, because I can and regularly do get this benefit from cloud services.

I’m probably discussing for something that just cannot exist on-premises, and for now many people will continue using cloud services instead of on-premises solutions not because they’re cheaper, or more scalable, but because they can develop their features against a MVP and balance their cost exposure vs feature benefits. Alternatively people will continue to shun OSS or commercial software and products in favour of DIY because they can more easily deliver against an MVP and then produce incremental feature releases in a controlled and cost effective manner (yes, even if this means more work in the long run!).

In terms of DIY: If you match the cost effort against the business benefit, you can ride a profitability benefit curve over the effort even if the overall effort is more expensive than buying or selective a product. (This is a little bit of CAPEX (Capital Expenditure, paying for everything up-front) vs. OPEX (Operational Expenditure, paying for everything over time as you use it), but not quite true). This is because of the MVP, you can invest a small amount of effort to meet a benefit which can start realising and delivering financial benefits. Installing a product has a huge risk and curve, you need to deliver the entire thing and the risk is you miss your window of opportunity and it’s much more difficult to pivot, especially with such a large investment overhead. It’s easier (in relative terms) to justify writing off 6 months of development work than a product that was sold with a 3 year plan including support and implementation services.