Manufacturing solved a problem most other functions haven't admitted they have yet.

Walk into a modern factory and you'll find engineers running "what happens if" scenarios against a live model before they touch the physical line: a new product introduction, a schedule change, a different supplier, all tested in software first. That practice is now unremarkable in manufacturing. McKinsey's research on factory digital twins describes them as real-time virtual representations that let manufacturers simulate scenarios and understand impact before committing resources on the floor, and most senior manufacturing executives surveyed can now name a practical use case in their own operations.

Now walk into the average product organization or operations function outside manufacturing. Ask how they decide whether to fund a major platform migration, restructure a service delivery model, or greenlight a product line extension. In most cases, the honest answer is: a spreadsheet, a set of assumptions from the last planning cycle, and a leadership team's confidence that this time the estimate is right.

That gap is the interesting story. Not "digital twins are cool technology." The interesting story is that one part of the enterprise normalized simulating a decision before paying for it, and most of the rest of the enterprise still treats that as science fiction.

What actually changed

The term digital twin started small. A virtual model tied to a physical machine, fed by sensors, used to predict wear or failure before it happened. That's still the most common use case, which is why the whole concept still feels welded to a factory floor in most people's minds.

But strip away the machine and look at what's actually doing the work. It's three things. A live feed of real data. A model good enough to represent how the system actually behaves. And the ability to run a scenario against that model before it happens for real. None of those three things require a physical asset. They just require a system worth modeling and a decision expensive enough that testing it first is worth the trouble.

Gartner has followed that logic well past the factory. Their research on the digital twin of an organization extends the whole concept to the enterprise itself, arguing that enterprise architects can use it to catch the kind of local optimization that quietly wrecks overall performance, the classic problem where every team makes a smart-looking decision in isolation and the sum of those decisions is worse than any one of them alone. That's not a manufacturing problem. That's a problem every large company has.

Network operations teams got there early, mostly because the cost of guessing wrong is impossible to hide. Gartner has found that teams modeling configuration and firmware changes before pushing them live can cut unplanned outages by as much as 70% through 2028. Same mechanism as the factory floor. Test the change against the model first. Catch the failure before it's live. Ship with confidence instead of crossed fingers.

Pharmaceutical companies are running a version of the same play, just earlier in the pipeline. Peer reviewed research on drug development describes digital twins being used from early discovery all the way through continuous manufacturing, precisely because a wrong decision late in that process is brutally expensive, and simulation lets teams catch it while it's still cheap to fix.

Look across all three of those examples and a pattern shows up every time. Nobody adopted this because it was trendy. They adopted it because being wrong cost too much, the system was measurable enough to model, and testing first became the obvious call rather than a bold one.

Where the conventional approach breaks

Most product and operations planning outside these domains runs on a different model entirely: build a forecast, get it approved, commit budget, and find out over the following two to four quarters whether the forecast was right. That approach isn't lazy.

It isn't even wrong, exactly. When you don't have a live model of the system you're planning against, a forecast built from history and good judgment genuinely is the best tool available. People aren't choosing the spreadsheet because they're careless. They're choosing it because for a long time, it was the only real option.

The uncomfortable part is that "the best available tool" quietly stopped being true for a lot of organizations, and nobody sent the memo. The data that would feed a real simulation, system telemetry, delivery metrics, cost and capacity numbers, customer usage signals, already lives somewhere in most enterprises. It's just scattered across a dozen systems that were never built to talk to each other. Nobody built the connective tissue, the "digital thread," that would turn all that scattered data into something a model could actually use.

That's the real barrier, and it deserves to be named precisely, because it isn't a technology problem anymore. Simulation engines and scenario modeling and even AI assisted forecasting are mature and increasingly within reach. What's actually missing in most non-manufacturing organizations is the unglamorous plumbing underneath all of it. Consistent data definitions. Feeds that update in near real time instead of a quarterly export. An architecture that treats operational and product data as one connected system instead of a stack of departmental reports nobody cross references.

There's a good proof point for this sitting in a corner of the tech world most product leaders never think to look at. Our partner Frenos builds this exact kind of connective layer, just for industrial and operational technology environments. They take firewall configurations, asset inventories, and known vulnerabilities, the kind of information that normally lives in a dozen disconnected tools, and turn it into a single, continuously updated digital twin of the network. Work that used to mean physically scanning live industrial equipment or flying in outside consultants to hand map attack paths now happens as a simulation against that twin, testing exactly how an intrusion would move through the environment without anything ever touching production.

What makes that example worth mentioning isn't the security angle. It's what it proves about the barrier itself. Frenos didn't win by building a better simulation engine. That technology already existed. They won by doing the unglamorous integration work first, pulling fragmented, disconnected data into one coherent picture the simulation could actually trust. That's the same digital thread problem sitting unsolved in most product and operations organizations today. The hard part was never the simulation. It was earning the right to trust what you're simulating.

What this costs when it's missing

None of this shows up as a single dramatic failure. It shows up as capital quietly committed against assumptions that were already stale by the time anyone acted on them. It shows up as rework, six months later, when a platform decision built on a static forecast collides with how customers actually use the thing. It shows up as a planning cycle that moves at the speed of the next budget meeting instead of the speed the business actually needs.

The underlying issue is one of visibility and accountability. Without a model of the whole system, decisions that look smart in isolation quietly undermine the organization's real performance, and nobody notices until the damage is already spread across three different teams' numbers.

There's a slower cost too, easier to miss because it doesn't show up on any single report. Call it decision latency. When testing an idea means waiting for the next planning cycle instead of running it against a model this week, organizations don't just make worse decisions. They make fewer of them, because the cost of finding out feels too high compared to just committing and hoping it works out.

A better way to think about it

The question worth asking isn't "should we build a digital twin." That question sends everyone chasing a technology purchase and a proof of concept that quietly dies six months later. The better question is simpler and harder to answer honestly. Where in our product and operations decisions is the cost of being wrong high enough, and the system measurable enough, that testing it first would actually change what we approve?

That question does two useful things. It stops people from treating this as something only manufacturing or IoT gets to have, and it forces an honest look at whether the underlying data can even support a real model, instead of jumping straight to buying simulation software and discovering six weeks in that the data behind it was never trustworthy to begin with.

What to ask your teams

A few diagnostic questions are more useful here than a framework slide. Where have we committed significant budget in the last two years based primarily on a static forecast, and how far off was that forecast once real data came in? Do we have a connected, real-time view of the systems involved in that decision, or is our "data" actually a set of disconnected reports built for different audiences? If we could test the decision against a live model before committing, would leadership actually act on an unfavorable result, or would the model just become one more input that gets overruled?

That last question matters more than it sounds like it should. Simulation only pays for itself if an organization is actually willing to change a decision because of what it shows. We've watched plenty of organizations build sophisticated models and then commit to the original plan anyway, because the culture treats the forecast as a formality rather than a real gate. In those cases, the model isn't a decision tool. It's expensive theater.

What this means going forward

Manufacturing didn't get here because factories are somehow more sophisticated than product teams or operations groups. They got here because a bad decision on the floor was always visible, always expensive, and always someone's job to explain by Friday. That same cost exists everywhere else in the business. It's just been easier to ignore, because a bad platform bet or a mistimed operational shift doesn't show up until a P&L review two quarters later, long after anyone remembers exactly which assumption was wrong.

The organizations that figure this out next won't be the ones who go shopping for digital twin software. They'll be the ones willing to build the unglamorous data architecture underneath it first, ask themselves honestly whether their culture would actually act on a simulation that told them no, and then go looking for the handful of high stakes decisions where testing first is genuinely worth the effort. That's a smaller project than "get a digital twin." It's also harder, and it's the one that actually changes how the organization decides.

None of that is a project most teams can figure out on nights and weekends alongside their day jobs. Knowing which decisions are worth modeling, untangling the data sitting in a dozen disconnected systems, and being honest about whether your organization would actually act on an answer it doesn't like usually takes an outside perspective that's done it before. If you're trying to figure out where to start, TSG spends a lot of time in exactly this kind of work, and we're always happy to talk through what it might look like for your organization.