How to Build a Planning-Level Product Architecture

A flat roadmap is usually too simple for a complex manufacturer, and a BOM is far too detailed for portfolio leadership. Product leaders need the layer in between.

This leads many of the product leaders we work with to ask, "How should manufacturers structure products, platforms, modules, and variants without rebuilding the BOM?"

Here's the short version. A planning-level product architecture should show the products, platforms, major modules, generations, regional variants, and lifecycle relationships that can change a roadmap, investment, or product decision. It shouldn't recreate engineering.

A useful test is to ask whether product leadership would care if a given element changed. If yes, the relationship probably belongs in the planning model. If it matters mainly when someone is building, sourcing, configuring, or technically controlling the product, it probably belongs in PLM or another engineering system.

So how do you build a planning-level product architecture that stays useful? Below, we’ll start with the decisions the model has to support, then work through modules, regional variants, time, and ownership.

Why the Boundary Between Planning and Engineering Matters

This boundary is what keeps strategic product planning useful, and it matters more as manufacturers rely on modular product structures.

For example, Epiroc describes modularization as supporting faster assembly, easier upgrades, and simpler service and maintenance. These benefits depend on understanding where common structures and modules are reused without forcing portfolio leaders into part-level engineering detail.

The idea isn't new. Harvard Business Review's classic essay on managing in an age of modularity argued that modular design shifts the hard work toward defining the rules that connect modules, which is exactly the level portfolio planning needs to see.

Pro-Tip: For more on what modularity changes in planning, take a look at our all-inclusive Modular Product Architecture guide.

What Should a Planning-Level Product Architecture Be Able to Answer?

As a general rule of thumb, start with the decisions, not the data you can import.

Why? Because manufacturers already have enormous amounts of product data, and not all of it belongs in strategic planning.

Before building the structure, ask what leadership actually needs to understand:

• Which products depend on this platform?
• Where is this module reused?
• Which product generations are still active?
• Where does a regional product differ from the global product?
• Which shared technologies are approaching transition?
• What other roadmaps change if this module moves?
• Where is product variation increasing?

These questions define the planning model better than the contents of an engineering database. This is part of the broader role of product portfolio planning, which maintains enough connected product context to support decisions without reproducing every system underneath it.

"The question is whether portfolio planning is represented primarily as a collection of projects and milestones, or as a connected model of customer needs, capabilities, platforms, modules, products, regions, expected business outcomes, and scenarios."

Maziar Adl, CTO at Gocious

What Usually Belongs in the Planning Layer?

There's no universal taxonomy, but most planning-level architectures can begin with a relatively small set of objects:

How the Model Varies by Industry

Different manufacturers may add different layers.

A medical-device manufacturer may care deeply about regulatory configurations, while an industrial equipment manufacturer may organize around machine families and common controls platforms. An electronics manufacturer may emphasize hardware generations and shared software foundations.

The objective is to create a model small enough to maintain and detailed enough to explain important product decisions.

Pro-Tip: Our list of product attributes manufacturers should track in portfolio planning is a good starting checklist to help you explain important product decisions.

How Do You Know if a Module Belongs in the Planning Architecture?

We recommend you use the controller test. Let us explain.

Suppose one controller is shared across three industrial machine families. It affects:

• Software compatibility
• Multiple product roadmaps
• Regional configurations
• A future platform transition
• Existing-product lifecycle plans

This controller belongs in the planning model.

Where the Planning Model Should Stop

Now look inside the controller. It may contain hundreds of individual parts, and a specific fastener may be essential to manufacturing it correctly. Engineering needs to manage that fastener, while portfolio leadership probably doesn't.

Unless a component creates a meaningful sourcing, compliance, cost, or lifecycle decision across the product line, adding it to the strategic architecture simply creates noise. The dividing line matters to the decisions the planning layer exists to support.

How Should Shared Modules Be Represented?

Represent shared elements in product portfolio planning once. One of the fastest ways to make a product architecture unmanageable is to recreate the same module separately inside every product.

Here’s a quick example.

Suppose six products use the same controller. If each roadmap maintains its own independent version, the organization appears to have six separate module decisions. Then the supplier announces the controller's retirement, and six roadmaps have to be reconciled before leadership can understand the exposure.

A cleaner structure is one shared controller with six dependent products, the same approach our platform planning capabilities are built around. Reuse now looks like reuse, and one lifecycle change can immediately be understood as a cross-product issue.

How Should Regional Variants Be Modeled?

Start with the common core, then show the differences that matter. For example, let’s consider a global equipment family that shares a platform, a primary controller, a core software foundation, and a main product generation. The regional versions then differ in a few specific ways:

1. Europe: Regulatory module, software configuration, validation requirement, and launch timing
2. North America: Communications module and a customer-specific capability

Leadership can now answer two useful questions. What are we intentionally sharing, and where are we intentionally allowing variation?

Modeling every regional configuration as a completely separate product hides the common architecture and can make a mostly shared portfolio look far more fragmented than it really is. It also makes it harder to recognize when exceptions actually are accumulating, one of the structural factors in complex manufacturing planning.

Why Does Product Architecture Need a Time Dimension?

It’s no secret that architecture changes. You’ve seen this first hand.

A platform may support five products today and only two three years from now. A shared module may disappear from the next generation, and one regional configuration may remain in market two years longer than the global product.

A useful lifecycle planning architecture therefore needs enough lifecycle context to show:

• When something enters the portfolio
• Which products depend on it during that period
• When its transition begins
• What replaces it
• Which products remain exposed afterward

Without time, architecture explains what the product system looks like. With time, it begins explaining where the product system is going.

What Should Stay in PLM?

A planning-level architecture needs a clear stop line.

The planning model can reference those systems without replacing them. Engineering retains the precision required to build and control the product, and product leadership gets a structure simple enough to understand cross-product consequences.

Who Should Maintain the Product Architecture?

It is okay for ownership to be distributed.

Product teams can maintain product direction and lifecycle assumptions, and engineering can validate important technical relationships. Regional teams can maintain meaningful market differences, while portfolio teams keep shared definitions and common elements consistent across product lines.

The planning layer doesn't replace those responsibilities! Its job is to connect them where a shared product decision needs to be understood.

One Test for Every New Element

When deciding whether another object, attribute, or relationship belongs in the architecture, return to one test. If this changes, could it affect a roadmap, lifecycle decision, platform strategy, regional plan, investment, or product commitment?

If yes, represent it. If not, there's probably a better system for that detail.

How Gocious Supports a Planning-Level Architecture

Gocious provides a strategic product portfolio planning layer for connecting products, platforms, modules, variants, roadmaps, regions, and lifecycle context above detailed engineering systems.

Ready to model your own products at the level leadership actually uses? Explore Gocious Product Portfolio Planning or request a custom demo to see our platform in action.