Minimal Viable Product

Here is something you don’t hear that often: estimation is hard! It’s so hard that people almost never get this right, and probably they shouldn’t because after all it’s an estimate:

“An approximate calculation or judgement of the value, number, quantity, or extent of something.”

I have a suspicion that estimation is hard for most trades not just for software development, because people are generally quite reluctant to give you an estimate. So generally people tend to either:

  • Overestimate and risk losing the job to someone else OR
  • Under estimate and risk working after office hours to catch up

This of course is inconvenient for everyone and tends to create a bitter relationship between the two parties.

Is there another way?

Yes .. avoid estimating.

First of all let me start by pointing out the obvious, everything has a value, and when I say “value” I really mean a “price”. So first we need to understand how much a client is willing to pay for a product. To give you an idea on how to calculate the price, general IT provides solutions to problems which we could categorize into 4 main categories:

  • Solutions which save time. For example searching and retrieving previously saved documents more efficiently. 
  • Solutions which help mitigate risks and solve legal issues – which would avoid you fines or losing clients.
  • Solutions which entertain.
  • Solutions to record data which in turn give a business value. 

In any of these we could work out how much a product is worth paying for. For example if a company, Strawberry company LTD, doesn’t have a document management system and employees are spending 30 minutes a day searching for documents you can estimate how much time is wasted in a year. An average employee working at Strawberry happens to be Bob, who works 8 hour days and earns €30,000 per year. When you deduct the time that Bob spends on leave and sick he works for 220 days in a year, which means that almost 14 days (220 days * 0.5 hrs / 8 = 110 hours) per year are spent searching for documents. Roughly €1909 per year. Apart from Bob there are 20 other employees and assuming that generally an IT system lasts for 5-10 years, Strawberry shouldn’t spend more than €190K – €381K on this system. From this simple calculation Strawberry can get a rough idea on how much money they can spend to at least break even.

The next step is to come up with the least amount of development tasks required to make Bob’s life easier. You come up with a MVP:

“The minimum viable product (MVP) is the product with the highest return on investment versus risk.”

mvp
On the left we see products that have too little features to be used, while on the right are the products that users would like to use.

Your initial aim should be to produce a product which contains the least number of features yet is still viable. You start to remove any additional features which are not used that often, for example any ability for users to manage their account, change passwords, change lookup values. You also remove the nice to have features such as being able to search by extension or document type. You only concentrate on the basic tasks that get the job done, in this case type in a keyword and get some results. Like this Bob gets to try out a very basic version of the product and checks if its enough to get his work done. From here we can either decide that what we have is enough and thus stop development or do another iteration. The beauty of software development is that we can evolve the first release and produce a better product. This process is repeated until everyone is satisfied. I have to point out that the minimal viable product is not limited to features but should also be used as an approach for software architecture.

design_evaluate_develop

If I am a client asking any company to provide me with a service I would prefer paying per day rather than trusting the company to provide me with an estimate. Here is why:

  • If developers are taking too many coffee breaks instead of working I can terminate the project at any point.
  • If the developers are doing a lousy job I can terminate the project in the beginning since I’m not really committed. I only end up losing a small % of my budget.
  • I don’t have to pay for features which I’m not really sure if I need.
  • I don’t run the risk that developers cut corners since they under estimated.

Most of the time clients are strict on budget but don’t really care if the end product doesn’t have the fancy check boxes, thus we are able to prioritize between the features and get the most important tasks out-of-the-way first. I truly believe that this is the best way to mitigate risks for all parties involved and ultimately create a product which works better.

Did anyone try this approach? Any thoughts?

Leave a Reply