Minimum viable product:

Today I had a coworker come into my office to talk about entrepreneurship and an idea he had for starting a company. His idea was an interesting one related to helping people find the perfect product for them based on products that they already owned (I’m being intentionally vague as I don’t want to give away his idea). We started talking about a concept called the minimum viable product (MVP) which is prevalent in the startup world. The idea behind the MVP is to build the minimum system necessary to determine if the value is there. It turns out that the MVP is often times much more minimum than you might imagine. In some cases it might be as simple as a landing page that you direct people to that allows them to sign up to register interest based on a description. That bit of information can help you to determine whether it is worthwhile to even start building the product.

In his case users would tell the system what they already own and what type of product they are looking for. The system would give recommendations for products that would be a good fit for the user. For example, if I own a BMW and wanted a coffee maker, the system might recommend a particular brand favored by BMW owners. He started asking questions about getting a technical cofounder and I explained that it might be premature to build a system, that his MVP might actually be a simple web user interface to collect the information. People on the backend could manually make the determination of the products to recommend. Over time if he could get users, it might make sense to begin automating the tasks that take the most time or the tasks that could provide a better user experience. His challenge would be sifting through the data to create correlations between products. However that task wouldn’t necessarily require a custom system as statistical programs could provide the same function.

This applies not only to product based systems but also to IT systems because too often IT organizations gold plate their internal custom software. End users ask for features without a clear understanding of the value of automating a particular task. Ultimately virtually all tasks in a business can be done manually. At some point the quality or speed of manual processes simply isn’t sufficient and automation can be used to improve the processes.

Recently we had a client that had a monster spreadsheet that used about 300 inputs from different sources to calculate a risk profile for loans. In a prior incarnation of the project they tried to automate the spreadsheet. Unfortunately, the business rules used in the spreadsheet were constantly changing and so the project failed. Development blamed the business for constantly changing requirements, the business blamed development for not being able to build a system robust enough to handle their constantly changing rules. When we came on the project we looked to see where all the time was spent to see if we could identify a much smaller product for the development team to build. It turned out that a majority of the time was spent assembling the data that was input into the spreadsheet. The calculation actually happened instantaneously. The development team realized that they most (but not all) of the data sources to populate the spreadsheet so we created a few avenues to pursue. In the first stage, development would automatically populate the data they already had into the spreadsheet. The business would manually assemble the rest of the inputs. In the second stage, development would automate the rest of the data. The business team at first felt like the development team was hardly building anything (how hard is it to take data you have to populate a spreadsheet?). But eventually they came to agree that the small feature would remove their biggest time sink while retaining their flexibility to change their business rules. Development was happy because they actually were able to produce a success and begin rebuilding credibility with their business stakeholders.

We also put off any plans to automate the spreadsheet because it would require implementation of a rules engine that development estimated would take a year to deploy. More importantly automating the spreadsheet while making a “complete” system didn’t provide much value at all.

On your next IT development product think about the minimum necessary product that will still provide some value to your users.