Where the Compute Should Live: How an Industrial IoT Platform Provider Used Market Research and Strategy Advisory to Decide Where to Invest Between Edge and Cloud

Edge computing has become one of the more commonly requested architectural capabilities in industrial IoT platforms, but the underlying drivers of that demand are considerably more varied than the term suggests. Some customers genuinely require edge processing because their use case involves real-time control loops where cloud round-trip latency is unacceptable, or unreliable connectivity makes continuous cloud dependency impractical. Others request it primarily because of bandwidth cost concerns addressable through less disruptive means such as compression or filtering at the data source.

The client’s product team had been receiving edge requests with increasing frequency for two years, creating internal pressure to commit substantial resources to a comprehensive edge capability. What the team had not done was systematically examine whether each request’s underlying driver actually required edge processing, or whether a narrower set of customers had a genuine technical requirement while a larger group had a cost concern a different feature could address more efficiently.

Committing to a comprehensive build without this distinction risked a substantial misallocation — solving a small subset of genuine latency problems while spending disproportionate effort accommodating a much larger group whose concern could have been addressed far more cheaply.

Key Challenges

• No structured analysis distinguishing edge requests driven by genuine latency or connectivity requirements from those driven primarily by bandwidth cost
• No use-case-level market research establishing which industrial applications genuinely required edge processing as opposed to benefiting marginally
• No segmentation of the client’s own customer base by the actual underlying driver of their edge requests, despite two years of accumulated data
• Risk of committing substantial investment to a comprehensive build addressing a smaller genuine need while leaving a larger cost-driven need inefficiently served
• Product roadmap pressure building from request volume alone, without the driver analysis needed to determine the appropriate scope of response
• Leadership expectation that the next cycle’s edge investment be sized according to genuine market evidence rather than request volume alone

Customer requests for a specific technology capability frequently bundle together genuinely distinct underlying needs. Edge computing requests are a clear example: latency-critical control applications and cost-sensitive monitoring applications can produce an identical surface-level request while requiring fundamentally different solutions.