Most moderately serious cyclists have come to know and loathe the indoor trainer, a device that one attaches their bicycle to in some manner, so that they can spend hours pedaling and sweating away indoors without going anywhere. The trainer can allow for a cycling workout when it’s too wet, cold, or dangerous outside, and can also allow for highly structured workouts that are difficult to duplicate on the open road.

For years, most trainers were fairly “dumb” devices that might allow for a resistance adjustment and little else. With cyclists generally being a group with disposable income that appreciates technology, eventually a company called CompuTrainer created a “connected” trainer and associated computer program that allowed the cyclist to integrate the trainer with a personal computer. This allowed the cyclist to create a workout on their PC, and have the computer control the resistance level and monitor the cyclist’s performance during the workout. CompuTrainer provided the entire package of hardware and software, achieving a vaunted state that many companies claim they aspire to: that of an ecosystem provider where an entire “experience” or process is designed, delivered, and integrated by a single provider.

The trouble with ecosystems

Ask nearly any executive in a product company about the benefits they see in IoT, and they’ll likely cite becoming an ecosystem provider as the consummate position in a market. Apple is the prime example of a successful ecosystem provider, where the company delivers hardware, software, services, integration to other vendors, and even a marketplace for third parties, happily deriving revenue from each element of the ecosystem.

What’s not to like? The trouble with ecosystems is that it’s amazingly difficult to succeed in each unique discipline required to “own” an ecosystem. Your company may have a storied history of developing well-engineered products, but has minimal competence with the software and integration side. Certainly these services are available from a variety of third parties, but the other major challenge to building an ecosystem is the potential for disruptive alliances.

The trainer market breakaway attack

CompuTrainer was successful at being essentially the only mass-market integrated, computer-connected training product for cyclists until a startup called Wahoo changed the game with its oddly-named KICKR “smart” trainer. Rather than attempting to build a competitive ecosystem to CompuTrainer, Wahoo released a well-executed trainer that wirelessly shared its data using the vendor-neutral ANT+ and Bluetooth protocols, and also allowed any third party program to control the trainer’s resistance over those same protocols, essentially turning the cycling trainer into an IoT device. On the software side, Wahoo offered little more than a basic mobile phone app to calibrate the trainer and adjust the resistance levels, but the key benefit was immediately obvious: training software makers could now focus on training applications and leave the hardware to someone else.

One of the more interesting companies to take up that challenge is Zwift, a company that’s created what amounts to a cycling “video game” where a virtual cyclist pedals through London, Virginia, or a simulated island. Rather than mashing a controller or keyboard, the virtual cyclist is controlled by the effort expended by the real cyclist sitting on the connected trainer. Pedal harder and your virtual cyclist goes faster. Hit a hill in the game, and the resistance of the trainer increases and makes you pedal harder.

Dozens of other companies have embraced this open standard on both the hardware and software side, since the economies of scale are obvious. If I’m a hardware manufacturer, I can incorporate ANT+ and/or Bluetooth and open my trainer to dozens of training software packages, just as the software companies now have a large pool of trainer hardware that works with their application. On the basis of product development and support costs alone, CompuTrainer’s ecosystem now looks like a liability rather than an asset.

Ecosystems aren’t easy

Before you embark on your quest to build the dominant ecosystem in your market, whether that market is cycling trainers, connected appliances, or industrial equipment, consider all the ingredients that comprise an end-to-end solution. Hardware and software are obvious, but there are interfaces, networks, integrations, support, and myriad other considerations that will become apparent if you carefully map out the full suite of components to build, deliver, sell, and support an IoT-based product. Carefully consider which components you’re well positioned to deliver successfully. Perhaps delivering 5% of the ecosystem well will put you and a “peloton” of partners into a dominant position, versus attempting a breakaway on your own.

Also see:
Approach IoT security as a system design problem
International technical standards needed to accelerate IoT growth
Intel to manufacture ARM processors in a bet on IoT and premium smartphones
IoT and liability: Who pays when things go wrong?