The goal of an organizational PIM strategy is to create, maintain, surface and distribute a single source of truth with respect to product data. That single source of truth is used to fuel sales channels such as ecommerce websites, print catalogs, marketplaces, and social media platforms. But, it doesn’t stop there.
That single source of truth should also power customer care, answering questions while they’re chatting or speaking with a customer. As distribution facilities pick and pack product, it should help to automatically identify and kick out errors. And then it should assist the facility with validating that the correct products are included in a drop shipment. This single source of truth should be used to engage with partners such as translation, nutritional and formulation attestation, regulatory compliance, state and federal agencies, and product identification, traceability and recall. It should be used by strategic pricing teams. It should gather and redistribute user-generated feedback from both digital and offline channels. We could go on, but I think you’re starting to get the point.
I’m not even done writing this article and I can already sense a percentage of readers bristling at what sounds a lot like manifest destiny for a PIM: the idea that a PIM should be able to absorb the complex needs (both in terms of data and functionality) of any part of the organization. Let me be crystal clear: that is not at all what I am suggesting.
Inventory, Pricing, Ecommerce platforms, Business Intelligence, Asset Management and other systems have a place in the organization. These systems are equipped to handle the types of problems and questions that get resolved by those disciplines. Michael Mezger and Marc Hölzle wrote a fabulous article a few years ago that flagged common mistakes in PIM/MDM implementations. Among those mistakes are believing that it’s possible to create a “super tool,” attempting to future-proof your solution, and in their words, “raising the expectation that all problems will be solved, including those for which, so far, nobody has been responsible.”
Businesses tend to set up a data model that is able to deal with every unknown situation, regardless of its intended use […] Don’t do it! When designing your system, focus on your actual requirements.
What I am suggesting is that within your organization, there is such a thing as a product master even if it isn’t mastered at a single source. This master represents the common data leveraged across disciplines. The data that has value for a broad cross-section of the business.
PIM fails to realize its true potential when it is isolated to a specific business function or team. When the only people with access to the system are Marketing, Sales or Digital, a PIM system becomes just another copy of isolated product information with no authority or relationship to other data stores across the business.
Start Small
When implementing a PIM, teams need to start small. Focus on an isolated problem or opportunity and solve for it. And the problem or opportunity with the most direct path to revenue should always take priority. In other words, focus first on problems like taking product to market, shortening launch timelines (or hitting launch dates at all), enhancing customer experience on the digital shelf. For this reason, many PIM systems compete with their connectedness to a broad retail ecosystem.
The initial business case for a PIM implementation should focus on revenue opportunities and building category share. Avoid nebulous concepts like “increasing efficiency,” “improving content quality” and “reducing complexity” which are difficult to measure (and/or the rubric for measuring these goals is subjective). Not that those aren’t worthy goals – they’re just not mission one.
If you choose to focus on sales channels first, it’s a good idea to prioritize amongst your retail and technology partners. The retail ecosystem is overly politicized and commercialized, making it difficult, time consuming and expensive to work with some retailers. Many partners require you to work through a specific provider, or to use a named third-party to validate the accuracy of your claims. As you decide what to tackle next in your content strategy, you need to constantly evaluate your distance from the goal line with every project.
Keep Costs Low
10 years ago, an enterprise PIM implementation could cost $3M and take nearly 3 years. Part of the reason to start small is to demonstrate the fastest time to value possible. Demonstrate the value of a single source of truth, and post the win. There’s no reason why an implementation of limited scope should break the bank. And there’s no reason why a minimally viable launch should take more than a quarter.
Distribute Access
Your goal should never be to centralize and restrict access to product data. Rather, the name of the game is to empower the business with accurate, consistent and usable product data. Business teams must be able to access the product information they need quickly, easily and wrapped in context they understand.
Sometimes that means working with business teams (for example, Customer Care) to best understand the information they need and then tailor their search and discovery experience to be as valuable as possible. Sometimes it simply means feeding another system (for example, Inventory) with a product master, and letting those users build upon that master data inside their native business applications. In either case, the primary goal of the PIM team is to make high-quality product data broadly available across the organization, and to focus on its utility for business teams.
Test and Learn: Continuously Demonstrate Value
The core responsibility of the PIM team is to understand how information is created, how it is used, and to make it as easy as possible for those business teams to leverage the single source of truth. If users are recreating product data from scratch, if they are downloading, manipulating and distributing copies of product data, the team has failed.
The PIM team should work collaborate with the business teams, soliciting feedback on both the data and the experience. They should stick to a strict sprint and release schedule of every two weeks. That timing is critically important. Any longer than two weeks erodes the confidence of the business partners. And honestly – changes should never take longer than that. Business teams need to see that feedback is getting incorporated, that the team is listening, and that it’s relevant and valuable for them.