26 Aug 2016, 19:21 MVP Bluemix

Using Bluemix to build Minimum Viable Products

When setting out to build a new product, product development teams are confronted with a number of unknowns.

  • What capabilities should the team incorporate in the product?
  • Will the product be compelling to its intended users – i.e. achieve product/market fit?
  • How much effort should the team invest in building the product?

In the London Garage, as practitioners of the lean startup method, we use a technique called the Minimal Viable Product (MVP) to help us answer these questions.

What is an MVP?

Unfortunately there is no straightforward definition of an MVP. Eric Ries, the author of Lean Startup, offer this definition.

“The minimum viable product is that version of a new product which allows a team to collect the maximum amount of validated learning about customers with the least effort.”

However, the definition is also a source of confusion.

Is an MVP just a trendy name for something that used to be called proof-of-concept? After all, the definition speaks of a product to collect validated learning.

Is an MVP a product with a subset of capabilities with more to be added at a later time, in other words a beta version?

Some practitioners of Lean Startup have even suggested a MVP could be delivered in the form of a PowerPoint presentation, a video, etc. If so, can a PowerPoint version of an MVP be really considered a product?

What about least effort? How little effort would need to expanded to be considered least?

These are questions that are beyond the scope of this blog. For the Garage, we characterise an MVP as having these attributes:

  • A product with just enough capabilities to achieve product/market fit;
  • And a minimally viable or workable product or something that can be used by users to provide feedback;
  • And a product where we can make changes without incurring high costs.

To build an MVP, we in the Garage use IBM’s Bluemix cloud platform.

Why use Bluemix?

Bluemix is a platform that enable organisations to quickly create infrastructure and host apps in the cloud. Developers creating apps that require complex services such as databases, Watson analytics and many others, can do so by connecting to these services hosted in Bluemix via standard interfaces. This means that we could easily swap one services for another simply by reconfiguring the interfaces. With Bluemix’s OpenWisk, Cloud Foundry and Container technologies (based on Docker technology), developers are also offered the option to build apps in modular components known as microservices.

In the not too distant past, the effort needed to build up similar capabilities as Bluemix to host apps would have been considerable and we have not even begun to invest effort in building the apps! Clearly, this option for building MVP would not qualify as requiring least effort.

However, using Bluemix to build MVP offers these benefits:

  • A working apps with a functional backend systems can now be built quickly;
  • Whilst an MVP does not require a completely functioning backend system but building one with these capabilities, even a limited one, will enable us to more accurately predict work for the next iteration of development;
  • Should an MVP be validated to achieve product/market fit, it would not require additional effort to convert it in a production app;
  • Being able to build apps in modular architecture and with minimal effort, discarding capabilities that are found to have no value would incur little cost.

How to use Bluemix to build MVP?

We’ll use two projects that were built in the Garage to illustrate how we use Bluemix to build MVPs.

The first example is an app we refer to as the Marathon App. Whilst this is mainly an iOS app that runs on a phone and outside the Bluemix infrastructure, it requires a backend database. The app was built using Xcode. The backend was facilitated through a Bluemix Cloudant database service that took very little time and manpower to activate and configure. The connection between the iOS and Cloudant was implemented via a RESTful API. Had we decided to switch to a different database all we needed to do was to reconfigure the REST API.

The MVP was developed in an iterative manner; at the end of each iteration, a working app was presented to the user for review. After three iterations, about three weeks, the MVP was considered production ready and was used to support Simon Wheatcroft, a blind marathon runner, in his bid the do a 155-mile ultra-marathon in the Namibian desert.

The second example was a project the Garage delivered to a medical service provider. This was a more complex project than the Marathon App and the MVP had three separate elements:

  • A Web-based application;
  • An app utilising Bluemix Watson IoT services;
  • An iOS app.

For this project, we were able to build a minimally functional MVP with end-to-end connection, using a combination of REST API and MQTT protocol, across the three elements in the first iteration within a week. By having a working system available for the user to use, the engineering team was also able to predict the engineering challenges for the second iteration and adjust accordingly. The MVP only took three iterations to be declared acceptable for the project sponsor, who in turn was able to use it as a basis to secure more funds for follow-on work.

Conclusion

In the two projects described earlier and other Garage projects, Bluemix was a vital technology to rapidly build a working MVP - real code, not just PowerPoint! This enabled us to validate with the client that the solution that had been built suited their business needs, and make swift changes accordingly.

Without Bluemix, we would have had to incur the cost of setting up a hosting environment and backend services. With Bluemix we were able to use the backend services out-of-the-box, so to speak, and focus our effort in building a working product; and taking it from validation to production state quickly.