What We Learned from Customers in 2025

Oleg Shilovitsky
Oleg Shilovitsky
18 December, 2025 | 8 min for reading
What We Learned from Customers in 2025

When I look back at 2025, what stands out most is not a list of features or releases, but the amount of time we spent observing how customers actually work. Not how workflows are drawn on slides, and not how systems expect work to happen, but how people behave when real constraints show up.

We deliberately started paying attention to moments of friction. What happens when a project falls behind schedule. When supply constraints appear mid-design. When multiple disciplines need to make decisions at the same time instead of in sequence. When ownership is shared, unclear, or constantly shifting. These are the moments where theory breaks down and reality takes over.

In those situations, customers don’t stop working because the system says “no.” They find ways around it. They copy data out. They create parallel spreadsheets. They run side discussions in email or chat. From a software perspective, this often looks like “breaking the data.” From a human perspective, it is simply work continuing in the face of uncertainty.

What became clear as we analyzed real customer scenarios is that this behavior is not accidental or careless. It is a signal. Customers are not trying to bypass systems; they are trying to follow processes that are no longer linear or predictable. Engineering, manufacturing, procurement, and planning increasingly overlap. Decisions that used to happen in sequence now happen in parallel. Assumptions change midstream.

Traditional systems struggle here because they are built around stable states and clear handoffs. They assume that design comes first, then review, then sourcing, then execution. But in practice, those boundaries blur. People need to explore options, test alternatives, and make provisional decisions while downstream consequences are still unfolding.

When software doesn’t allow that kind of flexibility, users create it themselves and often at the cost of data integrity, traceability, and trust. Spreadsheets and ad-hoc tools become the pressure valves that allow work to keep moving.

In 2025, we made a conscious effort to treat these workarounds not as failures, but as clues. Instead of asking, “Why aren’t customers following the process?” we asked, “What process are they actually trying to follow?” That shift changed how we interpreted customer behavior and reshaped how we think about product data, collaboration, and planning.

The lessons that follow are not predictions about the future. They are observations drawn from how customers navigate complexity today—especially when work stops being neat, linear, and predictable.

Lesson #1 — Customers don’t fail at SSOT, they fail at shared workflow

Many teams we work with technically have a system of record. Their data is stored somewhere, controlled to a certain degree, and even sometimes versioned. Yet the moment multiple people need to work together in engineering, manufacturing, purchasing, the data such as a BOM, or PO is exported outside of the systems (eg. File Storage or even PDM system) to Excel.

What we learned is that this isn’t a failure of data accuracy. It’s a failure of shared workflow.

Systems of record (eg. PDM) are very good at answering the question “what is the latest version?” They are much less effective at supporting discussion, iteration, and alignment while decisions are still being made. Excel persists not because it is accurate, but because it is social. It tolerates ambiguity. It allows comments, side calculations, and what-if scenarios without ceremony.

Over time, it became clear that the real gap isn’t another source of truth. It’s the lack of a shared place where work can happen together before decisions harden. When that space doesn’t exist, people create it elsewhere.

Lesson #2 — PDM is necessary, but it’s not the whole product anymore

File control still matters. CAD and designs are important. Customers rely on it, and they should. But what we kept seeing is that file-centric thinking only solves part of the coordination problem. Then multiple CAD systems are coming for different disciplines (MCAD, ECAD, PCB). Then software comes (more often today), and companies are looking at how to navigate this level of complexity. 

The object that people actually coordinate around is not the file. It’s the BOM—enriched with attributes, alternates, sourcing information, costs, availability, and downstream constraints. That information rarely lives cleanly in one place, and it rarely changes in isolation.

As products become more multi-disciplinary, file control reaches its limits faster. Mechanical, electrical, software, supplier data, and planning assumptions all intersect at the BOM level. Customers showed us, again and again, that understanding impact no longer means opening a file. It means understanding relationships.

This isn’t an argument against PDM. It’s an observation that PDM alone no longer represents the full product reality teams are trying to manage.

Lesson #3 — ERP integration isn’t the goal; procurement context must live next to design intent

A surprising thing we noticed in 2025 is how rarely customers complained about the lack of integrations themselves. What frustrated them was what got lost in between.

Purchasing teams would make decisions without seeing design intent. Engineering teams would make changes without seeing supply constraints. Problems weren’t caused by missing data transfers, but by missing context at the moment decisions were made.

Customers weren’t asking for bigger integration projects. They wanted procurement questions to be answerable while design decisions were still fluid. They wanted engineering to feel the reality of lead times, pricing, and availability before changes became expensive.

What this taught us is that integration is not the end goal. Proximity is. The closer procurement context sits to design intent, the fewer late surprises teams face. Moving data is easy. Keeping meaning intact is much harder.

Lesson #4 — The real differentiator is the data model’s ability to absorb reality

As companies grow, reality gets messy. Variants appear. Alternates multiply. Supplier-specific parts creep in. Inventory differs by location. Custom attributes get added “just for this project.” None of this is unusual. It’s normal.

What customers taught us is that systems rarely fail because they lack features. They fail because their underlying models can’t absorb these exceptions without breaking or forcing redesigns.

The teams that struggled the most weren’t doing anything wrong. They were simply growing beyond the assumptions baked into their tools. Each workaround added friction. Each exception increased fragility.

The systems that held up best weren’t the most rigid. They were the ones that could adapt without forcing users to fight the model. Flexibility here isn’t about customization for its own sake. It’s about letting reality exist without punishment.

Lesson #5 — Integration matters less than continuity

Perhaps the most important lesson of 2025 was this: customers don’t struggle because systems aren’t connected. They struggle because the story keeps getting lost.

Decisions get made, but the rationale disappears. Changes happen, but the history fragments across tools. Context lives in emails, meetings, and memory rather than in the product structure itself.

Customers rarely said, “We need more integrations.” What they actually wanted was to stay oriented over time. To understand why something changed, who made the call, and what it impacts—without reconstructing the narrative from scattered artifacts.

Continuity is different from synchronization. Data can flow perfectly and still leave people confused. Continuity is what allows teams to move forward without constantly looking backward to figure out what they missed.

A Note on AI — Product Memory is a Key

Throughout 2025, customers were increasingly curious about AI. But what they asked for was not hype or automation for its own sake. They wanted fewer interruptions in their daily work. Fewer moments of “where is the latest?” Fewer repeated decisions that had already been made once before. Faster answers to sourcing questions. Fewer mistakes at handoffs.

Listening to those requests, it became clear that AI is often discussed backwards. The real challenge is not intelligence. It is a memory (about what was done, and what exists).

AI cannot meaningfully assist with engineering or manufacturing work if it has no understanding of the product itself. Without a connected knowledge base – decisions, relationships, change history, and context AI becomes little more than a chatbot layered on top of fragmented systems. Instead of reducing friction, it sends users to a guesswork and not clear conclusions.

What emerged for us in 2025 is that AI only becomes practical when the product development and manufacturing organization has “memory” about what they did. When decisions are captured close to the data they affect. When relationships persist across changes. When history is not lost at every handoff between teams or tools.

This is not something customers explicitly asked us to build. It is something we realized needs to exist if AI is ever going to help with the kinds of problems customers actually care about. Without product memory, AI has nothing solid to reason over. With it, intelligence becomes incremental, grounded, and useful rather than speculative.

Conclusion

Taken together, these lessons shaped not only how we think about collaboration and data, but also how we think about the role intelligence can realistically play in product development.

The future isn’t about controlling data more tightly or adding intelligence on top of broken data foundations. It’s about supporting how people actually work together around evolving products and preserving the knowledge that work creates along the way.

Customers taught us that work these days is multi-disciplinary, iterative, social, and rarely linear. That decisions are provisional until they aren’t. That context matters as much as correctness. And that systems succeed not when they enforce perfection, but when they help teams stay aligned and focused on the speed as reality shifts.

That perspective is what we’re carrying into 2026. Not as a strategy, but as a discipline: keep watching where work breaks down, and learn from it.

In many ways, that’s been the most valuable outcome of 2025.

As we are moving into the Holiday Season, we can see it as an opportunity to learn. OpenBOM gives you a perfect opportunity to do so by providing an instant trial of OpenBOM – you can REGISTER FOR FREE and check it out. 

Best, Oleg 

Related Posts

Also on OpenBOM

4 6
15 January, 2026

The manufacturing companies are not what they used to be. In fact, there often isn’t a single company anymore. The...

14 January, 2026

One of the goals behind the new OpenBOM licensing model is very simple:make it easy to start, even if you...

13 January, 2026

Every engineering team and manufacturing company is using Excel. For years, we thought Excel was a technical problem. But I...

12 January, 2026

At OpenBOM, design integrations are not treated as optional add-ons or isolated utilities. They are a core part of how...

9 January, 2026

I’ve spent a lot of time this week rereading notes from past conversations about ECOs, AI, and collaboration, and one...

8 January, 2026

Engineering change is quietly outgrowing the systems we built to control it. On paper, ECO and ECN processes still look...

7 January, 2026

Boston, MA — January 2026 — OpenBOM today announced a new pricing and licensing model for 2026, designed to lower...

7 January, 2026

When customers succeed, their products grow. And when products grow, product data grows with them. Over the past year, we...

6 January, 2026

How product memory transforms engineering workflows to introduce AI agents  When I talk to engineering and manufacturing teams, the conversation...

To the top