Here’s a scenario we’ve observed (and advised on) several times. The merchant has implemented its PIM system. They’ve paid the licences and integrations are set up. Even so, the business still isn’t behaving as if it is reaping the benefits. User adoption is distinctly patchy and the quality of product data is a subject of constant debate instead of being implicitly trustworthy. That’s why publishing is still being stitched together using pre-PIM processes: Spreadsheets, emails, and ‘temporary’ workarounds which never really went away.
Given this dispiriting situation, the default boardroom decision in most cases is to go back to the drawing board and start again from scratch. They do it not because it’s the best option, but because they think they’re being decisive. It’s a reaction typically propelled by a fear of sunk-cost: the uncomfortable sense that this substantial investment either needs to be rapidly justified… or written off completely.
In fact, in most cases like the above, neither option is necessary. Most ostensibly ‘failing’ PIMs are recoverable, as the software is technically live. The real failure factor is the operating model surrounding the PIM: It’s a case of:
- What the business is asking product data to do
- What the catalogue structure really looks like
- Whether they can afford the enrichment effort that their channels demand
Restarting the whole endeavour isn’t going to change those constraints. It’ll simply ‘repackage’ them in a new implementation. This article examines exactly why a new PIM solution is failing and how to remedy the situation without having to write off the investment and then spend yet more money to replace it.
Forced adoption: A fool’s errand
If the PIM doesn’t turn out to be the cheapest, fastest path to getting channel-ready product information out of the door, users aren’t stupid – they’ll bypass it. And this isn’t a symptom of resistance to change; it’s the logic of throughput. Sure, you can mandate usage, but what you can’t do is impose trust. If your teams don’t trust the system to reflect reality (or when the PIM simply slows them down) they’ll cover their backs by keeping parallel versions elsewhere of what they consider to be ‘the truth.’ Senior management then has the illusion of adoption (because records exist in the PIM) but on the ground, the real work is still going on as if it largely didn’t exist.
You can’t boost sub-optimal adoption rates by using more internal communication, more training sessions, or more ‘PIM champions’ evangelising around the organisation. These interventions make the mistake of assuming that the system already fits the work. In fact, when a system doesn’t fit, training simply teaches people how to suffer the consequences more quickly and efficiently.
How to start: A forensic pause
Rescue work begins by stopping the programme from making itself worse. When a PIM deteriorates, it’s usually because new scope keeps being added to an unstable foundation:
- More attributes!
- More categories!
- More workflows!
- More feeds!
Hold on a minute. Take a deep breath. Take a controlled pause:
- Freeze new functionality and catalogue expansion
- Stabilise inbound data flows so you’re not importing fresh inconsistency every day
- Pick a diagnostic “thin slice”: one profitable product family and one high-impact channel output (your website, Amazon, distributor feed, catalogue)
This thin slice is significant because it forces your people to be precise. “Our PIM isn’t working” turns into: “This product family cannot be published to this channel through the PIM without manual correction.” That’s a solvable issue.
Diagnose the root causes, not the symptoms
Symptoms are visible: Missing attributes, duplicates, slow onboarding, user complaints, unreliable exports. Causes, on the other hand, are structural, and during a PIM rescue situation, the causes tend to fall into five repeatable failure modes. It’s your job to identify which one is most prevalent in your thin slice of operational data.
1) Data swamp: chaos migrated into a new system
You didn’t cleanse the data – you simply relocated it. Duplicate SKUs, inconsistent units, free-text values, and half-populated records were lifted into the PIM and then argued over (and at higher cost). The rescue mission here is pragmatic: establish a baseline for the thin slice, correct the worst patterns, and, critically, prevent new bad data from getting into the system.
2) Overbuilt schema: structure exceeds enrichment capacity
A schema can be correct yet still be operationally impossible. If the data model requires hundreds of attributes per item, but the business is unable to sustainably produce and maintain all of them, the PIM will permanently be in a state of incompleteness. The tell-tale sign is a constant need for exception handling: SKUs can’t be finished, there’s a growing backlog of approvals, and – yes, you’ve guessed it – people revert to spreadsheets to hit deadlines. Real rescue means reducing your mandatory fields to a level which genuinely drives selling, compliance, and findability for the selected channel.
3) Governance black hole: No enforceable ownership
If no one owns attribute definitions, value lists, and approvals, data quality is an ongoing negotiation among departments. It’s slow, and slow systems get bypassed. “Everyone owns product data” sounds robust on the face of it, but what it actually means is: “No-one truly owns it.” An effective rescue needs explicit ownership by data domain (such as compliance tributes, technical specs, marketing copy), each with clear authority to decide and with a clear path for escalation.
4) The ‘theatre’ of workflow: The process exists, but the work happens elsewhere
A large number of PIM workflows are designed more for visibility and control than for actual throughput. If approvals add days without reducing the need for rework, people will route processes around them. So initially, rescue starts with minimal controls to prevent publishing bad information. It then adds workflow steps, but only when these remove real friction (like: Repeatable checks, fewer disputes, fewer re-edits).
5) Integration drag: Unreliable handoffs create a parallel universe
If feeds from and to ERP, DAM, eCommerce, or marketplaces are inconsistent or inherently fragile, business users keep ‘safe’ copies in other places (which is entirely rational behaviour given that risk). The rescue mission focuses on stabilising critical flows of your thin slice of catalogue data, end-to-end. Thus, the PIM becomes the most reliable way to publish product information, not a kind of optional extra.
A sustainable fix: Re-sequencing the programme to rebuild trust fast
Recovery should not be a re-implementation with a more positive-sounding name. It’s a re-ordering of work so that confidence returns before difficult-to-fulfil ambition.
- Define “channel-ready” for the thin slice. Make the finish line explicit: which attributes, assets, and validations are required for this channel?
- Simplify the model to reach that finish line. Cut mandatory fields with ruthlessness; reduce choice paralysis; standardise value lists.
- Make ownership unavoidable. Assign stewards and approvers for the domains which matter to the slice; eliminate shared ambiguity.
- Gradually introduce automation. Start off with validation rules which block incomplete publishing and add approvals only where they shorten cycle time.
- Train to workflows, not screens. Role-based training should be built around your slice of data reality: For instance, “how we take this product family live on this channel in five days” is a SMART training outcome.
- Deliver visible wins. Use measurable metrics: Onboarding time, publish error rates, hours spent on rework, and percentage of feed acceptance. Why? Because forward momentum enhances credibility.
When starting again is justified
A start-from-scratch approach only makes sense if a platform cannot represent your catalogue logic without extreme customisation, or when the build is so bespoke that substantive change becomes prohibitively expensive, or when critical integrations can’t be stabilised at an acceptable cost. These types of cases exist, but they’re the exception to the rule, not the default explanation for poor levels of adoption.
The real conclusion
Most underperforming (or, better, under-used) PIMs are recoverable once you confront the structural mismatch driving people’s ‘bypass behaviour’: the business is demanding a level of product completeness and channel specificity that the organisation cannot produce, govern, and keep current at the speed and unit cost it requires. Until you sort out that mismatch, forced user adoption will fail. Because users know perfectly well that bypassing the PIM still remains the cheapest way to get products to market.
PIM health check
If your PIM is live but circumvented, get in touch with us today at Start with data to book your PIM Health Check. We’ll audit a thin slice of your operations (one product family, one channel), identify the dominant failure mode, and quantify what is preventing the PIM becoming the path of least resistance, and what you need to do to remedy the situation.