Defining PIM By Defining Product Information

When I first entered the Product Data world over a decade ago the definition of product information was pretty slim. There was Product Data (Category Specific Data) and Product Content (Images, Copy, Bullets) and every tool in the PIM space tried to optimize that space. Today Product Information Management tool has their own definition for Product Information, from Product Content Management (PCM) to Product Experience Management (PXM) to Syndication Data. None of these definitions are inherently wrong, but none of them are completely correct either.

Defining Product Information

The biggest challenge in manufacturing and retail today is moving the correct data between those two entities in a reasonable amount of time. Retailers want more imagery, more unique content, and richer category-specific data to differentiate themselves from their competition. Manufacturers must take these data requirements and manage them across multiple retailers and their unique data requirements. An entire industry has arisen to attempt to capitalize on this chaos without defining their solutions or attempting to solve the core issues.

Part of the core issue is that "Product Information" is poorly defined. In the absence of any other definition, here is my definition that I only claim due to my experience in this industry:

Product Information is any data that is required for a vendor to represent their products in any applicable channel, any data required by intermediary businesses to represent that product to their clients, as well as any additional information required by a retailer to represent those products within their own channels.

This definition goes beyond Product Content Management and Product Experience Management. These limit themselves to what is visible on a website or a store shelf, seeing the customer experience as the only important factor. However, there are much more complicated issues when attempting to sell a product in either a B2B or B2C environment.

Logistics Data

Before you can sell a product you have to understand how you are going to move that product from the plant where it is build through the shipping mechanisms to the warehousing systems in the target market into the warehousing systems of the selling retailers to the shipping to the end customer. This involves understanding dimensions of the shipped product and how exactly that product can be shipped.

This also means an understanding of not just the finished sellable product, but also how it is packaged and bundled together. Most retailers need to understand these case pack dimensions to understand how and where they are going to store them. If they don't understand the length, width, and height of the pallets on which the products are arriving to their warehouses they can't understand their capacity to store the entirety of their inventory. Simply put, if you cannot provide them this data they cannot house your products.

This might seem like a simple problem to solve. In a perfect world it would, as the GDSN standard somewhat takes care of this. However, not every reatiler subscribes to the GDSN/GS1 standards, and variants between data pools exists. The North American GS1 pools are quite different from the European and Asian data pools, meaning global companies have more than a single pool to deal with. Food Service companies also have to deal with FSENet, which subscribes to the GS1 format but asks for the data in a different format.

Because of these differences, there are serious consequences to getting this data incorrect. Charge backs are the most obvious result, where companies are fined by retailers for getting this data incorrect. However, warehouse holds are just as common and just as expensive. It costs just as much for a product to sit in a holding area for weeks while logistics data is provided as it is for the charge back for providing incorrect data.

Ignoring Logistics Data in the definition of Product Information is a serious delinquency in the Product Data space. It results in expenses for both sides of the equation, as manufacturers deal with charge backs and retailers try to manage their warehouses without the correct information to do so.

Pricing and Inventory

Another important aspect of Product Information is the more transaction-type data points included in pricing and inventory. This is normally handled by EDI transactions, which provide real-time updates to pricing and inventory availability between manufacturer, distributor, and retailer. However, retailers are requesting price and cost information up-front before EDI is available to be able to set their assortment levels.

It therefore becomes vital to understand how to deal with pricing from the onset of product data syndication to enable complete syndication as early in the process as possible. Manufacturers and distributors that have complex pricing, either by contract or quantity breaks, have the most difficult task ahead and require more complex systems to manage this activity. However, providing Manufacturer's Suggested Retail Price (MSRP) and Minimum Advertised Price (MAP) up front is a requirement to complete almost every retailer's data setup.

Inventory on it's own is less daunting. EDI covers this data point pretty thoroughly. However, there are holes. EDI is not used to describe End-of-Life for a product, nor does it handle recall information well. Transmitting data to a retailer to explain when a product is no longer available is often left to conversation as opposed to electronic notification through a system. Life cycle of a product is not handled exceptionally well, which can result in issues at both the manufacturer and the retailer.

Simply put, pricing and life cycle data is a core component of Product Information that is often ignored during the system implementation process, mostly due to a lack of a full ecosystem understanding of life cycle. Your business' system integration strategy is vital to being able to set sources of truth for this type of data.

Regulatory Data

Other forms of Product Information that are often overlooked are the regulatory data that is often required by retailers to sell products. This data is expansive, regulated, and often not easy to find from a source of truth inside an organization. It is also vital to understand where, when, and how you can sell a product.

Often times the assumption is that providing a data point that says something is California Proposition 65 regulated is enough to satisfy regulatory data. This is incorrect. Prop 65 has many facets, including the warning statement that is associated with that flag. The Sourthern California Air Quality Management District (SCAQMD) regulations, Volume of Organic Compounds (VOC) reporting requirements, Wool and Textile Acts, Cancer-Causing materials disclosures, Child Labeling acts, and so many other regulatory attributes are required across a variety of different retail channels. There are over 150 regulatory compliance attributes across the dozens of retailers requiring this form of data to sell manufactured products. From it being illegal to ship bladed knives in New York City to it being illegal to ship an incandescent bulb in a light fixture in California, there is no end to the types of restrictions that apply to everything that is sold.

Ignoring this data and Product Information is a huge miss. It is a dependency for the GS1 standard and almost every retail syndication system in existence. Without a source of truth for this data, which most manufacturers do not possess, the process of aggregating this data becomes ad hoc, excel-dependent, error prone, and a waste of resources working on duplicate efforts to collect this data for each retailer.

Sell Sheets, Hang Tags, and Other Assets

Another often-forget element of Product Information is data that rarely is ever seen by customers. Manufacturers put together sell sheets for their sales force to be able to market their products to the retailers before they ever ask for product data. Safety Data Sheets, Tech Bulletins, and other assets are often forgotten as data that occurs before data is every syndicated. However, much of the data within these assets will end up in the syndication stream anyways, as marketing a product for a retailer to sell often involves much of the data required to sell that same product to a customer. Therefore, your Product Information should always include this type of data. It avoids the duplicate data collection that is nothing more than a cost to your business, and should be seen as mandatory for your syndication systems.

Marketing Copy and Images

Of course marketing copy and images are part of Product Information. With the push to unique content by channel, videos, and 360 images have made this a core component for Product Information. However, there is more to this type of content than the content itself. Many organizations fail to understand two core elements of this type of Product Information: Content Delivery Networks and Metadata.

PIMs by themselves do not provide real-time content. They provide the systems that provide real-time content with that Product Information. Although there are promises with the SaaS PIMs moving towards providing CDN services, a CDN strategy is needed to ensure you are aggregating the right data in the right location. For example, some retailers only accept binary files for videos and images. Providing a URL will not meet their needs, and therefore your PIM system requires the right access to a CDN to ensure it can provide the actual file.

Don't take this as me suggesting CDNs aren't valuable: They are an extremely valuable system for ensuring images and videos are provided in an up-to-date fashion. However, if a business does not understand how to provide what the retailer requires a CDN can be of limited value in some circumstances.

Secondly, the metadata around your images is vital to providing the right Product Information. If a manufacturer provides retailer-specific images or videos being able to understand not just which images to send to each retailer but also when to send them and when to remove them is vital to your differentiation-by-channel strategy. Knowing which images are your main image versus lifestyle shots or angled images is critical, and the licensing of images often require a start and end date when they can be used. The metadata of when, where, and where not to use images is critical Product Information.

A Source Of Truth Versus Book of Record

All of this comes down to a philosophy on Product Information that is often seen as a secondary benefit of Product Information Management systems. Your product data requires a Book of Record for what constitutes a product record. This can often be confused with a Source of Truth for a product record, but that definition can be tricky. A Book of Record for a product record is a reference system where all the Sources of Truth for a product record meet. A Source of Truth assumes that a single system can be regarded as the originating system for a product data point. You can refer to a system as a Single Source of Truth for a product record, but only because it is the aggregation of multiple Sources of Truth. A Book of Record or a Golden Record system is a much better definition of this aggregation point.

Creating a Book of Record system is much more than a database that hold that data. It consists of an integration strategy to understand the source and destination for product information. It consists of governance programs to ensure data is maintained correctly with proper monitoring and controls to avoid decay in data quality. It involves data modelling and product taxonomy development to ensure the right data is collected at the right time. It involves an ecosystem-wide view to ensure that all of these elements are balanced and work in unison rather than being ad-hoc thoughts that are applied retroactively.

In Summary

A Product Information Management tool is just that: A tool. It is not a silver bullet that fixes all the ills in a business. Most of the time the issues companies have with syndication are because they thought a tool would solve their issues. There are system and user considerations, but before those comes a need to understand what constitutes the "Product Information" part of the PIM acronym. Product Information is an asset in an eCommerce world as much as the products a business sells are an asset. Creating returns on that asset are as much a business goal as creating returns from your marketing budget.

This is where experience in implementing a PIM or Product MDM tool is vital. As much time should be spent understanding your products, your existing systems, and your users as the technical aspects of an implementation. Otherwise the return on investment you can achieve with your Product Information will be limited by the understanding of the implementer of the tool.