Turning the BOM into a Shared Workspace for Release & Change Readiness

In the previous article, I introduced OpenBOM Review as a way to bring comments and discussions from emails to the data (BOM) context. But as we started using it in real workflows, it became clear that the real problem is not actually commenting on the BOM. Comments and tasks are part of the process to get the BOM ready for release across multiple engineering disciplines, procurement, and production.

To accomplish the goal of helping the team to do connected work, we are developing a way to turn product structures into shared spaces for coordination and actions. The motivation was simple and familiar to anyone working in engineering or manufacturing: too many important conversations still happen outside the systems that hold product data. Emails, spreadsheets, chat threads, and shared links quickly lose context, ownership, and history.

As we started using these capabilities internally and talking with early customers, something else became clear. Comments alone are only the first step. The real opportunity appears when the BOM is no longer treated as something we comment on occasionally, but as the place where work itself is coordinated. Not just discussion, but actions. Not just notes, but tasks. A shared space where engineering, procurement, and production planning can align day-to-day activities using the same live product structure.

The BOM as a Collaboration Surface

When I look closely at how teams work around a BOM today, the pattern is almost always the same. The BOM is reviewed, exported, copied, and discussed — but the actual work happens somewhere else. Tasks live in project management tools. Supplier questions are resolved in email. Cost analysis ends up in spreadsheets. Files are exchanged through links that quickly lose meaning once something changes.

In OpenBOM Review, we started approaching this problem from a different angle. Instead of asking how to attach collaboration to a BOM, we asked a more fundamental question: what if the BOM itself became the surface for collaboration? A shared, live product structure where actions, decisions, and responsibilities stay connected to the exact data they refer to — not as side annotations, but as part of how teams coordinate work every day.

This shift sounds subtle, but it changes everything. When the BOM becomes the collaboration surface, context stops leaking. Conversations stay anchored to the product. Actions remain tied to the data that triggered them. And teams no longer have to reconstruct intent weeks later when it matters most.

A Complete Product Structure as the Foundation

The first requirement for meaningful collaboration is completeness. Over the years, I’ve seen countless workflows break down because teams were not looking at the same structure. One group works from a filtered BOM. Another relies on an Excel export. A third references a PDF generated weeks ago. Everyone thinks they are aligned, until they are not.

OpenBOM Review starts with a complete, live product structure. The full hierarchy is preserved, and all relevant data — items, files, suppliers, costs — remains connected. This matters because collaboration is rarely about a single row in a table. It is about understanding how a change in one place affects everything else around it.

When procurement validates a supplier, they need to see the same structure engineering is releasing. When production planning checks readiness, they need visibility into the same components, revisions, and supporting files. A complete product structure creates a shared reference point, so teams don’t spend their time rebuilding context instead of making progress.

Multiple Teams, Working at the Same Time

Real work does not happen sequentially. Engineering does not “finish” before procurement starts, and procurement does not wait for production planning to catch up. Everyone moves in parallel, often under time pressure, and coordination becomes the real challenge.

OpenBOM Review is designed for this reality. Multiple users can access the same BOM at the same time, perform their activities, and see updates as they happen. Instead of locking structures to prevent overlap, we focus on visibility and history. Teams can see who did what, when it happened, and how the product structure evolved.

I’ve found that this approach replaces a familiar set of anxious questions — “Is this the latest version?”, “Who changed this?”, “Did anyone already review that?” — with shared awareness. The goal is not to eliminate change, but to make it visible and understandable. When everyone sees the same data and the same activity trail, coordination becomes much easier.

From Comments to Actions: Contextual Tasks

Comments are a natural starting point for collaboration. They allow people to ask questions, flag issues, and capture intent. But at some point, discussions need to turn into actions. Someone has to upload a file. Someone has to confirm a supplier. Someone has to review cost impact or validate alternates.

This is where many teams struggle. Traditional task systems are generic by nature. Tasks quickly lose their connection to the data that triggered them. A task might say “Review supplier,” but which supplier? In which BOM? For which revision? That context often lives somewhere else — if it exists at all.

In OpenBOM Review, tasks are contextual by design. They are created directly on specific data: a part, a supplier, a cost field, a file, or an entire BOM node. When a task is connected to the exact element it refers to, ambiguity disappears. The person assigned to the task does not just see a description — they see the data itself, in context, inside the product structure.

This may sound like a small detail, but it changes how work flows. Tasks stop being abstract to-do items and become concrete steps tied to real product decisions.

Coordinating Work Across Functions

Contextual tasks become especially powerful when multiple roles are involved. An engineer can request a supplier confirmation directly on a part. Procurement can respond by validating options and updating cost or lead time. A production planner can check readiness and flag issues before release. All of this happens on the same BOM, without exporting data or re-entering information elsewhere.

This kind of coordination is critical during BOM release preparation and ECO execution. Many delays and errors do not come from disagreement, but from fragmentation. Work is spread across tools, and no one has a complete picture of what is done and what is still pending.

OpenBOM Review does not replace formal lifecycle control or ECO processes. Instead, it supports them by making sure the work that leads up to those decisions is visible, assigned, and completed in context. It creates a missing layer between design intent and formal change control — a place where teams can align before committing.

Seeing It in Action: A Preview Video

Concepts like contextual collaboration are easier to understand when you see them in practice. To make this concrete, we are sharing a short preview video that walks through OpenBOM Review and task management on a live BOM. The video shows a complete product structure, comments and tasks created in context, and multiple users interacting with the same data.

This is an early look at capabilities that are still evolving, but it reflects the direction we are heading. Our focus is not on adding another task tool, but on making the BOM itself a place where coordination naturally happens.

Why Contextual Task Management Matters

When tasks are disconnected from data, coordination becomes fragile. Information gets duplicated. Intent gets lost. Teams spend more time reconciling than moving forward. I’ve seen this pattern repeat itself across companies of all sizes.

Contextual task management changes that dynamic. By keeping actions, discussions, and responsibilities tied to the BOM, teams gain clarity and momentum. Fewer handoffs are missed. Fewer assumptions go unchallenged. Decisions are made with shared understanding.

The real value is not just efficiency. It is confidence. Confidence that everyone is working from the same structure. Confidence that actions are visible. Confidence that decisions are grounded in live, shared data.

An Invitation to Shape What Comes Next

OpenBOM Review and contextual task management are being built in close conversation with customers. We are intentionally sharing these previews early, because real workflows matter more than polished feature lists. If this approach resonates with you — or if you see gaps we should address — I invite you to connect with us and share your perspective.

The BOM has always been central to how products are built. We believe it can also become central to how work gets done.

BOM Review will be soon available for early preview. Want to discuss how to participate in OpenBOM Review Beta? Contact us directly. 

Best, Oleg