Why Product Definition Starts Before CAD in Engineering Projects

When a new project begins, nothing is designed yet.

• There is no finalized BOM

• No approved drawings

• No structured dataset 

Instead, there are conversations. Sales, project managers, and engineers come together to interpret a request. They compare past projects, evaluate constraints, estimate costs, assess risks, and align on what is even possible.

This phase defines everything that follows. And yet, it is the least structured part of the entire process.

The Invisible System Behind Every Project

At this stage, information is everywhere.

Spreadsheets. Meeting notes. Emails. ERP data. Reference designs in Vault.

There is no single place where product definition actually lives.

Instead, teams operate inside a kind of virtual table. Information is collected, discussed, interpreted. Decisions are made, but rarely captured in a way that connects to execution.

The result? A phase that drives critical decisions… but leaves no structured trace.

Most engineering inefficiencies don’t start in design. They start in unstructured decisions. 

Why Documents Are Not Enough

Most teams try to solve this with shared folders or collaboration tools. It helps. But only on the surface. Because what defines a project is not just documents. It is:

• Delivery dates
• Costs
• Responsibilities
• Risks
• Dependencies

These are not files. They are decisions. And when they are buried inside documents or scattered across systems, they lose context and visibility.

Turning Conversations Into Structure

This is where a different approach starts to matter. Instead of storing information, you structure it.

Instead of documenting outcomes, you manage the process that creates them.

With Autodesk Fusion Manage, product definition becomes something you can actually see and work with:

• Information exists as structured data, not hidden inside files
• Processes are defined, not improvised
• Responsibilities are clear, not assumed

Now the early phase is no longer informal. It becomes part of the system.

From Discussions to Decisions

Defining a machine or plant is not a single action. It is a sequence.

Inputs are collected. Options are evaluated. Scope is aligned. Engineering is prepared.

When this is structured:

• The current state is visible
• Missing inputs are visible
• Next steps are visible

Work moves forward because it is clearly defined. Not because someone followed up.

Working Where Decisions Actually Happen

In real projects, discussions are rarely abstract. They happen on designs.

Teams review previous CAD models, compare alternatives, and adapt existing solutions. That is where the real understanding happens.

Instead of separating discussions from engineering data, they need to happen directly on it.

With integrated access to Vault data, teams can:

• Review designs in context
• Annotate directly on models
• Capture decisions where they matter

No switching tools. No lost context.

Managing State, Not Just Files

Versioning files is not enough. Because in early phases, information is fluid.

Ideas evolve. Assumptions change. Options are explored.

What teams actually need is clarity:

• What is still under discussion?
• What is agreed?
• What is ready to move forward?

Lifecycle states bring that clarity. They turn uncertainty into visible progress.

Starting Without a Full BOM

At the beginning, there is rarely a complete BOM. What exists instead is a partial structure:

• Top-level assemblies 

• Key machines in a plant 

• Specific components that must be used 

• Proven technical solutions from previous projects

That is enough to guide decisions.

By capturing this early structure, teams create a foundation that evolves naturally into the final BOM.

Not a replacement. A starting point.

From Definition to Execution

What is defined early does not disappear. It grows. It becomes:

• The basis for engineering
• The reference for execution
• The starting point for future projects

This is where continuity is created. And where most teams lose it.

Why Meetings Feel Heavy (And How That Changes)

When nothing is structured, coordination becomes the system.

Meetings are used to:

• Understand status
• Assign work
• Decide next steps

Emails often become the default way to keep everyone aligned, but this is not real progress. It is a workaround for missing structure. When product definition is managed in a structured way, this dynamic changes.

Meetings are no longer spent figuring out what needs to be done or who should do it. Instead, they become focused moments where teams review, discuss, and make decisions that move the project forward. 

The Shift That Changes Everything

Product definition does not begin in CAD. It starts much earlier, in conversations, in decisions, and in the way information is brought together across teams. When this early phase remains unstructured, the same inefficiencies are carried forward into every downstream step, shaping how engineering, coordination, and execution unfold.

But when it becomes structured:

• Decisions become visible
• Work becomes clear
• Systems become connected

And projects move forward with far less friction.

Simple Questions to Reflect On

If you recognize this situation, it is worth taking a closer look at how the early phase of your projects is structured.

• Where is product or project definition captured today?
• How visible is the current state of a project?
• How do people know what needs to be done next and by whom?
• How much of the coordination happens through meetings and emails?

 The answer to that question often explains more than any feature comparison ever could. 

Fusion Manage is one way to bring structure to this phase not by replacing engineering or ERP systems, but by connecting them through a shared product definition and a guided process.