Most product information processes work. That is what makes them difficult to assess.
Nobody schedules a review of a routine that has not failed. The signal usually arrives as growth instead: two new categories with attributes nobody has defined, a marketplace with its own required fields, a second market that needs localized content, an acquisition that brings a second ERP, or simply more products than the current arrangement was built around. None of those events break anything on the day they land. They expose how much of the work was being absorbed by people rather than carried by the process.
That absorption is the thing worth measuring. A team that quietly re-keys dozens of attributes into a retailer portal every launch week is running a functioning process and an unfunded liability at the same time.
Post 2 showed how requirements, enrichment, validation, workflows, and review create a managed path for product information. The harder question is whether the path you run today can carry what the business is about to put on it.
What you are assessing
Every company that sells products manages product information in some form. A PIM is the system that supports that work at volume. Whether you have one is a procurement fact. It is not an assessment.
The useful question is whether the current combination of people, processes, data structures, rules, and systems can support what the business needs next without producing recurring manual work, inconsistent information, unclear ownership, or failures that surface downstream. Five areas carry most of that load. Read them one at a time, then read them together, because the pattern across them tells you more than any single finding.
Do not start from the assumption that the software is the constraint. Weakness shows up just as often in an undefined attribute set, an integration scoped for one channel, a review step nobody owns, or a configuration that made sense when the catalog was a third of its current size.
1. Ownership and workflow: can anyone say what happens next?
The job here is simple to state and hard to run. At any moment, someone should be able to say who owns each part of a product record, what has to happen next, which reviews are required, what is blocking completion, and who last changed a value and why.
Weakness looks familiar. Status lives in a status meeting. A launch stalls and it takes two days of messages to learn that a regulated attribute was waiting on a person who has been out since Thursday. Two teams both believe the other owns product copy for the new category. Someone corrects a weight and no one can reconstruct which value was right or what it was based on. And when the person who knows which retailer treats which field differently takes another job, a working process degrades within a quarter.
The consequence is not only delay. Unclear ownership converts every exception into an investigation, and investigations are the least visible cost in the operation because they never appear as a line item. Collaboration is often described as sharing information on one platform. The operational version is narrower and more demanding: visible ownership, defined steps, accountable review, and a change history you can read afterward.
Diagnostic question: For a product currently in flight, can you name the owner of each unfinished part of its record and the step it is waiting on, without asking anyone?
2. Data model and scale: what happens when the next requirement does not fit?
Your data structure is a set of decisions about what a product is: which categories exist, which attributes belong to them, how variants relate to parents, how products connect to accessories and replacements, which values vary by market, and which are set by a standard rather than by preference.
The test is absorption. New products and variants, new categories and attributes, new markets and languages, new relationships and hierarchies, new recipient requirements, changed business obligations, and significant increases in product volume all arrive as demands on that structure. A flexible model can absorb many new requirements through governed changes. An inflexible one pushes teams toward exceptions and workarounds.
The workarounds are recognizable. Attributes get overloaded, so a field named for one purpose now holds three, distinguished by a convention only two people know. Variants get created as separate products because the model has no way to express the relationship, which doubles the maintenance on every future change. A second market gets served by a duplicated set of records rather than by localized values on one record. Category attributes get added as free text because adding them properly requires a project nobody has scheduled.
Each workaround is reasonable in isolation. Together they produce a structure that is expensive to change and increasingly difficult to describe to anyone new, which is the same thing as saying the next requirement will cost more than the last one did.
Diagnostic question: The last time a new channel or market introduced a requirement your structure had no place for, was it configured or worked around, and who maintains the workaround now?
3. Integration and continuity: does the meaning survive the trip?
Product information does not live in one system. It starts in source systems, picks up commercial and logistical values in an ERP, gets built out in a PIM, draws on digital assets, feeds commerce platforms and syndication, reaches retailers and marketplaces, and comes back as reporting.
Assess this at two levels. First, can the information move between the systems that need it? Second, does its structure and meaning stay intact when they move?
The second level is where most of the damage happens, and it is quieter than an outage. A category in one system maps imprecisely to a category in another, so classification drifts a little with every sync. Units of measure convert on the way out and not on the way back. An attribute that is mandatory in one system is optional in the next, so completeness is real in one place and theoretical in the other. Two systems both hold a weight, both are current, and neither is defined as the one that governs.
You can usually spot the consequences without any tooling. Somebody exports a file every Monday to keep two systems agreeing. The same enrichment work happens twice because the second system cannot receive it. A retailer onboarding slips because building the feed is a project rather than a configuration. A downstream flow fails and the first question in the room is which system had the right value, and nobody answers quickly.
Diagnostic question: For one attribute that matters commercially, name the system that governs it, then check whether every other system holding it agrees today.
4. Governance and validation: what stops a bad value from moving?
These two words get used interchangeably, and the distinction is worth holding onto because it points at two different kinds of weakness.
Validation checks whether information passes a rule: a missing required attribute, a value in the wrong unit, a duplicate record, an asset below the resolution a destination requires. Governance is the layer above it. It determines who sets the rule, which source governs the value, who is allowed to change it, and how that decision can be traced later.
A business can be strong in one and weak in the other, and the failure modes look different. Strong validation with weak governance produces well-formed records that are confidently wrong, and rule sets that quietly diverge because three teams each maintained their own version. Strong governance with weak validation produces clear standards that depend on human attention to enforce, which holds until volume outpaces the attention available.
The stakes are worth stating plainly, and the point survives from the earliest version of this argument: small errors are not small once they move. A missed decimal in a weight or dimension does not stay in the record. It reaches the people making shipping, storage, and shelf decisions, and it reaches them as fact. The cost of catching that at the source and the cost of learning it from a retailer are not comparable.
Requirements also change. A rule set that matched the business two years ago describes a business that no longer exists, and nobody gets a notification when that happens.
Diagnostic question: When a required value is wrong or missing, where does it get caught today, and how often is the answer “a retailer told us”?
5. Activation and visibility: can you tell what is ready and what happened next?
The last area covers what happens when information leaves. Each destination wants the record its own way, with its own required attributes, formatting, and content expectations, which makes preparation part of the job rather than an afterthought.
Syndication belongs here, and it belongs in the strategy. It is one part of a larger job: preparing trusted information for the places it will be used, seeing whether it arrived, and using what you learn to improve the process that produced it.
That last part is where assessments usually find the gap. A team can often publish and rarely tell you the state of what it published. Readiness is estimated rather than known, so “are we ready for the retailer” gets answered by opening four systems. Failures are handled individually, so the same rejection reason recurs for months without anyone counting it. Nobody can say which step produces the most rework, which means process improvement is guesswork with a deadline attached.
Without that feedback, every correction is a one-time event. The failures teach nothing, and the same category of problem returns with the next launch.
Diagnostic question: Can you tell, right now, which of your products are complete and ready for their destinations, and what the most common reason for failure was last quarter?
AI raises the requirement on all five
AI-assisted product-content work increases the need for structured, accurate, and trustworthy product information. It adds new demands to the five areas above rather than creating a separate area to assess.
Gartner projects that 60% of AI initiatives will be abandoned by the end of 2026 due to a lack of AI-ready data. McKinsey found that only 7% of companies have fully scaled AI across their business.
AI can help teams handle parts of the workload. What that assistance does not do is resolve unclear ownership, repair an overloaded data model, determine which system governs a value, or make an unreliable source trustworthy. If the product-information foundation is already under strain, adding AI increases the consequences of those weaknesses.
Reading the pattern across the five
One weak area usually points to a contained problem. A workflow with no assigned reviewer, an integration built for a single channel, a validation rule set that was never updated after the category expanded: these are process, configuration, governance, integration, or scope corrections, and they are worth making on their own terms.
Weakness across several connected areas is a different finding. When ownership is unclear, the structure cannot absorb new requirements, values disagree across systems, and nobody can see publication status, those symptoms share a cause. The operating model, or the system supporting it, no longer matches the complexity the business is running.
Either conclusion is legitimate. Neither one is reached by assuming the software is at fault, and neither one is reached by looking at a single symptom.
Record what you found before you decide what it means
Use evidence you can point to, not impressions. Record what you found in the third column, then translate each finding into an improvement requirement in the fourth.
| Assessment area | Evidence to examine | What we found | Improvement requirement |
| Ownership and workflow | Products currently blocked and the step each waits on. Parts of records with no named owner. Routines that depend on one person’s undocumented knowledge. | ||
| Data model and scale | Requirements from the last 12 months the structure could not express. Workarounds now in production, and who maintains each one. | ||
| Integration and continuity | Manual transfers performed on a recurring schedule. Attributes where two systems disagree. Attributes with no governing system named. | ||
| Governance and validation | Where errors are caught today. Rules that exist in more than one version. Standards enforced by attention rather than by a rule. | ||
| Activation and visibility | How readiness is determined today. The most frequent rejection or failure reason. Whether anyone counts them. |
The fourth column is the output that matters. “Two teams both edit pricing attributes with no defined owner” becomes a requirement for role-based ownership and change history. “Variants exist as separate products” becomes a requirement for a model that expresses product relationships. “Someone exports a file every Monday” becomes a requirement for a supported connection between those two systems.
Written that way, the list gives the next evaluation conversation something more useful than a generic feature list: evidence-based requirements.
