Solution Space

The solution space is the engineering and production view of a product family: the set of all technical design decisions, components, assemblies, and configurations that implement the variation defined in the problem space Problem Space (ˈprä-bləm ˈspās) n. In variant management, the problem space captures customer requirements — what must be solved, independently of the solution. Expressed in needs language, not engineering terms. . Where the problem space describes what customers can choose, the solution space describes how those choices are realized in the product’s architecture, bills of materials, and manufacturing processes.

In variant management, the solution space is what engineers, production planners, and ERP systems work with. It is expressed in engineering language: part numbers, assembly drawings, material specifications, production routes, software module configurations, and constraint rules that govern which combinations are technically valid.

What belongs in the solution space

The solution space is expressed in the language of engineering and production:

• Part variants — Different versions of a component (e.g., a bracket in three lengths, a housing with and without a cable port)
• Assembly variants — Different subassembly configurations (e.g., a motor assembly with or without an integrated encoder)
• Software configurations — Feature flags, firmware versions, or license modules that implement different product behaviors
• Production routes — Different manufacturing or assembly sequences required by specific variants
• Constraint rules — Technical restrictions that prevent invalid combinations (e.g., a high-torque motor requires a reinforced mounting frame)

The mapping to the problem space

Every element in the problem space must map to one or more elements in the solution space. This mapping is central to managing product variety systematically:

• When a new customer option is added (problem space), the engineering impact is identified and documented (solution space).
• When an engineering component changes (solution space), the affected product configurations are identified and communicated to sales and customers (problem space).
• When a customer orders a specific configuration (problem space), the correct set of parts and production instructions is derived automatically (solution space).

Without an explicit mapping, changes ripple unpredictably between the two spaces. Engineering teams modify components without knowing which customer configurations are affected; sales teams commit to options without knowing whether engineering can deliver them.

Solution space in practice

In manufacturing companies, the solution space is typically managed in a combination of PLM systems (for product structure and engineering data) and ERP systems (for BOMs, production routing, and materials management). The 150% BOM 150% BOM (ˌwən-ˌfif-tē pər-ˈsent ˌbil əv mə-ˈtir-ē-əlz) n. A 150% BOM lists all possible components across all product variants, serving as the master structure for subtractive configuration in variant management. is a classic solution-space artifact: it documents all possible components across all variants in a single product structure, from which individual variant BOMs are derived.

In software product families, the solution space is managed in version control systems, feature management platforms, and build systems that assemble different product variants from a shared codebase.

Role in variant management

Keeping the solution space separate from the problem space is not an abstract modeling principle — it has direct practical consequences:

• Configurators translate customer selections (problem space) into engineering specifications (solution space). The translation logic lives at the boundary of the two spaces.
• Change management becomes tractable when each change can be assessed for its impact in both spaces independently.
• Reuse is maximized when the solution space is designed with variability in mind — shared components with defined variation points Variation Point (ˌver-ē-ˈā-shən ˈpȯint) n. A variation point is a specific location in a product or system architecture where a decision between alternatives must be made to create a specific variant. rather than independent per-variant engineering.

Examples

• Commercial HVAC systems — The problem space offers options for cooling capacity, refrigerant type, and installation format. The solution space contains compressor assemblies, refrigerant circuit variants, housing tooling, and wiring harnesses for each combination. The manufacturer manages hundreds of solution-space components to deliver a problem space of perhaps twenty customer-selectable parameters.
• Embedded software platforms — A product is sold in three tiers (problem space). The solution space contains a shared software core with conditional compilation flags, a tier-specific license verification module, and separate firmware images for each tier. The mapping from tier (problem space) to build configuration (solution space) is managed explicitly in the build system.

Frequently asked questions