Connected Product Engineering Services

Forrester's own summary of this market opens with an observation most analyst research avoids making: connected products are everywhere, and far too many of them are bad.

Anyone who has fought a washing machine app, waited for a car's infotainment system to boot, or discovered that a smart bulb requires an account and a firmware update before it will emit light knows the pattern. The physical object usually works. The connected part frequently does not.

Forrester's diagnosis of why is the most useful framing in this category, and it is structural rather than a matter of effort.

Five disciplines, one product

A connected product requires physical product design, physical user experience, embedded software engineering, supporting software engineering, and digital user experience.

A good connected product requires excellence in all five.

That is an unreasonable demand on almost any organisation, because those five disciplines have different talent pools, different tooling, different development rhythms, and different professional cultures. Industrial designers and embedded firmware engineers do not attend the same conferences. Cloud platform teams work in weeks; hardware works in months and cannot be patched after it ships.

A company that has built appliances for eighty years has deep capability in three of the five and is hiring into the other two against competition from software companies paying software salaries. A company that has built software has the opposite gap and no idea how long tooling takes.

Forrester's characterisation of the service providers follows directly: they fill gaps in their customers' capabilities to ensure connected products are manufacturable, usable, secure, and worthwhile.

Four adjectives, four different failure modes. Manufacturable is an engineering constraint. Usable is a design one. Secure is a risk one. Worthwhile is a business one, and it is the one that kills most connected product programmes, because a great many things were connected without anyone establishing why a customer would want that.

Inside The Forrester Wave: Connected Product Engineering Services, Q4 2025

The evaluation scored twelve providers against twenty two criteria covering current offerings and seven criteria covering strategy, using questionnaire responses, executive briefings, case studies, and customer reference conversations.

The full field: Capgemini, Cognizant, EPAM, FPT, HCLTech, Infosys, LTIMindtree, NTT DATA, Orion Innovation, PwC, Tata Consultancy Services, and Tech Mahindra.

Two Leaders: Capgemini and PwC.

Capgemini was credited for a well-articulated and strong vision for connected products, with Forrester citing the combination of engineering innovation and a well-considered partner ecosystem, alongside established expertise in physical product design and prototyping and the ability to manage initiatives across the full lifecycle from concept through operations.

PwC's assessment is the more surprising of the two and worth reading closely. Forrester credited it with a clear vision for helping clients place connected products into their roadmaps, continued investment expanding its network of centres of excellence into adjacent technologies including robotics and autonomous systems, and strength on strategic criteria including business model innovation and culture change.

Then the detail that explains the placement: PwC performs well in physical product design and prototyping by drawing on its Surfaceink heritage, an acquired hardware design capability. Reference customers praised the hands-on nature of interactions with its product designers and the depth of support in selecting and securing contract manufacturing resources on the other side of the world.

An accounting and advisory firm scoring well on physical prototyping and contract manufacturing selection is not what the brand suggests, and it is a good illustration of why these evaluations are worth reading past the tier.

Orion Innovation, a smaller provider than most of the field, positioned itself around the digital and embedded layers specifically rather than claiming the full stack.

The line Forrester does not usually write

Buried in Forrester's own commentary is a statement that undercuts how every vendor in this market will use the report.

The right vendor for your needs may not be one of the two identified as a Leader.

That is Forrester explicitly telling buyers that its own tier placement may be the wrong answer for them, and pointing at the digital experience it provides for clients to reweight criteria against their specific situation.

It is worth taking seriously here more than in most categories, because the requirement varies so much. An organisation that already has excellent industrial design and needs embedded and cloud capability is buying something entirely different from one with a strong software team that has never shipped physical goods. A twelve-provider list where two are Leaders tells you almost nothing about which one fills your particular gap.

The Wave scorecard is more useful than the Wave graphic in this category, and Forrester is saying so.

What actually goes wrong

Three failure patterns account for most disappointing connected products, and none are solved by choosing a better provider without also changing something internally.

The first is the lifecycle mismatch. Hardware ships and is then fixed for years. Software expects to ship and iterate. When a connected product is designed by teams operating on those two clocks, the usual outcome is hardware that constrains what the software can ever do, chosen before anyone knew what the software would need. The memory budget, the processor, and the connectivity module get locked eighteen months before the application team discovers what the product should have done.

Providers that engage early can prevent this. Capgemini's own framing makes exactly that point, that impact is greatest when engaged from the outset. That is self-serving and also true. A provider brought in to build an application on hardware already in tooling is being asked to solve a problem that was created upstream.

The second is the ongoing cost nobody budgeted. A connected product has a backend, and the backend runs for the product's life. Someone pays for cloud hosting, certificate rotation, security patching, and operating system updates for every unit sold, for a decade, whether or not the customer ever pays again. Businesses accustomed to selling a physical object and booking the revenue frequently discover this liability after launch rather than before.

The third is that connectivity was added without a reason. This is the worthwhile criterion, and it is the most common failure of all. Products get connected because competitors are connected, then the app has no purpose beyond replicating the physical controls badly, and usage collapses in the first month.

Security is the part with no undo

Connected products have a security profile unlike anything in enterprise software.

The devices sit in homes, factories, hospitals, and vehicles. They frequently cannot be patched easily, sometimes cannot be patched at all, and often outlive the team that built them. A vulnerability in a web application is fixed by a deployment. A vulnerability in a shipped device may require a physical recall, a firmware update path that was never designed, or acceptance that a population of insecure devices exists in the field permanently.

Regulation has caught up with this. The European Union's Cyber Resilience Act imposes requirements on manufacturers of products with digital elements, and various national regimes have introduced baseline security expectations for consumer connected devices. Requirements around vulnerability handling, update mechanisms, and support periods change what a connected product costs to build and how long the obligation runs.

That is a reason to weight security capability heavily when selecting a provider, and specifically to ask about secure boot, update mechanisms, credential provisioning, and end-of-support planning rather than about security in general.

Where AI changes the product

The current wave of investment in this market is about intelligence at the edge rather than connectivity for its own sake.

Running models on the device rather than in the cloud changes several things at once. Latency drops, which matters for anything safety-related. Privacy improves, because data can be processed without leaving the product. Connectivity dependence falls, which matters in a factory basement or a moving vehicle. And cloud costs fall, which matters when you are supporting millions of units.

It also raises the hardware bar, which brings the lifecycle mismatch back with more force. A device designed for a model that exists today will be running for a decade, and model architectures are changing considerably faster than hardware refresh cycles.

Forrester's note that PwC has been extending its centres of excellence into robotics and autonomous systems points at where this goes. The distinction between a connected product and an autonomous one is narrowing, and the engineering discipline required is converging.

What to test

Establish which of the five disciplines you genuinely have before you shortlist. The provider's job is filling gaps, and you cannot evaluate that without an honest inventory of your own capability. Organisations consistently overrate their software capability and underrate how much their hardware knowledge is concentrated in a handful of people.

Ask for a reference in your industry with a similar gap profile, not just a similar product. A provider that supplemented a client's embedded team is doing different work from one that supplemented a client's industrial design.

Test the physical side specifically if you need it. Several providers in this evaluation are primarily software services organisations, and the ones with genuine prototyping, design, and contract manufacturing capability are the exception rather than the rule. Forrester singled that out for both Leaders for a reason.

Price the ten-year operating cost before signing anything, including hosting, security maintenance, and support obligations under whichever regulatory regime applies to you.

Ask what happens at end of support, and decide it now rather than in year eight. It is a commercial and reputational question as much as a technical one, and the answer belongs in the product plan.

And use the scorecard rather than the graphic. Forrester has said plainly that the Leaders may not be right for you. Reweighting the criteria against your actual gaps is the whole value of the research in a category this heterogeneous.

Forrester does not endorse any provider named here, and tier placement should not be read as a recommendation to buy.