Configurator for Product Management and Planning

By amystrucko

When we started this discussion in Beyond Product Configurator Software: Total Variability Management, we talked about defining and managing variability across a product suite. Teamcenter uniquely supports variability introduction and management seamlessly tied to product definition and visual configuration.

Critical to this approach is the concept of a single variant backbone for managing variability across all domains. To make sure every user is able to most effectively interact with that data, you need specialized variability that’s relevant for different roles. I’d like to continue this discussion by taking a closer look at two user communities – Product Managers and Product Planning.

Product Managers Define How Product “Looks” to the Marketplaceconfigurator-product-manager-role.png

As I talked about in a previous article on product variant management, product decisions are made based on what is expected to make the product successful and profitable. This is based on the product manager’s consideration of market research and analytics, competitive analysis, and desired positioning of their products in the market.

As such, product and program managers define a strategy for how the product will “look” to the marketplace. That is, how will the product suite be broken down, what product models will be offered to the marketplace, which product options will be made available for different models and different markets, and how will different options be packaged and offered together.

With Teamcenter, product and program managers can capture and communicate these decisions. They can define and manage a dictionary of options that will apply across the product suite, and be able to draw from this dictionary specific option values that will be relevant or allowed for a given product model they are defining.


Enabling the product manager to directly manage the product line and options as it will be presented to the market supports both the view that the customer ultimately sees and also enables capture of other program and product definition and execution decisions to satisfy the product manager’s vision for the product options being offered. In the next installment of this series, we’ll talk more about the connection between the decisions the product manager makes and downstream activities.

Product Requirements and Systems Definitions Drive Downstream Product Definitionconfigurator-systems-engineer-role.png

As the breadth of data that customers manage in PLM fully connected to the engineering product definition expands to include not only product requirements but also full systems and logical modeling, it is important that this data is qualified for which features and options it is relevant for.

The value of supporting this expanded product scope is greatly enhanced by enabling these requirements, systems, and logical models to comprehend the full variability of the product suite and to leverage this intelligence to drive product definition and accountability downstream.

This whole area of Systems Driven Product Development merits dedicated discussion all it’s own—we have just mentioned it here for completeness given its critical role in the overall product development lifecycle.

Early Planning Decisions Directly Guide Product Definitionconfigurator-program-manager-role.png

Managing the product suite with all product options and compatibility in Teamcenter opens up the ability to directly tie and track early program decisions all the way downstream.

One example of early program decisions that can be captured and tracked against product option offerings is penetration expectations for certain features or options. That is, what percentage of customers will choose a given option for the unit they configure and purchase? The analysis and decision-making itself are not intended to be done using Teamcenter. However, by being able to record and track some of these decisions/assumptions in Teamcenter, it enables a company to better predict and plan for procurement, manufacturing costs, and profitability.

Another example of early program decisions tying into both product variant management and engineering reuse and innovation are reuse targets. That is, what areas of the product are expected to leverage existing product definition, and where is engineering and manufacturing innovation to be focused? By planning and accounting for this metric, it allows a company to better plan for engineering costs and resource needs.

The Pareto Principle (better known as the 80 / 20 Rule) has various forms. One is “80 percent of outputs are from 20 percent of inputs”. In this case, the inputs are the early planning decisions and targets. Being able to directly capture and track accountability to these throughout the product definition process in Teamcenter allows better visibility and ideally better overall alignment to program expectations and goals.

It is the decisions made upstream of engineering and manufacturing that define many of the criteria that impact the overall success and profitability of a program. This integration of Program Planning, Product Definition, and Product Configuration allows the key up-front decisions to drive product definition with maximum effect.

Configurator in Teamcenter: Benefits Reach Far Beyond Engineering

As we’ve discussed previously: An effective configurator strategy needs to address the scope of product configuration and variability management far beyond engineering. You need to support variability introduction and management seamlessly tied to product definition and visual configuration. Next week, we’ll look at how the decisions captured and communicated from product managers and planners can be leveraged downstream.

Other discussions in this series include:

Beyond Product Configurator Software: Total Variability Management

Configurator for Engineering and Manufacturing

Configurator for Enabling Customer Choice

After-sales BOM and Configuration

Configurator for Service Organizations

Accelerating Lead Times for Engineer to Order (ETO) Processes

Leave a Reply

This article first appeared on the Siemens Digital Industries Software blog at