Business model iterations. Crucial points for gradual business model design

Posted on by Bart Doorneweert

Ambition is what drives many of the entrepreneurs and researchers I work with in creating new business models. And ambition creates the right kind of energy to start shifting boundaries in the thinking of possibilities. Yet ambition is also what can create problems with business model innovation, particularly in overestimating idea potential overlooking the need for critical testing, over-hypothesizing business model mechanics, and last but not least underestimating the long run and grit that is needed to pitch up a business model in the wild. I recently did some research on an interesting case that shows just how complex it is to achieve a promising business model, and how modesty in approach, and incremental improvement paved the way to a highly robust business model for a platform in the medical sector.

Glooko
I had to advise a consortium of organizations on the joint development of an app for (pre) diabetic people. The first thing I do in these kind of cases is to look for a compelling precursor, and that was an app named Glooko. Digging into the history of how this app developed, I found 4 very powerful lessons to learn for entrepreneurs facing the business model challenge. These lessons regard points I usually see going wrong because people take to their business model designs overzealously.

The Glooko iPhone app

1. The parsimony of the initial value proposition
All diabetics are requested to keep a logbook of their blood sugar levels, caloric intake, and exercise. Glooko started off with just that, the simple hypothesis that its users would find more value in keeping their logs on a smartphone (launching initially on the iPhone) instead of on paper. They started with something simple, which could be validated and expanded on, rather than starting with a feature-laden product for a too wide a range of customers that would swamp learning and iterative development.

At the time there were a couple of competing logbook apps on the app store, but they all required manual input. So, the innovation with which Glooko launched in 2010 was a glucose meter synchronisation cable that could read data from blood glucose meters, making registry more easy and accurate. The app was free, like the other apps, but the cable cost 40 dollars. Glooko thus bypassed the most common innovation myth that you need to create something completely new and unexpected to build an invincible product. Rather they built something users were already familiar with, and solved a major problem at launch that they could immediately start generating revenue with.

2. Gradual refinement and expansion of features
Based on the initial value proposition, Glooko started building additional functionalities. The first was becoming more sharp about its metrics and analytics by making the glucose synchronization cable connectable to a wider range of commonly used glucose meters. This turned the app into a prime data aggregator through synchronization over various metering devices. Also they linked to actual supermarket and restaurant food product databases, to feed into the app’s caloric consumption input registry. This way the app could provide more accurate data input and readings overall.

When Glooko achieved FDA approval on the cable in 2012, they were allowed to provide data analytics and graphing, so that patients now could better monitor and plan their regimes, and share their data with their clinician. Launching the app on the Android platform at that time also expanded the reach. And currently they are taking things even further into predictive analytics. The beauty is that everything expands based on gradual learning, rather than cluttering the learning process with too many learning objectives at once.

3. Taking time to create a platform community
Before FDA approval, users could share only their data with clinicians via email or PDF’s. Even though this wasn’t ideal, it was the first step towards creating a platform. After FDA approval, Glooko enabled clinicians to access their patient’s data through a web app that used analytics. Patients and doctors could now have a better conversation on the patient’s health status and progress.

But this was apparently only the beginning of the social mechanics that this app could achieve. Currently, Glooko is exploring the possibilities for predictive analytics in partnership with a renowned diabetics research organisation, to help insurance agencies and hospitals estimate the local prevalence of diabetics. This helps these customers to better optimise their service and staffing capacities, based on the needs locally, and could be the big revenue stream that will turn Glooko into a profit making machine. This development of social functionality is very much in line with the excellent advice that was recently posted by Andrew Chen on building platforms. The irony is that you don’t build a platform by starting with building a platform!

4. The lean approach to customer acquisition
Currently Glooko has 20 people on board, with only a couple in the sales force. I think there are two factors that can keep their sales force this lean. For one I found Glooko myself by using Google, prompted by a notion that “there must be an app for that”. That’s all it took. Secondly, I suspect that they can ride a wave of clinician referrals to real in new hospital accounts and insurers. What also helps here is the recent partnership with the diabetics research organization to bolster credibility on the analytics of the value proposition. However this may turn out in the future, it is an incredible feat that they have come so far with minimal acquisition activities. It will be interesting to see how far they can take it.

Conclusion
The Glooko case is a very rich learning case on business model innovation. I will use it often when trying to explain about the business model innovation process, and syncing everybody’s expectations on what will be required to search for and develop a new business model. If you’re interested to use this case yourself, I’ve included it in a presentation below, visualising the business model iterations. I’m keen to have any further thoughts and reflections!

 

The minimum viable product for physical products; what we can learn from the makers.

Posted on by Bart Doorneweert

Imagine you live in rural India and you own a motorbike. Every once in a week or so, you are approached by a passer-by or a neighbor to help out because his bike has run out of gas and the nearest station is 16 kilometers away. Sometimes they’re lucky. You have enough gas to share and you’re able to perform the icky job of siphoning off your gas with mouth and hose. People even pay you extra for your discomfort, enabling you to buy a pack of gum to clear away the taste from your mouth.

So, after a couple of times of doing this, and the unintended near swallowing of petrol, it hits you! Could there by a market for this? Could I build a filling station with the purpose of helping people reaching the next village? A solid discovery of a customer problem, and a potential solution to tackle that problem.

Now the question is what a physical prototype of your business model would look like. Fortunately you’re strapped for cash at your 2 dollar a day income, imperative for lean decision making. It prevents you form asking the wrong type of questions for your prototype like:

  • What colors should my uniform be to look credible enough for my customers to buy from me?
  • Do I serve Coke or Pepsi at my station?
  • How about a drive-through bike wash?

In this case you need to earn before you spend. So no, it won’t be a lavish, fully furbished, high-tech unmanned petrol station. It might look more like something below:

 ….the Minimum Viable Gas Station (photo credit to Niti Bhan).

This prototype would be the most reduced concept (generally referred to as the Minimum Viable Product (MVP)). The MVP enables you to test the most essential parts of your business model: How do customers interact with and value my product? The downside is that it looks scrappy, but the dominant positive side is that you will naturally test better questions about your business model:

  • Would customers pay extra for this type of filling service? And, how much?
  • What volumes will they need, and how much stock do I need to keep?
  • Is there a pattern in demand which is prevalent throughout rural areas?

Through such essential questions you are also more inclined to focus on gathering essential data for testing your idea. So it’s not so much the total number of motor bikes that zip by your station that count as an indicator for the potential of your idea. Depending on that in your case will make your family go hungry. Naturally, it’s the number of people that actually make a stop for a fill that does.

What’s more is that through playing with pricing, you might discover that customers are willing to pay 4-5 times the market rate for petrol, because your service saves so much effort (so radical affordability as the main constraint in servicing the BoP appears to be an assumption). Now you have found the essentials for scaling a profitable business: franchise anyone?

What we can learn from the makers
In short the MVP emphasizes what matters, and prevents you from wasting resources on testing the non essentials and using non-essential data. But conceiving your MVP is hard. How do you define your product in the most undressed way possible to test your product and its features? It is even more difficult to build an MVP for physical products like a gas station than for a web application (where the MVP concept naturally originated from), as you often incur more costs in time and materials to test them.

But, as the example in rural India shows, constraints like money and time spark creativity and can invoke “the maker” in all of us. Play around with representation: there is always a prototype! In our case we redefine the gas station to a jerry can and a funnel: the smallest representation with which all essential features of a gas station can be tested. People like Steve and Woz of Apple started out with just a motherboard.

Invest in defining, and cutting & pasting your MVP. It keeps you from carrying around stupidity for too long; it prevents you from filling the bucket with so much water that it starts spilling over the rim once you start walking. Build with less.