10 Common IoT Commercialization Errors
The Internet of Things is still a fairly new development, but the commercial success rate for connected products is discouraging. Failures outnumber successes by more than two-to-one. Amid all this trial and error, Peer Insight is exploring success and failure to discern the underlying patterns. We have worked on over 20 IoT projects in the past decade. More recently, we have conducted over 40 expert interviews.
Download the presentation that Peer Insight shared on the 10 Commercialization Errors at the Liveworx conference in Boston, MA. It includes strategic frameworks for designing how you bring your IoT solution to market.
Check out our other IoT resources on IoTForAll.com
- The Pivotal Role of Business APIs in IoT Platforms – Part I |Part II
- How Smart Should your Smart Solution Be?
- To Commercialize IoT, Embrace the Venture Structure
IoT Commercialization Errors
Slow pace; Framing it as an R&D Challenge, Not a Commercial Venture
Many R&D projects subscribe to the tortoise-vs-hare theory of speed: slow and steady. That’s OK for managing technical risk, but ill-equipped to address market risk. Venture capital firms know commercialization requires speed and agility. So take a page from the VC playbook: run it as a venture. That means a joint technical-business team, funded to a near-in milestone, with a laser-focus on getting to first revenues.
Weak Use Case; Low Resonance With Target Customers
The connected products that struggle are often too ambiguous about the value for the user. They may offer tracking or remote communication, when users don’t see high value in those capabilities. Insufficient effort and inconsistent methods are used to ensure the connected product solves a major pain point for customers.
Complexity; Solution Too “Smart,” Not Simple
Many connected products are simply over-featured in their initial development. A connected tea kettle, for example, presents complexity beyond the needs of the vast majority of tea drinkers. Just like robots, the more successful IoT products are only smart about the few things their commercial strategy requires.
Sunk Cost; Build too Much Before Validating the Market
The key to solving this failure is to build a commercial hypothesis — and test it — before you invest too much in the physical solution.
Who is this solution for? What pain point does it solve? How will they learn about it and buy it? Questions such as these comprise the market risk, and we need to get our arms around it.
Focusing on the Mass Market Instead of Early Adopters
Development teams tend to think big and shoot for the fat middle. However, if the product didn’t get real traction in Year 1, it often didn’t attract support to scale and cross the chasm to reach the early majority. The most successful IoT projects focus on a small segment of early adopters (or earlyvangelists, as Steve Blank dubs them). That’s where they get their initial traction, and build belief.
Weak Business Model; and Slow to Adapt
Revenue models for most connected products undergo many evolutions in the first year. We observed that very few firms test multiple revenue models in the market, pre-launch. Instead, they tended to pick a logical (or familiar) one and then were sluggish to adapt, post-launch.
Product Myopia; Overlooking the Service Aspects
When you combine a product and a service, you get a service. That is, when products become ingredients in a connected experience, the service attributes tend to dominate the popularity. Very few firms adequately anticipated the need to conform to – and enable – service architectures.
Making When We Should Be Partnering
Not only are many connected products too smart, but a lot of them build elements they could more efficiently partner for. The key part of the Make vs. Partner decision is whether the component establishes a control point for its maker. Planning for control points needs to become more formalized, along with the Make vs. Partner decision process.
Lack of API Instincts; Can’t Scale Thru Third Parties
While technical APIs always get their due, the notion of setting consistent, scalable Business APIs is mostly neglected in connected products. The business terms between participants (e.g., data sharing, revenue sharing) are too often left to one-off business development negotiations that are both slow and risky.
Underestimating the Chicken-and-Egg Problem
Many connected products work well when there are lots of nodes on the network, and not very well when there is just a handful. Getting to critical mass is sometimes called the chicken-and-egg problem. There are concrete ways to address this, but this is most often a simple area of trial-and-error.