Part 3 of my PTC Next 2026 series. In Part 1, I asked whether “intelligent” PLM is new architecture or a new label, and ended on a concession a PTC rep made at the booth: the layer that would capture the reasoning behind product decisions mostly isn’t built yet. In Part 2, I tested the two-layer architecture and left a thread open. This article is that thread — and after sitting in Ryan Orwoll’s (VP Product Management) dedicated Jetstream breakout, I have a lot more to test it with.
Of everything PTC unveiled at PTC Next 2026 in Chicago, one announcement keeps pulling me back, and it isn’t the one with the most agents or the broadest portfolio reach. It’s the simplest product the company shipped.
In Part 1, I pressed a rep on whether I could point “intelligent” PLM at my company’s data and get back a real diagnosis. He didn’t bluff. He said that becomes possible only once the reasoning behind product decisions is actually captured in connected repositories, and he acknowledged that road isn’t paved. I’ve thought about that sentence more than anything else from the event, because it’s the most honest thing anyone said. Going back through my notes from the Jetstream breakout, I think Jetstream is the first stretch of paving.
So Jetstream deserves its own article — not because it’s flashy, but because it’s the most structurally consequential thing PTC announced. And the reason it earns a whole piece is that it isn’t one thing. Read it carefully and it’s three things at once, arriving on different clocks: a collaboration layer and a context layer, both shipping this fall, and — on a longer horizon PTC was open about — the beginnings of a product-data layer. Those aren’t three features bolted together. They’re the same architectural bet seen from three angles. Let me take them one at a time.
Dimension One: Collaboration Becoming Traceable Product Work
Start with the problem, above PTC, because the problem is industry-wide and older than any product.
For two decades we have been very good at one thing: putting product data into controlled systems. Items, BOMs, revisions, release states, requirements links — all of it sits inside a managed source of truth. But the decisions about that data have almost never happened inside those systems. PTC’s own framing in the breakout was blunt about how this actually looks today, and I recognized every word of it.
Orwoll described the current state as a “wild west”: no standard tool, no standard process. Teams stand up Google Drives to share links, email CAD as attachments, screen-share over Teams and Zoom, move files by FTP, or reluctantly invite outsiders into Windchill — when they can invite them at all. The image that stuck with me was a customer’s literal workflow he relayed: a design engineer opens Creo or SolidWorks, rotates the model to the right view, takes a screenshot, drops it into PowerPoint, marks it up with PowerPoint’s tools, screenshots that, emails it out, and hopes feedback comes back. That is how engineering decisions get made at a lot of very serious companies. And it spans the whole org: internal design and cross-discipline review (mechanical to electrical to software), downstream subject-matter experts who don’t author the CAD but whose input is decisive (manufacturing, service, procurement, sustainability), collaboration on documents and requirements before any 3D exists, and the entire external world — joint development, co-design, design-for-manufacturing, RFQs, contract bidding.
Orwoll was precise about what that costs, and it’s the same list I’ve been writing for years: no traceability of who has what, no governance, no associativity between a piece of feedback and the thing it was about, and real IP and security exposure every time a file leaves by email. His summary of the damage is the sentence that matters most for this whole series. When work happens this way, he said, the things that get lost are: what was the context, why did someone say that, are we aligned on the actual decision, and what was the reasoning behind it. All gone, because there was never a tool to hold them. In a regulated environment, you can’t even prove the review happened.
That is the gap, named by the vendor: the system records that a change was approved; the deliberation that produced it evaporates. And it points at the shift the whole industry is moving through, which is bigger than Jetstream: product collaboration is migrating from messages, meetings, screenshots, PDFs, and emails into traceable product work connected to product data. For most of PLM’s history the frontier was getting the data under control. The next frontier is connecting the collaboration back to the data — so the conversation about a part lives attached to the part, not in someone’s inbox.
I’ll keep this dimension tight, because on its own “better collaboration” is the least interesting way to describe what’s happening. Collaboration tools are not scarce. What makes Jetstream architectural is the second dimension.
Dimension Two: Context, Tied to the Data Source
A comment in an email is context with nowhere to live. A comment tied to a specific 3D view, on a specific edge or face, on a specific version of a file, inside a stream that publishes its result back to the record — that is context that becomes part of the product’s data. The difference between those two is the entire point, and the breakout demo made it concrete.
The scenario was an excavator arm. Scott, a manager, needs a supplier to confirm whether a pin is an off-the-shelf part. He opens a room, uploads the assembly, narrows the 3D view down to just the pin, and leaves a comment attached to it. He invites Pat, the supplier, by email; Pat clicks the link, and the system drops him onto Scott’s exact view. Pat measures the pin — 174 mm, not a size he stocks — and replies with the two options he does make, 170 or 175. Cody, the engineer, clicks the same comment, lands on the same view, sees the constraint, and adjusts the surrounding parts to take the 175 mm pin. A small example, but every comment in it is anchored: to the geometry, to the version, to the person. Nobody is asking “which file were you looking at,” because the file is in the question.
That anchoring is the architecture. Comments are version-aware, so the old nightmare — was this feedback on the latest revision or two versions back, which we already resolved — stops being a guessing game. And because PTC built a common, cross-product commenting and notification service, those comments aren’t trapped in Jetstream: subject to access control, they surface in Windchill and in Creo. Orwoll’s example was the engineer opening the file in Creo and simply seeing the list of changes the supplier asked for, without hopping between tools. The conversation follows the data into the authoring environment.
Then the loop closes back to the record, and this is the part that answers the booth concession directly. Jetstream is wired to Windchill through a Windchill extension — hooks appear on a part’s detail page, a CAD document, a change object — so a user can push the affected objects out to a room, run the collaboration, and pull the outcome back. What comes back isn’t just an approval. In Orwoll’s words, it’s capturing the decisions and the intent behind those decisions and attaching that to the product data — the full discussion or an AI summary, landed on the change request, or on the part itself, for history and auditability.
I want to underline what PTC is not claiming, because the discipline matters. Orwoll was explicit that Windchill — PLM — remains the source of truth; Jetstream is not a data-storage or data-management system, and you don’t author changes in it. You go back to Creo, SolidWorks, or Word to make the edit. The record stays in the record. In the terms I used in 2022, Windchill stays the system of record while Jetstream becomes the system of engagement and intelligence layered on top of it. What Jetstream keeps is the part that used to die in an inbox: the rationale, the why. As I noted in Part 2, the very existence of a new product built to capture decision rationale is the quiet refutation of the other PTC slide that claims the foundation already captures “decision intent.” You don’t build this if the vault already held it.
Dimension Three: Toward a Product-Data Layer
The first two dimensions are what Jetstream is this fall. The third is where it’s pointed, and the right way to read it is as a direction, not a finished product.
Start with the architecture Orwoll described, because the foundation is real today even if its destination isn’t. Jetstream is a standalone, cloud-based, multi-tenant SaaS product. He said it plainly: it is not a Windchill product, it requires no other PTC product to run, it is its own thing. Sign-in is by email — a new external collaborator goes from invitation to viewing data in under a minute, no install, no provisioning. It is CAD- and format-agnostic: any CAD, any file type, plus PDFs, Word, PowerPoint, 2D and 3D. Work happens in rooms — named, access-controlled spaces with revocable membership — with room templates on the roadmap for structured processes like design review, supplier management, and PPAP-style approval. It integrates with PTC products and, over REST APIs, with third-party systems.
Those characteristics are what make Jetstream more than a collaboration tool. A standalone, multi-tenant, cloud-native place to hold and share any product data, reachable by anyone with an email and open at the edges over APIs, has the shape of a platform, not just a feature. In Part 2 I described it as Onshape for product data rather than Onshape for CAD, and the architecture in front of me holds that up.
PTC was also open about where this goes next, and I want to capture the notion accurately without over-reading it. Asked in the breakout whether Jetstream could serve teams that just need lightweight data management, Orwoll pointed to a planned 2027 direction: a version of Jetstream that adds cloud data-management and PDM capabilities, so a team could begin with data management and grow into the collaboration capabilities over time — the same product, with licensing deciding what’s switched on.
That is genuinely a forward-looking direction, not something shipping now, and it’s far enough out that what it actually becomes is something next year will show, not this one. So I’ll hold it lightly. What I can say from today’s architecture is that the foundation is built to support it: cloud, multi-tenant, connected, reachable by anyone, open at the edges. And it’s a direction worth naming, because it points Jetstream at a population enterprise PLM has historically served least well — small teams, suppliers, contractors, the mid-market, for whom a browser-based, email-accessible place to manage and share product data is an on-ramp the enterprise stack never offered. How much of a product-data layer Jetstream grows into is, fairly, a 2027 question. The architecture just makes it a credible one.
The Same Layer, Approached From Two Directions
Step back to the industry level, because this is bigger than PTC and bigger than any single launch.
There is a layer forming in this industry — call it the connected product-data-and-context layer: the place where product data from many systems comes together, where decisions get made and captured, where an AI agent can reason across the lifecycle instead of inside one silo. That layer is being approached from two directions at once.
One direction comes down from the enterprise system of record. An incumbent owns the vault and the largest installed base in its category. It builds a new cloud, multi-tenant layer to capture the context the vault never held, reaches outward to suppliers and partners by email, and points that layer, over time, toward cloud data management a smaller team could adopt on its own. That is Jetstream’s direction: an incumbent extending down from the record and building outward toward the people and the data the record couldn’t reach.
The other direction comes outward from connected product data itself. Start cloud-native and multi-tenant on day one. Federate CAD, PDM, and PLM data you don’t own rather than demanding everything move into your database. Reach contractors, suppliers, and the mid-market first, because they were never served by the enterprise stack, and add enterprise depth from there. Independent approaches have been building toward this layer from the opposite starting point for years.
The thing worth naming is that these two directions are converging on the same architecture: multi-tenant, connected rather than owning, context captured where the work happens, open to records and tools the platform doesn’t control, with a small team able to start and grow. The starting points are opposite — one descends from the enterprise record, the other ascends from connected data — but the destination looks increasingly shared. And when an incumbent with the deepest installed base in the industry points in that direction too, the convergence stops looking like any one vendor’s product plan and starts looking like where the layer itself is heading.
There’s a sharper way to see the convergence, and it doubles as the test of whether the layer is real. A genuine layer of this kind has to be open to systems its builder doesn’t own. PTC gave the hooks itself: REST integration with third-party products, a common cross-product commenting service, and a common agent architecture where agents from one product can talk to another. If that openness is real, then the same plumbing that lets Jetstream sit beside Windchill is the plumbing that would let anything else connected sit in the same thread — a competitor’s system of record, or an independent connected-data platform built from the other direction, pushing and pulling rooms, sharing comments, exchanging context. The door PTC describes is, architecturally, a door that opens both ways. The clean way to prove the layer is real is to show something PTC didn’t build participating in it as readily as Windchill does. The clean way to prove it’s a moat is for that never to happen. I’ll keep that challenge from Part 2 standing.
Why the Layer Has to Remember, Not Just Capture
Naming the layer this way surfaces the question the whole series has been circling — and the one I’m deliberately not going to answer in this article, because it deserves its own.
Orwoll gave the cleanest statement of the dream I heard all event. The reason to capture rationale, he said, is so that when someone comes back a year or two later and says “we should really do it this way,” you can answer: we had that conversation, here are the people who were in it, and here’s why we decided what we decided — instead of relitigating the same debate forever. That is exactly right, and it’s the most convincing piece of PTC’s strategy.
But capturing the why at the moment of decision is not the same as keeping it usable across the life of a product. A rationale captured today and unfindable in three years — across a tool migration, a supplier change, a reorganization — isn’t context anymore; it’s archive. The record has always remembered what changed. The hard, unsolved problem is making the why durable: retrievable, connected, and reasoned-over years later, across companies and across tools, long after the room that produced it is closed. That’s a question about what this layer actually remembers, and what it takes to make captured reasoning last. It’s the natural next step in this series, and I’ll take it up on its own.
What Is My Conclusion?
Jetstream is the one announcement at PTC Next 2026 that was building the road — the first paving of the captured-reasoning layer a PTC rep acknowledged, at the booth, mostly didn’t exist yet. That alone makes it more interesting than the products with bigger billing.
Read through three lenses, it’s a single coherent bet arriving on different clocks. Two of the three are here now: collaboration that’s traceable and context that’s tied to the data source both ship this fall, and together they answer the booth concession honestly. The third — a product-data layer — is the longer horizon. PTC has pointed toward it for 2027, and I’d put it exactly there: a direction the architecture already has the shape to support, whose real form next year will show, not this one. I name it now not to overclaim it, but because the foundation makes the direction credible, and the direction matters.
The deepest thing this announcement points at isn’t really about PTC at all. It’s that one layer is being built from two directions: incumbents extending down from the enterprise record, independents building outward from connected product data, converging on the same multi-tenant, connect-don’t-control shape. When the largest incumbent points the same way, the convergence stops being a vendor story and becomes the industry’s. The question I’ll keep watching — fairly, and over time — is whether the layer stays genuinely open, so that records and platforms PTC doesn’t own can live in the same thread alongside Windchill.
What do you think: is the product-data layer of the next decade something a single incumbent builds down from its vault, something independents build outward from connected data, or the place where those two roads finally meet?
Just my thoughts…
Best, Oleg
Disclaimer: I’m the co-founder and CEO of OpenBOM, an AI-native collaborative digital thread platform connecting engineers and manufacturing teams, built on federated CAD-PDM and PLM architecture. I argue for connected, two-layer thinking — record plus context — built outward from connected product data, for a living. So on the question of which direction the product-data layer gets built from, my opinion can be unintentionally, and probably intentionally, biased.
Frequently Asked Questions
What is PTC Jetstream? PTC Jetstream is a standalone, cloud-native, multi-tenant SaaS collaboration platform introduced at PTC Next 2026. It lets internal and external teams share, review, and capture traceable feedback on product data, ties comments to specific 3D views and file versions, and integrates with Windchill, Creo, and the broader portfolio — as well as third-party systems over REST APIs — while also running entirely standalone. General availability is targeted for fall 2026.
Does Jetstream replace Windchill as the system of record? No. PTC was clear in the Jetstream breakout that Windchill (PLM) remains the source of truth and that Jetstream is not a data-storage or data-management system today; authoring still happens in Creo, SolidWorks, or Word. PTC has also indicated a 2027 direction that would add cloud data-management / PDM capabilities to Jetstream itself — a longer-horizon item whose actual shape will be clearer next year.
Why call Jetstream the most important announcement when it’s the simplest product? Because architecture matters more than feature count. Jetstream is the first PTC product aimed directly at capturing the decision rationale — the why — that the system of record never held, which is the exact gap PTC’s own representatives conceded wasn’t yet addressed. Its importance is structural, not cosmetic.
Is Jetstream a collaboration tool or a product-data platform? Today it’s both a collaboration layer (traceable feedback) and a context layer (rationale tied to the data source), and both ship this fall. On a longer horizon, PTC has pointed to a 2027 direction that adds cloud data-management / PDM capabilities you could adopt on their own and grow from — which is why I describe a third, future-facing dimension: the beginnings of a product-data layer. Its actual shape is a 2027 question; today’s architecture mainly makes the direction credible.
What does “approached from two directions” mean? The same connected product-data-and-context layer is being built by incumbents extending down from the enterprise system of record, and by independent platforms building outward from connected product data. They start from opposite points and converge on the same architecture: multi-tenant, connect-don’t-control, and open to records and tools the platform doesn’t own.
