The dangers of minimum viable product that no one talks about

It has become a core principle of the software development world that you don’t know what your users will want in the future. So you should design and build as little as possible up front, get to market quickly, and then be ready to respond to evolving needs. This approach is supported by the new religion of software development, Scrum, and lauded by its bible, The Agile Manifesto.

The cynical part of me wonders if there may be some commercial infiltration of the zealot’s agile utopia by the financiers of our new era. Venture and private equity investors have a very discernible interest in getting engineers to get to market as quickly as possible and monetizing their work instead of waiting until they feel it is ready. It is hard to build something that has a smooth and elegantly simple answer to a whole category of questions because investors want us to make money by answering just one at a time and selling that solution quickly. There is nothing wrong with making money, but the pursuit of it in the short-term with no regard for consequences has often been the cause of medium-term failure.

But regardless of the reasons for the pursuit of the Minimum Viable Product (MVP), I wonder if universally applying it to all situations might be a mistake. To be clear, I am not talking about the purist principle of MVP that says you need to limit feature-set not quality. We can all get on board with that. What I am referring to is the interrupted experience. The “appification” of the future of software, if you will. It is true that some things work better if you break them down into their component pieces, structure them as microservices. But even those things are better if there is an overall plan for the greater direction that the software will take.

My experience is mostly in business applications. The ultimate goal of business software is to take all the information that a business generates and that it needs so it can be linked together. There are massive inefficiencies and even failures when the left hand does not know what the right hand is doing. The larger and more complex an operation is, the greater the potential harm of a lack of visibility of relevant data from one side of the organization to the other.

This is why ERP and CRM software were traditionally rooted in the large corporate sphere. Only larger organizations had sufficient resources to spend on a massive and complicated implementation project with very long timeframes and frequent failures. They were also the only ones who could reasonably benefit given the complexity and volume of the data their business generated.

Half of that is still true. Today, it is still the case that only large corporations can survive the birthing pains of implementing an expensive and complicated new enterprise-wide system. It is no longer the case that they are the only ones that can benefit from it. Businesses today, regardless of size, work internationally with lots of partners, vendors, warehouses and customer destinations. They have to work in multiple languages and comply with a whole host of regulations. A small business can be every bit as complex, information-wise, as large one.

What does this mean for the day to day operations of a typical small business? In a quickly growing e-commerce world, it is often too late when you find out that the product and the specific units you shipped at a discounted price actually cost you more than you made. If you take your FOB costs versus your sales prices you would think you are fine. But, what about your transportation costs? What about the e-commerce platform’s dynamic discounting? What about the fact that you ran out of inventory in your domestic warehouse so had to fill from a foreign one which completely changes your profit for this one shipment? A Quickbooks Online integration with TradeGecko is good, but it can’t give you the visibility you need in the time frame you need to help you in this situation.

So, what’s the impact of this given all of the above rambling? The point is, that while small and medium sized businesses are trying to work with a multitude of little purpose built apps using API-powered integrations, the overarching information flow is… poor. Data gets shuttled and transformed in a whole bunch of different ways and often doesn’t make it to a place where it can help make coherent decisions. Specific pieces of aggregated data that can really help a growing business be competitive are impossible to get in a market that desperately needs them.

So what is the lesson? Making lots of little purpose-built apps that only communicate in a limited way is limiting the true value of information and insight. I think we can do better.