, , ,

I’ve been thinking about this, off-and-on, over the last few weeks, ever since I had a conversation with a chap hoping to build up a large database of Type 2 diabetes related stats, analysis of which would allow his firm to develop a tool to help sufferers self-manage their own care.

In the context of our own interest in getting hold of large amounts of data from wearable devices with movement information related to exercises, I began to think about the differences, wondering what they might suggest.

In the case of a diabetes app, then, what are the conditions? I came up with;

  1. Restrictions on access – diabetes is a medical condition; data results from medical interventions, from medical devices. Access to these will necessarily require a strong partnership of some sort with the medical establishment.
  2. Data-set size – the potential range of measurements and other data to be collected, possible treatment approaches, the number of sufferers and the wide variety of effects suggest large, complex data sets.
  3. Analytical work required – as a follow on from points 1 & 2, analysis will require expert medical involvement, and will inevitably be truly complex.
  4. Access to market – highly restricted – any provision of even the simplest medically significant advice from an app will have important regulatory and risk factors.
  5. High-value market. Type 2 diabetes is a disease which is widely considered to be at epidemic scale in developed nations. Management is incredibly important – diabetics with poorly managed conditions face truly terrible outcomes and quality of life issues – which involve significant care and treatment costs. There is thus a huge potential market (in both scale and value) for useful self-management tools.

Points 1-4 make it clear that any entrant into this area will need to make significant investments on a number of fronts – investments which may be justified by the market identified in point 5. If they are, then a team who have a good story to tell about points 1-4 should find investors on the basis that the ability to line all of these issues up will be relatively rare – and thus competitors will be few, each of them faced with the same significant hurdles.

In summary, Diabetes Type 2 management software could be a large, high value market, but has significantly high barriers to entry; investors in a successful product can be reasonably sure that there will be few competitors – as long as those barriers to entry are maintained. Investors in this area are likely to be highly secretive about as much as possible of their IP, and, once established, be keen supporters of tight regulation. Given the inherent conservatism of the medical establishment, this will likely remain a market with a small number of players.

So then, what are the parallel conditions for an outfit like ourselves, looking to build and use a library of movement data that will capture physiotherapy exercises?

  1. Relatively easy access – I’m going to break this down a little;
    1. collection of data points – this is essentially easy – we can simply get people to wear a device and do the exercises while we collect the data. There are no significant  legal, privacy or other conditions here.
    2. access to sensor data – this is a little harder, as most device manufacturers consider the processing of the raw sensor data from their device as an important part of their IP; we haven’t investigated what you get from the API of any wearable device so far, but it is fairly clear from their information that they intend to be the interpreters of the raw data and offer up only metrics on the patterns their own software has identified from it. However, alternative approaches exist –  you could;
      1. develop your own device. This is obviously not a trivial undertaking – but neither is it particularly hard to do. High-end, nine axis accelerometer chips are commodity devices, as are other parts (essentially a bluetooth chip, a controller and a battery). Some straightforward industrial design and you can have your own wearable, with access to any level of data you wish.
      2. hack an existing device – there’s nothing to stop you buying an existing device and reverse engineering its communication protocols. modifying it – as long as you are careful about the licensing around any embedded proprietary code.
  2. Data set size – for exercise data, only moderate size data sets are required – depending, of course, on the level of analysis and interpretation desired. And all the data comes from the sensors in your device – you’re not also trying to collect data on a number of other factors, as you would with diabetes.
  3. Analytical work required – turning nine sets of sensor output into reliable descriptions of motion in 3D space is not trivial – but then again, once you have developed a template for the integration of the data from your particular wearable, it’s going to work for every exercise you wish to analyse/model. Again, you’re not trying to integrate essentially dissimilar types of data into a coherent picture, and you’re dealing with highly structured data.
  4. Access to market – essentially simple – no significant restrictions exist for access to private individuals or private fitness practitioners. Access to medically registered practitioners may be more controlled, but for an app which offers no diagnostic or testing output, this is primarily a matter for marketing and sales, rather then regulation.
  5. Market value. The fitness/exercise wearable/app market is enormous, and growing.

The picture here, then, is of a large, porous market, with relatively low barriers to entry – a very different set of conditions from our ambitious diabetes management friend. What does this understanding tell us?

Well, for me, what it says is that the model most wearable companies are working with at the moment is not sustainable in the long term.

Device manufacturers want to own their device’s data and the interpretation of it – hoping to lock customers in to their own walled garden of data, apps, stats and so on. At the moment, most of them are offering the apps free, using the quality of their individual app offers to drive hardware sales – after all, it is the app that customers interact with, not so much the device.

The problem with this is that, once the device is sold, that’s pretty much it for sales income, beyond wear-and-tear replacements, unless you can convince our customer that they need to upgrade. and really, given the level of analytical ability on display from current devices, what sort of upgrades are needed, that would be compelling?

So the business model is based on the fact that the market isn’t yet saturated; build some cool apps to drive sales (that offer features beyond Apple’s offer!), give them away free and hope to have invented a new business model before everybody who wants a device already has one (or two or three).

This looks screwy to me; software is obviously the space where innovation is going to occur, so to keep ahead of the curve, these companies are going to be continually spending on new software, most of which will be offered, for free, to their existing customer base. After a certain point on the sales curve, this is not going to be a comfortable place to be.

Now, I’ve no doubt that the people in these companies have got all sorts of ideas about what to do next, and I’m sure many of them are cleverer than me – so I’ll wish them luck and watch their progress with interest.

But in the meantime, my analysis suggests a different approach, and it’s this; build software that understands exercises – as exercises – as real human motion in space and time, based on raw sensor data. Then, on the basis of this library of exercises, interpret data from any given wearable and match it to the exercise.

Build a universal library of exercise dynamics, that is device agnostic. Separate hardware and software, so that hardware can become (as it will do) commodified, and then license that library so that software can be developed in a myriad ways, for a myriad of specific purposes.

This is a parallel to the approach Waze took to developing mapping/wayfinding software. The guys that started Waze had a similar analysis of the GPS routefinder market – namely, that the level of innovation at the hardware level of GPS devices was strictly limited – that where the real value lay was in the data, and in the software that could do interesting things with that data.

They built a GPS app that had no map – literally, they started with no map at all. Their brilliant idea was that they would get their users – all equipped, of course, with GPS enabled smartphones (which they had bought for other reasons, at great expense and were now keen to use to the full) – get their users to build the map for them! In the early days of Waze, if you were driving down small country lanes, it wasn’t uncommon for you to be the person who defined the map for that road. Waze’s users built for them a map that formed the basis on which they sold their company to Google for all but a billion dollars. The app encouraged this by some full-on gamification strategies that made pioneering new routes seem exciting and rewarding – and boy did it work. Waze now claims to outperform hardware GPS devices – all without spending a penny on  building or acquiring maps, or a penny on hardware design/marketing/after-sales.

How might this approach work in the wearables space? I’ll leave a discussion of that for another post – hopefully with more insight and a widened viewpoint after tomorrow’s inaugural London Wearable Developers Meetup!