By
·
8 minute read
Manufacturers should structure complex product portfolios so leaders can move from the overall portfolio to a product family, platform, product, variant, module, or region. With the right structure, leaders can follow these relationships in a product portfolio dashboard without rebuilding the portfolio each time.
Most teams get there with a clear product hierarchy plus connected relationships for the modules, lifecycle states, regions, and dependencies that cut across it.
One giant hierarchy rarely works when everything is forced into it, but a good product portfolio structure keeps the relationships easy to follow when the question changes.
Most manufacturers already have the data. What they lack is a structure that shows how one platform or module change reaches every product that depends on it. This guide shows product and portfolio leaders how to structure complex product portfolios across platforms and modules.
What Does a Complex New Product Development Portfolio Structure Need to Do?
Imagine you are reviewing the products planned to launch on a global platform.
Your Director of Product Portfolio Management asks which plans will launch regional variants on it, then which of those products will use the new battery module, and finally, which product introduces that technology to the portfolio or product line first.
The last question is often the hardest, because it asks which products are still planning to use the battery that is slated to retire.
Why Disconnected Portfolio Data Slows Every Answer
Each of these answers depends on how the portfolio is structured.
If each answer lives in a different spreadsheet, roadmap, engineering system, or regional presentation, the team has to reconstruct the relationships before it can answer the question.
A useful product portfolio planning structure should make it possible to follow these relationships without rebuilding the portfolio each time.
Two decisions make this possible. First, a clear product hierarchy, then a defined strategy for how shared modules are integrated and adopted. Let’s break this down further.
1. Start With a Clear Product Hierarchy
First, answer the simplest question: where does this product belong?
A manufacturing hierarchy might look something like:
Portfolio → Product family → Platform → Product line → New Product Plan → Product
Keep in mind that the exact levels will depend on the business.
For example, an automotive manufacturer might organize around vehicle families, global platforms, models, and regional variants. Meanwhile, an industrial equipment manufacturer may think in terms of equipment families, platforms, machine lines, and individual products.
Why Many Manufacturers Organize Around Platforms
Large manufacturers and those with high levels of complexity eventually move toward platforms and modular product architecture to reduce cost and ship faster. Platform and module strategies can cut development costs and manufacturing times, because several products build on the same standardized base.
In these cases, launches are commonly tracked by platform. Products for different brands and regional markets can share components and production processes on one platform, so budgeting and measuring performance against the platform is standard practice.
Track Performance by Product Line or Individual Product
Other manufacturers measure performance by product line, and some go down to individual products. The individual-product approach is especially common in software, where a roadmap may carry many swim lanes, each representing a single software product or a major software component that launches frequently and moves through revisions.
Whichever level a manufacturer tracks against, the structure should represent the relationships leaders use when planning the portfolio.
Stop at the Right Level of Detail
The structure also needs to stop at the right level of detail.
Portfolio planning needs more structure than a presentation can usually provide, but it does not need to reproduce every engineering part or bill of materials record.
The useful test is whether the team understands enough of the product structure to make the portfolio decision, without modeling every detail of the product.
Product portfolio planning software like Gocious is built for this level. It gives product and portfolio leaders a view of products, platforms, and shared modules without duplicating the engineering detail that lives in PLM.
2. Define the Module Integration and Adoption Strategy
An engine, battery, transmission, cab, software capability, or other module may appear across several products. It does not necessarily belong neatly underneath only one product line.
Since a shared module serves many products, the portfolio needs a plan for how and when each product adopts it. The plan starts with one lead product.
Pick the Lead Product That Adopts the Module First
Consider an equipment manufacturer introducing a new engine family. One machine will be the first adopter, and several others are supposed to follow.
The lead product acts as the “guinea pig.” Its program tries the engine first, often funds the integration work and the initial design, and works through the early issues, so the products that adopt the engine later inherit a more mature module.
Questions Leadership Needs to Answer About Module Adoption
Leadership then needs to know:
- Which product introduces the engine first?
- Which products adopt it next?
- Where is the engine new to a product line?
- Where is it changing?
- Which products continue with the older engine?
- Did we miss a product that was supposed to adopt the new one?
All six questions follow the same module through the portfolio from different angles.
How Shared Module Risk Spreads Across Product Lines
When leaders follow the module this way, they can see shared module risk, where a decision about one module creates consequences across several product lines.
If the module is represented as an unrelated item every time it appears, the portfolio loses the connection that makes the rollout understandable. A better structure lets leaders start with the module and see the products connected to it, or start with a product and see the modules it depends on.
Plan for a Lead Project That Slips or Gets Canceled
Adoption plans rarely unfold exactly as scheduled.
If the lead project is delayed or canceled, every product waiting on its results inherits the problem. Follow-on products may lose the integration funding they were counting on, have to absorb design and validation work themselves, or stay on the older engine longer than planned.
A connected structure shows which products depend on the lead program, so when its status changes, leadership can decide whether to promote another product to lead, fund the integration separately, or extend support for the older module.
Separate Module Availability From Product Adoption
Adoption also has a timing dimension. Say a new battery module becomes available at the start of the new year. One product line adopts it immediately, and another follows the following year, while the battery it replaces still runs on several existing products and has its own planned retirement date.
The date a module becomes available and the dates products adopt it are related but separate, so the structure needs to connect the module’s lifecycle with the plans that use it.
If leadership can see that the new module is available, an expected product line with no adoption plan is easy to spot.
A module approaching retirement while several products still rely on it is a lifecycle and dependency risk that deserves attention well before the retirement date. The retirement date may be global while each region transitions on its own timeline, so it helps to track module retirement across regional product lines starting from the retiring module.
Broader questions about availability, transition, and retirement belong within lifecycle planning across the product portfolio.
3. Handle Regions Without Creating Another Portfolio or Disconnected Slide
When someone asks what the plan looks like in Europe, the answer should not require an entirely separate product structure. Start by separating regional variants from regional markets.
Regional Variants Versus Regional Markets
A manufacturer may sell products across North America, Europe, Asia Pacific, and other markets. Some products may have true regional variants, while others use the same underlying product or platform in several regions, which is a different relationship.
Meanwhile, a European variant may belong in the product hierarchy because it is a distinct product configuration. Europe itself is a business dimension that can apply across many products, families, and platforms.
A clear distinction stops teams from creating a new version of the portfolio every time another region or business group needs a different view.
Where Product Attributes Fit
This is also where product structure and product attributes work together.
The structure answers how products are related, while attributes help answer which part of that structure is relevant to the question being asked.
4. Make the Structure Work in Both Directions
A useful portfolio structure lets leaders start from different places depending on the question.
Trace Portfolio Relationships From a Product or a Module
Sometimes the question begins with a product.
What products is this platform launching in the future, which shared modules does it use, and what else depends on those modules?
Other times, the question begins with the module.
If this module changed, which products need it to launch, which launches depend on it, and which regions are affected?
Follow Both Paths in an Automotive Portfolio
Imagine an automotive portfolio leader reviewing a future regional model. The leader might move from that model to its global platform, then to a shared module, then to the other planned products that rely on the same module.
A week later, the question may start with the module because its timing has changed. Leadership now needs to move in the opposite direction, find every connected product, and understand the change's impact on each one.
The structure is doing its job when both questions are easy to follow and the team can visualize complex product architectures from either starting point.
How Much Detail Should a Product Portfolio Structure Include?
A product portfolio structure needs enough detail to understand the planning relationship, but not enough to recreate the engineering system.
For portfolio leaders, relevant structure can include products, product families, platforms, modules, features, variants, lifecycle states, availability, dependencies, and launch timing. Detailed component definitions, engineering specifications, and bill of materials records belong in the systems designed to manage them.
Too little structure hides the relationships portfolio leaders need, and too much detail makes the portfolio difficult to use for strategic planning.
What Should Manufacturers Avoid When Structuring the Portfolio?
Complex products do not require a complicated planning model for its own sake.
Watch for a few warning signs:
- A separate hierarchy exists for every region or business unit
- The same shared module is recreated under several products with no clear relationship among them
- Structural relationships have been reduced to labels or attributes
- Portfolio leaders have to open engineering level records to understand a strategic relationship
- Separate roadmaps show pieces of the same portfolio but cannot easily be connected
- A change to one module requires manual work to determine which products depend on it
Each warning sign points back to the same problem. The structure no longer shows how products, platforms, and modules connect. Fix the relationships first, and the rest of the portfolio becomes much easier to plan.
Test Whether Every Change Can Be Traced Across the Portfolio
A simple test is whether the team can follow every place a change reaches.
If the answer requires several disconnected artifacts, the portfolio may be organized without being connected.
How Gocious Supports Complex Product Portfolio Structures
Gocious is the strategic product portfolio planning platform for complex manufacturers. Sitting above execution tools and below PLM, it gives product and portfolio leaders one trusted view of lifecycle, dependencies and shared modules.
At the planning level, teams can work with product structures and the relationships among products, platforms, modules, features, variants, lifecycle information, dependencies, timing, and business context.
This makes it possible to start with one part of the portfolio and follow the relationships relevant to the question.
Keep Your Portfolio Structure Connected
With Gocious, a leader can begin with a product family, move to a shared module, examine which product lines are planning to adopt it, and then look at the module’s availability or retirement timing. The conversation could also start globally and narrow to the products and plans relevant to a particular region.
Ultimately, engineering systems remain the authority for detailed product data. Portfolio planning keeps enough connected structure that product and portfolio leaders can answer the next question without rebuilding the planning picture first.
Request a custom demo to see how our software can work for you or explore connected product portfolio planning with Gocious.
Frequently Asked Questions