Problem Space
In variant management, the problem space captures customer requirements — what must be solved, independently of the solution. Expressed in needs language, not engineering terms.
The problem space describes the requirements and context a customer brings to a product decision — what problem must be solved — expressed in market and requirements language rather than engineering design decisions. In variant management, the problem space defines what a customer needs, not what a product offers, independently of how those needs are realized in engineering and production.
The distinction is concrete: a customer who needs a gripper to move a 3 kg part contributes “3 kg component” to the problem space. That is a property of the customer’s problem, not of the product. The gripper’s rated payload capacity — say, 6 kg, parallel-jaw, pneumatic — belongs to the solution space. Both spaces describe the same reality from different perspectives.
Separating the two is one of the fundamental structuring principles in variant management. Conflating them — letting engineering decisions leak into customer-facing product descriptions, or letting sales commitments drive product architecture directly — is a root cause of unmanageable product complexity.
What belongs in the problem space
The problem space is expressed in the language of customers, markets, and requirements:
- Customer requirements — “Heated seats,” “all-wheel drive,” “24V power supply,” “stainless steel housing”
- Market segments — “Entry-level,” “professional,” “food-grade,” “ATEX-certified”
- Performance requirements — “500 kg payload,” “IP67 protection,” “≤3 ms response time”
- Regulatory and regional variants — “North American electrical standard,” “EU machinery directive compliance”
What does not belong in the problem space: internal part numbers, manufacturing processes, CAD model references, or engineering design decisions that customers neither see nor care about.
Problem space and solution space together
The two spaces are linked by a mapping: each element of the problem space must correspond to one or more elements in the solution space that implement it.
| Problem space (customer view) | Solution space (engineering view) |
|---|---|
| “Heated front seats” | Seat assembly variant with heating element, wiring harness variant, fuse box variant |
| ”IP67 housing” | Housing part variant with sealed cable entries and gasket material |
| ”400V / 50 Hz” | Power supply module variant, input filter variant |
A well-managed variant space keeps this mapping explicit and consistent. When a new requirement is added to the problem space, the corresponding engineering decisions in the solution space are identified and documented — not discovered during production.
Role in variant management
Separating problem space from solution space serves several practical purposes:
- Configurator design — A CPQ system CPQ – Configure, Price, Quote (ˌsē-ˌpē-ˈkyü) n. abbr. CPQ stands for Configure, Price, Quote — software that automates sales quoting for configurable products by enforcing product rules, calculating pricing, and generating output. presents the customer with problem-space language (feature names, options) and translates selections into solution-space elements (part numbers, BOMs) behind the scenes.
- Requirements management — Customer requirements are captured in problem-space terms; engineering responses are captured in solution-space terms. Changes in requirements can be traced to their engineering impact.
- Complexity control — The problem space is often much simpler than the solution space. One customer-visible option may require changes in ten engineering components. Keeping the two separate prevents the engineering complexity from overwhelming the product presentation.
Examples
- Machine tools — A CNC machine customer specifies requirements such as spindle speed range, axis count, and control system brand (problem space). Each requirement maps to specific hardware assemblies and software configurations (solution space). Customers define their needs in problem-space terms; engineers fulfil those needs from the solution space.
- Configured software — An enterprise platform is sold in editions defined by feature access and user limits (problem space). Each edition maps to a feature-flag configuration and a licensing module (solution space). The customer does not see or need to understand the feature-flag architecture.
Frequently asked questions
Where does the problem space concept come from?
The problem space / solution space distinction originates in systems engineering and software engineering methodology, where separating what a system must do (requirements, problem space) from how it does it (architecture, solution space) is a foundational principle. In variant management and Product Line Engineering, the same separation is applied to product families: what variations customers need versus how those variations are engineered.
Is the problem space the same as a product catalog?
A product catalog is a customer-facing representation of the problem space, but the problem space is more than a catalog. It includes the constraint rules that define which option combinations are valid, the market segmentation logic that determines which options are offered to which customer groups, and the traceability links to the solution space. A catalog without these elements is a snapshot; the problem space is the model behind it.