Many PIM initiatives begin with vendor demos. Teams compare feature lists, select a system, and finalize a rollout plan. Only then do they begin to grapple with their actual product data. Within weeks, it becomes clear that the reality of their product data and processes doesn’t fit the chosen system. This leads to custom logic, delayed deadlines, and, six months later, a PIM system that doesn’t work as intended. This isn't because the users lack the skills to use it, but because the data model, workflows, and responsibilities weren't defined clearly enough beforehand.

Whether a project succeeds after go-live isn’t decided during implementation. It’s decided in the weeks leading up to it, in a phase we call “Discovery” or the pre-project. Too often, this phase is simply skipped.

A PIM is a management system for product data. It structures, versions, distributes, and enriches data with attributes and assets. What it does not do is invent a data model that doesn't exist within the company. It doesn't clarify responsibilities, define maintenance processes, or replace missing architectural decisions.

Those who overlook this buy software to solve a problem that should have been solved organizationally first. A PIM cannot replace data governance or master data management. If those are missing in your company, a PIM can support their implementation—but only if you have already determined who maintains which fields and which dataset is the "source of truth." Without this clarity, problems will surface during data import at the latest.

From our projects, we have isolated three areas where the greatest risks lie. If these aren't thought through, the implementation will be costly and protracted, regardless of which system is chosen.

The Product Data Model

The number of attributes a product has is rarely the crucial question. It is more important to understand what types of attributes exist and how they depend on one another, as this determines the variants. The raw quantity of products is a simpler criterion: some systems can process millions of products, while others hit their limits sooner. Furthermore, data quality is key; product data often ends up in fields not intended for it, or the same attribute – “width” for example – can mean different things for different product types. These cases have a direct impact on the model.

When it comes to variants, it’s worth asking: Do they exist within a single product type, or can they be logically generated from the existing data at all? On which axes are they formed, and which attributes can be maintained for which product type at which level?

The answers are rarely found in a single system. Product management knows how the assortment is intended, category management knows how it should be structured in the shop, and ERP managers know the master data logic. What’s missing is a system-independent description that consolidates these perspectives.

A practical starting point is modeling based on real products: two dozen representative articles are sufficient, including the question of whether variants can even be formed for them. This is where the conflicts appear that will later push any system to its limits: overlapping attribute definitions, exceptions without categorization, or assortment areas with contradictory logic. These belong in the conception phase, not the configuration of a tool you’ve already purchased. For one B2B retailer, for example, an automated migration of legacy data was impossible because the old model had never accurately mapped the product world. The effort wasn't generated by the PIM, but before it — by cleaning up a logic that no one had questioned for years.

The Processes

With master data from the ERP, text from the CMS or an agency, images from the DAM or the manufacturer, technical data from supplier catalogs, and additional layers for translation, variant management, and quality control handled by various roles: a PIM is almost never operated by a single department. Before go-live, it must be clear who maintains and approves which data, and in what order.

We clarify this by looking at departments, not just the product. In Deep Dives with the teams that actually work with the product data, we determine who creates, enriches, and approves what, and through what channels (email, Excel, tickets) the data flows. This simultaneously sharpens the data model and brings stakeholders on board early, as a new system changes their daily work. The recurring signal is almost always the same: time-to-market is too long. This is exactly where process analysis should start, not with the friction in the details.

Only on this basis does the vendor question become concrete. Akeneo, for instance, excels with seamless processes and parallel, permission-based collaboration using roles, workflows, and notifications. Centric PXM thinks in terms of the product lifecycle and is a good fit where PLM aspects overlap with product data work.

Without a described maintenance process, the feature list makes the decision, and the processes are expected to adapt to the system later. That rarely works.

The Architecture

A PIM never stands alone. It is embedded in a landscape of ERP, shop or marketplace, DAM, supplier systems, and sometimes a data hub. The architectural assessment answers three questions: Where should the PIM sit, who holds which data, and how does it flow?

Where does the PIM sit? Its position in the chain varies from case to case. Sometimes it sits at the beginning and assigns the SKU itself; sometimes it is attached to the ERP; sometimes a PLM drives the product lifecycle — it's not for nothing that Centric bought Contentserv, a PIM that connects to their PLM. There is also no fixed direction regarding suppliers: sometimes the PIM is the portal they upload to, other times it exports to a marketplace. The relevant question is therefore not whether a PIM will be connected, but to how many systems and in which direction.

Who holds which data? Before the vendor conversation, a stocktake is worthwhile: which systems currently hold which data, where is the PIM the leading source, and where is it only a consumer? The goal is for every piece of information to be maintained where it originates or is needed, rather than in two places. The PIM must be the lead for at least one data category, otherwise, there is no justification for its deployment. This is particularly relevant for the ERP: if an attribute is missing, people often quickly say, “let’s add it in the ERP,” even though it is never needed there, but rather on the website or in the catalog. An attribute belongs in the ERP only if the system actively uses it, for instance for shipping costs or, as with Riese & Müller, for price tags with barcodes in the showroom. Otherwise, the ERP becomes bloated and difficult to maintain.

How does the data flow? Internally, the PIM absorbs data and consolidates it; externally, it distributes it, often in different formats. The same product goes to B2B and B2C channels: one wants technical information, the other marketing content; a print catalog has less space than a product page. It is worth keeping the number of output channels and languages low. A separate channel is only necessary if the data for the recipients is truly different. Anyone who sets up three channels with identical data in Akeneo has misunderstood the concept.

The fact that data does not always flow unchanged between systems is demonstrated by Riese & Müller. The realization there was that they first needed their own data switchboard: a data hub that consumes, harmonizes, and distributes data. It made a blocked ERP functional again and was the primary enabler for exchanging data between systems.

Where a discovery phase uncovers such cases, custom connectors and a transformation layer belong in the architecture to prepare, aggregate, or merge data beforehand.

A consistently executed discovery process can lead to the conclusion that the answer is "not yet." Or that an entirely different step needs to be taken first.

"Readiness" is shown by concrete signals. The assortment is large and heterogeneous enough that spreadsheet maintenance is noticeably reaching its limits. Multiple channels require different subsets of data from the same source. There is a person or team that can take organizational responsibility for product data, rather than just performing operative maintenance. Master data and marketing content can be logically separated instead of being mixed in the same system. And a concrete AI roadmap requires structured product information as input.

If several of these signals are missing, it is often worth taking a different step before implementing a PIM: cleaning up ERP master data, developing a data hub concept, or clearly defining owners for product data. The PIM can then come later, with less friction and a clearer mandate.

A clean discovery process doesn't end with a slide deck and a recommendation. It delivers three artifacts that work for vendor selection and the subsequent implementation project.

First, a documented product data model, tested against a representative segment of the assortment, with real attributes, variants, and hierarchies. Second, a process overview that records which role maintains which data and in what order, including interfaces to other departments and external data suppliers. Third, an architectural assessment that maps the current system landscape, defines data ownership, and identifies which connections will make the PIM project complex.

On this basis, a vendor decision can be made against concrete criteria. And the implementation doesn't start with another conceptual phase, but directly with the realization of a well-thought-out model.

In practice, a PIM discovery takes between four and eight weeks, depending on the breadth of the assortment and the number of source systems involved. It is only effective if the right people are at the table: operational product data maintenance, category management, an IT architect with an overview of the interfaces, and someone from sales or marketing who knows the delivery side. They all need to be not just interviewed, but included in the project. If the discovery is run solely by IT, the result is a technically clean architecture that misses the operational reality. Without IT, you might get a sophisticated data model that gets stuck at the interfaces later.

Whether a PIM project succeeds is not decided at go-live. It is decided in the weeks when you clarify what the system is actually supposed to do: for whom, with which data, and in which architecture.

Treating this clarification as merely a preliminary stage pushes the most important decision in a PIM project to the margins. A stringent discovery ensures that the implementation starts with a tool that fits your own reality. Without this preparatory work, you are left hoping that the two will somehow come together later. And that rarely holds up until go-live.