PIM implementation mistakes: eight traps and how to avoid them

What this episode covers

The fourth episode is a list of mistakes gathered from real projects, ordered the way they usually appear: from how the project is organised, through partner choice and the data model, to the temptation to extend the system with everything.

Key takeaways

• One person coordinates the implementation, with a real mandate. Not a committee of directors who each have plenty of other work.
• The costliest mistake is a bad data model: no room for translations, or a product page where 70 percent of values read not applicable.
• Do not mirror your current structure and plan to tidy up later. Later, other systems will already have adapted to that structure.
• The time needed to prepare data for the first load is almost always underestimated. Start collecting from day one of the project.
• A PIM system is not a bin for data that did not fit elsewhere. Price calculation and sales reporting have their own tools.

No product owner, or one without a mandate

Companies often hand the implementation to a whole team, a committee or a group of directors who have plenty of day-to-day work. It should be coordinated by one person who watches progress, timeline, budget and requirements.

This is not about dumping every decision on one individual. It is about giving the product owner room: some topics go to decision makers, while the small, day-to-day ones are settled directly. That person is the main link between the implementation team and the stakeholders: collecting feedback and reporting progress. Without the role, communication and organisation drift into chaos.

No engaged team

Even the best-mandated product owner cannot implement the system alone. You need a team that includes the future beneficiaries of the system.

A good team does four things: defines expectations, looks into what a PIM system is and can do, works out collectively which data will be needed, and tries to restructure product data to serve customers better. It also takes part in meetings and testing.

The last condition matters most: openness to change. An implementation means different processes and leaving paths worn in over years.

Doing it alone by trial and error

Not impossible, but risky. Typical outcomes: a slow and difficult implementation, discouraged staff, trouble with integrations, and having to remodel data once the portfolio grows.

Without experience it is hard to know the system deeply, and building a data model by instinct leads to mistakes whose repair calls for a rebuild, sometimes a fresh implementation. The apparent saving turns into a double cost.

The wrong partner

An implementation is not only technology and training, it is a new way of working and new processes. So it pays to work with a partner who knows the traps and can advise on data design and integrations.

The workshops and pre-implementation analysis also serve another purpose: getting to know the partner’s team and checking whether they understand your organisation. It is a project of several months, usually followed by shared development and maintenance, so it is worth testing the fit early.

A bad data model

This mistake has the longest consequences and several faces. The e-commerce system cannot read data from the PIM system. Text attributes were added without allowing for translations, so entering another market means a rebuild. Or the model is so universal that it answers every hypothetical case and, as a result, the product page consists of 70 percent “not applicable”.

That is why the pre-implementation phase and the first stage of the project, where data is analysed and modelled, decide the next several years of working with the system.

Mirroring the current structure

The approach “let us mirror today’s product page and tidy up later” is not recommended. An implementation is exactly the moment for questions: is the current description good, could the product be described better, do the filters on the site actually help, does search work.

The practice is the reverse: at least minimal tidying first, plus thinking through how to build products, families and categories, then modelling and testing the target structure. Postponing usually means the original structure stays for years, because other systems consuming the data have adapted to it, and changing the PIM system would force a change in each of them.

Too optimistic about data

Once the skeleton exists, the system has structure but no data: no specifications, images or documentation. Reflecting the current portfolio, and often an archive of several years, needs a plan.

Methods vary and can be mixed: pulling part of the data from existing systems, loading from a flat file, semi-automatic image import, and manual entry as a last resort. Experience shows, however, that a delayed go-live usually comes from two things: too few people assigned to loading the system, or too little slack in the timeline. The recommendation: gather and prepare data from the beginning of the project, so it is ready when a place for it exists.

Every requirement in the MVP

Collecting ideas and expectations is necessary. Squeezing all of them into the first release is not. Prioritising and phasing integrations and modules lets you start benefiting from centralised data sooner.

Trying to do everything at once ends in testing trouble and user frustration, with nobody feeling that any part works well. Better to ask what is missing most. If it is a single reliable source for product documentation, add documents early so the benefit is visible immediately.

A PIM system for everything

The final trap: there is nowhere to calculate prices and discounts, so let us add that to the PIM system. There is no sales reporting tool, so let us build a module.

A PIM system manages product specifications superbly, supports adding products and preparing translations. It is not a bin for data that did not fit elsewhere. Price calculation and reporting have dedicated tools, usually cheaper than extending a PIM system in that direction. And an over-complicated system is harder to maintain and develop.

Planning an implementation and want to avoid these traps? Get in touch. More on the PIM systems page.