In Stay Sharp Episode 149, Product Memory: The Context Layer Behind Every Product, co-hosts Juliann Grant and Jonathan Scott talk with three-time guest Oleg Shilvitsky, PLM industry expert and CEO of OpenBOM. He returns to discuss a concept that he may have coined, “product memory,” and why it’s critical to understand and capture for your product.
All About the Context
Oleg describes product memory as a context layer without a specific scope, which can include everything from the history of product creation and decisions made about it, to associated customers and maintenance.
Oleg Shilvitsky, PLM industry expert and CEO of OpenBOM
“Product memory is becoming an enabler of organizations to start getting more intelligence about the products that they develop, maintain, sell.” To make AI useful, organizations have to feed it their own organizational knowledge, and a large part of that is product memory.
He explains, “[It] describes everything that is related to particular product, part, assembly, or entire family of products, everything that related to this product across the lifecycle or across the scope that you want to discuss.” More importantly it’s context that helps us answer the questions PLM alone can’t answer. Some of that information may be stored in other systems—like a back and forth discussion with a supplier that became a change order. The change order will end up in your systems of record, but the discussion and conclusions that led to it, which could include useful details that you want in years to come, wouldn’t otherwise be stored in PDM or PLM.
Jonathan suggests it may be easier to define product memory by what it’s not. Oleg agrees, noting first that product memory is not about data, but the information and decisions that happen around data. It’s also not a new system of record. “A system of record has an authority on some data that it’s originated and recorded like records,” he says. But unlike MRP, CRM, or PDM/PLM, context isn’t authoring anything. That means product memory isn’t a new name for PLM, because PLM is a system of records that keeps the history and changes of those records. Product memory is more universal. “To me,” Oleg says, “this context layer can be in the same way applied to PLM as it can be applied to CRM, as it can be applied to ERP. It can be applied to a maintenance system.”
The origins of product memory stem from three sources. The first is the need to address the “why” of the product. This is typically information we’re not capturing, “the information that sits in connections, in relationships, in the history of emails, in history of conversations, and everything else,” Oleg says. The second “parent” is the context graph, a technology that captures how or why a decision unfolded in a certain situation. Context provides guardrails, which are critical for AI, otherwise it’ll return hallucinations or irrelevant information. The third source is AI itself, for which product memory is important, not just nice to have. “We need to feed this AI with this information,” Oleg notes.
Managing the Product’s Context
Security of your product memory is obviously a concern. Oleg reminds us that mitigating risk is one of three factors that drive business value in PLM—see Stay Sharp Episode 111—along with controlling cost and increasing revenue. Fortunately, security is a process that companies have in place, and it should be followed for elements of product memory just as for your systems of record. “We can’t ignore security around product memory,” Jonathan says, “but if we are working on product memory and we’re thinking about security during the process, we can still get ourselves somewhere safe.”
Ownership of product memory is another consideration, and Oleg notes it starts simple and becomes more complex. An employee develops IP, creates drawings, makes products, even develops processes for change management or PLM—and all of those rights belong to the company. The skills an employee develops while doing so belong to the employee. Where it gets complicated is if AI or another tool can help the company capture the way the employee makes decisions, which they learned at the company, and then use it to make decisions like the employee does? He acknowledges the question raises ethical questions we don’t yet have answers for. “It’s a very, very gray space,” he says. “If there is something that can capture the way you’re making decisions, this is not clear to whom it belongs.”
Learn More About Product Memory
The full podcast contains more discussion and details on a variety of topics, including why Oleg says everything around us is a bill of materials, why the software business model is moving from paying for data to paying for outcomes, what Oleg will cover in the new book he’s writing on product memory, and more.
Be sure to check out Stay Sharp Episode 149: Product Memory: The Context Layer Behind Every Product and join us each week for a new podcast.
Follow the Razorleaf Podcast, Stay Sharp in Digital Engineering on:
