Stop mapping PIM fields while the project goes nowhere

I have sat through too many kickoffs that start with a 200-row spreadsheet of PIM attributes and end with a parked project. In one meeting, the team spent two hours arguing whether "engine family" belonged under variations or compliance. We left with a color-coded backlog and zero progress on something a salesperson could use. Scope grew. Momentum died. Nobody sold more the next day.

If your first milestone is a perfect data pipeline from Inriver to CPQ, you have already chosen the slow lane. You are laying a harbor while your competitors are out on the water in a speedboat.

The real first step: build something sales will use

The common belief is simple. To connect PIM to a configurator, you must map, cleanse, and integrate all product information before you do anything else. That belief is why so many CPQ programs stall. It front-loads plumbing and delays proof of value.

The design problem is not integration. It is usefulness. You cannot prove value with a data pipeline. You prove it with a working configuration tool that shortens calls, avoids rework, and produces correct quotations.

CPQ is not about automation. It is about correctness.

When a salesperson can guide a customer to a valid pump or truck configuration in five minutes, the organization leans in. Adoption is the only metric that matters.

Design principles for a model-first approach

Four principles separate teams that deliver in days from teams that deliver in quarters:

  • Start from a template, not a blank page. Give AI a proven structure and ask it to mirror it for the new product family. Consistency beats cleverness.
  • Constrain AI with explicit rules. Large language models are a great assistant, not a source of truth. A symbolic rule layer keeps configurations correct.
  • Integrate essentials only, and do it later. Most PIM attributes do not matter for configuration. Pull the 10–20 percent that drive choices and rules. Ignore the rest until it earns its keep.
  • Make logic explainable. If sales cannot see why a rule fires, they will not trust it. Visibility creates confidence and speeds improvement.

AI does not replace logic. It depends on it.

The architecture: model first, hybrid intelligence, integrate later

I have built CPQ for complex products since 2000, often with Tacton. The architecture that works now is a simple sequence shift that changes everything.

1. Model first. A two-day workshop. We start with a template everyone can read. Say a truck with clear modules, variants, and rule patterns. We feed that structure to AI and ask for a parallel for pumps. In a few hours, we get modules like motor, impeller, seal types, casing materials. We get variant lists and base rules. We tighten names. We drop fluff. We add the two or three hard constraints that matter for day-one sales.

Day two we test it with real scenarios. A salesperson and a product specialist sit together. We configure three typical deals and one ugly edge case. We flag anything that breaks, refine the rules, and capture explanations. The output is a working configuration model that someone can use in a call. Not perfect. Useful.

2. Hybrid Intelligence engine. This is not just an LLM "guessing" a product. A symbolic logic engine holds the hard truths. It enforces compatibility and prevents contradictions, like classic CPQ. The AI layer sits on top to converse, summarize, propose options, and translate need to configuration. The AI suggests. The rules decide. That separation is why you can trust the answers and still move fast.

Rules are not the enemy here. Brittle rules are. When rules are modular, named, and testable, they become assets you can reason about.

3. Connect smartly with an agent-based sync. Once sales confirm the model is useful, we bring in only the data that matters. An agent queries Inriver for configurable components and relationships. It filters out the 80–90 percent of attributes that are irrelevant to selection logic. It compares "before vs after" and applies deltas. New motor variant added. Deprecated seal removed. No full export, no brittle mapping, no weekly fire drills after a PIM change.

This is integration by curiosity. The agent looks for what changed and why, then updates the configuration model accordingly. You get continuous correctness without a heavyweight pipeline.

4. Active guidance, not passive filtering. Many teams think e-commerce filters when they hear configurator. That is passive filtering. A modern configurator is active guidance. You can chat in needs, use a guided form for structured discovery, and offer visuals where selection benefits from seeing. It is like a GPS for complex sales. You set the destination and it routes you through a valid path, avoiding dead ends.

Does this ignore pricing and ERP alignment? No. It sequences them. Get configuration correctness and sales adoption first. Then bring in price and ERP item IDs where they matter. Progress beats perfection because learning starts sooner.

What to change this quarter

Pick one product family with volume and repeatability. Not projects or one-off systems. Pumps beat entire buildings. Mixers beat custom plants. Choose something with 10–20 modules and clear options.

Run the two-day workshop. Day one, agree the template and generate the initial structure with AI. Day two, validate with real scenarios. Keep a human in the loop. Name owners for every module. Write the three most important rules per module in plain language.

Make it explainable. For every rule, keep a one-line reason and a link to a test. If the system cannot explain itself, it will never be trusted.

Test with sales on real calls. Put the tool in front of three senior reps. Ask one question: did this help you think, or just click? Adoption tells you if you are on track.

Wire in data later, and only what earns its place. Use an agent-based sync to pull the essentials from PIM. Components, variant lists, images for key choices, and the relationships that drive rules. Skip marketing text, long descriptions, and anything that does not change selection. Set the agent to watch for deltas, not to rebuild the world each night.

Show, do not explain. If you are selling this internally or to a customer like Regel, build a focused demo. Two use cases. One guided form. One chat. One visual. Ten minutes that prove correctness and speed. People believe what they can try.

Create lightweight governance from day one. Name a logic owner. Define a safe path for change. Keep a small test suite. If change still needs a project plan, the field will route around the system.

You cannot prove value with a data pipeline. You prove it with a working tool.

Sticky close

Build the tool your salespeople will actually use first. Then, and only then, give it the data it needs to run.