It’s natural to think of efficiency in an industrial mindset: replication, scaling, cost per unit curves, and similar. Unsurprisingly, corporations seek cost and speed-to-market efficiencies in their connected product portfolio using a similar perspective. Their results don’t always align with the old industrial paradigm.

Connected products and IoT have matured to the point that large businesses have tried, failed, and succeeded at finding efficiency across their product portfolio. Most attempt this with discipline, reining in initiatives seen as competitive or duplicative. They’ll solve for perceived inefficiency by attempting to yoke all connected product development under one managed system, a central service or center of excellence (CoE).

Unfortunately, centralizing IoT in a single department independent of the business units (BUs) usually fails. Let’s tell some real-world stories to find out why.

If an apocryphal story is one that’s widely-circulated but untrue, these are the opposite—true, but uncirculated. We’ve anonymized everything.

1. The official IoT team

As an industrial titan, ACo formed a dedicated group to own IoT, which it placed under its investment arm because IoT was new. However, all software backend decisions lived in a different central IT service, and all user experience and software frontend implementation lived with their offerings’ respective business units. Confusion reigned.

Bottlenecks emerged early and often throughout ACo’s connected product development cycle. IT and central IoT were the smallest teams relative to the BUs, and therefore possessed the least bandwidth. In turn, their limitations selected priorities for the whole company, regardless of intentional strategy. To execute anything, BUs had to appeal to both central services to get their attention. If their appeals succeeded with both teams (rare), then cooperation between IoT and IT became critical, yet that relationship was the most contentious of all.

BUs tired of this runaround and started going outside for IoT help. From their perspective, they make the money, they have the money, they’re accountable for business objectives, and they're deeply unsatisfied with the centralized IoT/IT duopoly. They tell both central teams to kick rocks, upending their positions as high-and-mighty arbiters and putting both central teams at risk instead.

To calm tensions, salvage relationships, and return some level of autonomy to the BUs, the IoT team leader begins hiring program managers, then loaning them out to BUs. They’re happy for the help, but it’s nothing they weren’t already going to get another way. The IoT leader may have intended to build a center of excellence inside ACo, but built an in-house staff augmentation firm instead.

ACo contacts tell us that BUs view their central IoT group as an impotent joke. The central IoT team can't bring in money, doesn’t bring insight as a pure staffing play. The best they can manage is meddling and temporary headcount.

2. Sisyphus, the IoT guy

BCo senior managers believed connected versions of their government-serving products were an inevitability. To manifest the inevitable, they hired Sisyphus, a charming, experienced early connected product evangelist to apply sufficient leadership and R&D cash to create long-term magic.

Unfortunately, BCo’s C-suite forgot to share their enthusiasm for IoT with their BUs’ managers. Sales and marketing teams universally panned connectivity as a solution in search of a problem. They understood it but couldn’t see why their customer might a. care and b. be more profitable with a connected version of what BCo already sold.

Sisyphus didn’t make life easier on himself, either. He’d dive deep into business units, advocate fiercely for the hows and whys of IoT, get involved with customers, and drive everybody absolutely bonkers. He also had wisdom enough to let each BU do things differently to find unique value in their specific segment, creating perceived inefficiency before BCo even delivered its first connected product to market.

In time, Sisyphus won over internal BU engineering groups one-by-one. He fought internal sales and marketing headwinds the whole way, though—they never saw connectivity as a net benefit. Although it took a few years, Sisyphus ultimately delivered what became a stunning financial success in BCo’s first connected product.

That’s the moment one of IoT’s most common (and deadly) ailments likes to strike: first-phase success sets up second-phase failure.

Now Sisyphus had to repeat his act. He went so deep and had such a high workload as an individual contributor (especially one with an eight-figure success under his belt) that he couldn’t pause, hire, or train anybody. Sisyphus couldn’t mature beyond himself and became the critical chokepoint in a high-friction environment that was still skeptical.

Sisyphus believes the BCo org and culture didn’t allow him to scale. His superiors believed he put too many conditions on how they scale. He was an easy political target when BUs failed to meet their goals.

3. Leviathan, the panacea

In the mid-2010s, CCo realized that IoT affected nearly their whole multi-billion dollar product lineup. Their immediate instinct was to build Leviathan, a huge, singular tech stack and prescribed a method for doing IoT in CCo. CCo’s C-suite believed in the (now quaint) promise of everything being connected to everything else, funneling data into one giant money-making pile. CCo funded their IoT initiative to the tune of 9 figures!

Things went wrong quickest for CCo, and not just because of BU leadership reactance and indignance. By choosing one approach to rule them all, they created a generic approach with fundamentals that didn’t really fit any BU's use case. Enforcing technology selections early sanded off enough value (via technical sacrifices) to reduce the prospective value of most of a given BU's potential solutions (“oh, we can’t do that, then why connect it?”).

Problems came to a head when a distributor rebelled. This distributor didn't like what was being foisted upon them by CCo, and created their own user interface that interacted with CCo’s backend. Customers strongly preferred the distributor’s version, and CCo eventually realized their distributor’s solution was superior, brought the distributor back into the fold, bought their UI, and rolled it out worldwide.

CCo did also have a successful product rollout in one BU, but acute success drove evolutionary failure here, too. By focusing their centralized IoT offering on what worked for this BU, CCo’s technology stack evolved toward the successful BU’s own use case and away from others, leaving those BUs to seek external solutions, thus undermining the value of CCo’s common stack and approach.

Do you really want to do this?

We get it. At the enterprise level, connected product initiatives consume too much money and they run amok across the corporation, stirring trouble in marketing, planning, manufacturing, and more.

It can work, though. We’ve seen and perpetuated central IoT successes. Understand that to reach a successful operating method across a large organization, each business must focus on three things:

1. Strategy. Seek excellence before efficiency. Connected products must be good. Don’t waver and get efficient first.
2. Politics. Create collective, cross-department collaborative action. This will need a significant dose of top-down leadership that will create bottom-up problems. It’s your central team leader’s job to help BUs navigate those challenges alongside the journey from unconnected to connected.
3. Insight. Until a centralized IoT team brings something new to the table, BUs will always see them as an obstacle.

If you feel the pull of efficiency and order strongly enough to proceed and create a corporate IoT center of excellence, we recommend the following dos and don’ts.

The dos of IoT central services

A strong central corporate IoT group recognizes that it’s supposed to facilitate and consult each BU’s connected product development effort. BUs have to own development—they’re the ones who’ll support, sell, market, and iterate on a given connected product. Central services should:

1. Determine their consulting mix and boundaries. Provide self-service tools when necessary, people when necessary, and get out of way when necessary. BUs rarely want someone else to do the work. What’s more, central services will never have the customer connection a BU has...that's the source of product development magic.
2. Educate. Set up educational opportunities...but not too much. Balance education, service delivery, and enablement (e.g. design system). Educate BU, give tools so they can help themselves, support to help them over hurdles. Offer value enough to be invited back.
3. Clarify. Make it easy for decisions to be made without making decisions. As a central services consultant, your mission is to de-confuse and build options, not choose for the people you serve. Still, you'll have to balance option creation with business's need for efficiency.
4. Think far. Central IoT must own a significant portion of portfolio-level thinking—most business units are too siloed to think this way. If you expect customers to buy more than one product from you, this becomes a primary responsibility that no one else will have, and your ecosystem may even be the key driver of purchase value to customers.

Your central IoT team should provide the advice and insight necessary for BUs to move faster and avoid fatal mistakes.

The don’ts of IoT central services

As highlighted in the stories above, these mistakes condemn an IoT central services team to uselessness. If you run or are creating a centralized IoT team in your corporation, don’t:

1. Dictate the method of IoT delivery. Jamming everything into the existing toolset will feel efficient but kill the BU's ability to tailor a customer-specific solution. This is how every solution ends up feeling like the same idea.
2. Become a one man band. The recipe for resistance. In order to thrive, connected product development has to be the BU's show. Otherwise, it becomes about which BU has better relationships with you. IoT requires you to make space for others and invite them in. Leverage your talents to grow talents in the BU.
3. Assume that one success will light the path forward. It may just put too many constraints or too much expense into any individual connected product program. You'll have to go case by case, but things will rhyme.

Above all, resist the urge to over-industrialize. Generic IoT methods and technologies create unremarkable experiences and, in turn, lackluster products.

---

Next Mile can help your connected product program dodge mistakes and avoid tragedy. Contact us for an assessment of your scenario and we’ll outline your most painless path forward.