Three Keys to a Successful Product Data Project BEFORE You Start the Project

The words "data quality" have become ubiquitous in the business lexicon in the last 5 years. Businesses are hiring Chief Data Officers to manage their data strategy, businesses are seeing the value of machine learning and powerful data tools to be able to store their data, and data scientists are the new rock stars of the tech world. With all these people and all this new technology we should have no problems achieving our data quality goals, right?

I'm going to barricade myself to what I know, which is product data. I am pretty sure most of what I write below is universal, but I am not the Multi-Domain Master Data Management guru. I know product data extremely well, but I will let you choose how to equate what I write outside of the product data domain.

That being said, the answer looking through that product data lens is a resounding "not even close". Although businesses have product data there are still massive holes in completeness and accuracy. How can this be with all these people and all this technology managing our product data?

The answer here is complex and no single element I will mention will solve every product data issue. However, experience has taught me that there are three primary keys to success when setting up a product data collection and storage system and all three need to occur before you launch your product data solution. Here are the three keys:

#1 Know what quality product data looks like

Many tools promise that they will assist businesses with improving the quality of their product data. In fact, that is the goal of every Product Information Management (PIM) system on the market. As I stated in an status on here recently the one thing those tools absolutely cannot do for any business is tell that business what quality product data looks like. When defining a product data collection and storage implementation it is easy to say "The tool will take care of standardizing our capitalization." or "The tool will normalize our values." The processes built into a PIM system by definition perform the activity of ensuring that a specific business decisions on case, grammar, and value lists are standardized by design.

However, those businesses have to build their normalization and grammar standards into these systems. If they do not have a documented standard for the grammar, case, and value lists for their product data the users of the tool will provide unstandardized data. PIM systems will not look at the string values and tell someone "You're using sentence case instead of title case." That is a process standardization issue that a business need to develop before the first data element is entered into their PIM system.

The other element of product data that a PIM system will not rectify is completeness. Most definitions of completeness state that every mandatory attribute has a value for every product that is attached to that attribute. That is very important. However, how does a business determine they have a complete set of mandatory attributes to say that a product is fully described? The tool will help enforce mandatory rules but it will not tell anyone that they are missing an attribute or that an attribute should be required. PIM tools work with the model provided, but do not build or correct models on their own.

Here are some ideas on the topics a business should cover to understand what their product data quality should look like. It is not complete nor comprehensive, but is a great starting point:

• Understand when an attribute should be mandatory or when it should be optional. Optional attributes rarely get completed during data collection, so having 75% of attributes optional will lead to only 25% of all attributes being complete. A business needs to know what their data requirements are and how to define a fully described product.
• Understand when something should be a string and when it should be a controlled list. Controlled lists maintain much better product data quality, as they force a preset selection from a vocabulary you control. However, having to add a new value for every product is a lot of work that may be unfeasible long term. Businesses need to have a strategy for defining when to use different data types before they build the first controlled list into their PIM.
• Make sure grammar and case standards work in both taxonomy hierarchy and attribution. Having a different standard for case for hierarchy compared to attributes is confusing to maintain, and using two different grammar standards will create odd end-user experiences. A business needs to know ahead of time what their standards are, document them, and keep them standard across all of their product taxonomy elements (Hierarchy and schema).

#2 You Need Product Data Governance before you need a PIM

I hear all the time how Master Data Management will solve everyone's data issues in every vertical of every business as long as they have an MDM tool. This is only partially correct, and can be problematic in the product data space. Master Data Management is a set of principles and processes businesses apply to their "master" data in order to gain control over their data quality. Many mistake the tool for the principles, and then rely on the tool to be their MDM program. The tool only helps apply the MDM rules built in a particular domain, and can not build the processes or the documentation on its own.

The key process in the product space within the MDM framework is Product Data Governance. Product Data Governance sets the rules for case, grammar, hierarchy depth, controlled value list maintenance, and many other important rules within product taxonomy. Without these rules a product taxonomy program quickly descends into what I reference as "the wild west", where everyone builds their own rules as they go and any commonality in those rules is not through best practice. For example, one product taxonomist on a team may choose to always use plurals where another taxonomist uses the singular. It seems like a small issue, but a professional taxonomy should never harbor those types of discrepancies.

The other activity that Product Data Governance manages is giving a set of processes and documentation to maintain a product data collection program. This is where the tools are helpful, as they can be a document store for thesauri and rules for a taxonomy/schema and give process definition to data collection and taxonomy maintenance. Here again the tool can be helpful but does not manage every element. The tool will never schedule a meeting to go over an exception case and then document that case in a useable manner. It will not decide edge case decisions by providing stakeholders a cost/benefit analysis. The tool enforces the processes that are programmed into it, but will not alert anyone when a process is failing or when someone is bypassing the system requirements. Businesses need to understand the processes that are needed to handle these issues and the associated documentation.

Setting up these rules and processes through a Product Data Governance framework and then documenting and enforcing these rules through a Data Governance/MDM tool is a task that needs to be performed up front and maintained across the lifespan of the product and beyond. Attempting to set up these rules after the development has occurred will result in mass re-work, remediation, and additional cost that will slow down the implementation of any bug fixes or change requests in the long run. Mistaking the MDM tool for a Product Data Governance program is like mistaking the Pope for God. The pope did not write the book; he just enforces it.

#3 Know where your data is going

The most important reason Product Information Management tools are purchased today is to manage product data before it is presented on a Content Management System (CMS) or E-Commerce platform. However, most businesses have a need that is causing them greater concern than their own websites: Product Data Syndication. The ability to quickly, accurately and completely push data to retailers economically and within the retailer's specific data format is becoming the biggest challenge to any manufacturer, supplier, or distributor. Soon every manufacturer will have a PIM installed, not to drive sales on their own platform, but to be able to syndicate data to Amazon, Walmart, Home Depot, and every other big box retailer.

Product Data Syndication is also going B2B. Distributors now need data for the products they push to their customers faster than ever and are requiring the same level of data quality as B2C channels. The days of catalogs being shipped with hundreds of pages of products for everything from office supplies to industrial manufacturing supplies to building maintenance are fading. An industrial supply business no longer calls and asks for product information on a grinding wheel; they want to see it on a web site first. Where retailers paved the way for Product Data Syndication distributors in the B2B realm are now driving that highway towards faster data availability with an expectation of better data quality.

If a business fails to see this and builds a product data collection program based on their web site needs they will find themselves re-working their data collection and taxonomy fairly quickly. Understanding that the mechanics of data collection are changing rapidly is a daunting task, as it becomes more difficult every day to keep up with the rate of change. However, understanding where their products are sold, how they are sold in that channel, and how the product data moves from one business to another is key to a successful product data collection program.

While the heading says "Know where your data is going", understanding "how is gets there" and "What format it needs to be in" is just as important. For businesses that I personally deal with we handle this pre-install with a specific meeting just to look through their channel needs. We then build a data model that meets all of those needs with as few channel-specific elements as possible. Product data collection should be channel agnostic, as re-using the same data element multiple times is the goal of a PIM installation. Acknowledged in that sentence is that being purely channel agnostic is a great goal but generally unachievable, as every downstream channel has an intricacy that will most likely need to be handled separately. Keep channel agnostic development as a goal and concede those small elements when needed.

When a data collection systems project is kicked off and the downstream uses of the data are constrained to a single channel, that channel is well served. However, it is likely that any additional channels that are added later will require data remediation to reuse existing taxonomy/schema elements or will require their own channel-specific elements to allow for syndication to occur. Planning for syndication only occurs when all channels are represented in planning, not just internal channels.

An oft-forgotten channel is print. Earlier I stated that the days of printing catalogs were fading, but print is still a viable business use for product data. Brick and mortar businesses still need to print shelf tags, and the data and images to create those tags is generally collected during product data collection. Often the need to print product data sheets into PDFs is neglected to be seen as a print function, but use all the same design tools and formats as ink print. Ignoring print as a channel is an oversight that can cause problems downstream. Here is an example of how print requires attention during the data collection project planning phase.

Let us assume that you have a long description on every product you sell. In order to bold or underline certain text in that description your marketers add HTML markup tags to certain products. Those tags, unless dealt with on output to your print tool, will appear as code in your printed material, making the end product look odd. Do you remove those tags on output, make a rule disallowing the user of HTML tags in that attribute, or create a special attribute just for print descriptions?  All three are viable options, but knowing that there is a need to manage this issue is critical to you having a documented decision on which choice you as a business make.

Now image that you have Titles, Short Descriptions, Medium Descriptions and other string text where these HTML markups might occur. Knowing that first decision allows you to replicate that functionality or process rule across many different attributes instead of dealing with each one individually. Knowing that up-front means less hard coding, less re-work, and less resource costs to deal with these issues later.

In Summary...

The boy scouts tried to teach me 30 years ago why being prepared was so important. We think about being prepared when we go on vacation or when we go camping in the woods, but tend to apply those preparation techniques when we are building data collection projects. Although important, this is not everything you need to prepare for in these types of projects. There are infrastructure questions, change management issues, system requirements and project timeline questions. My three keys are from my experience in seeing projects run where these elements are completed after the project has already started an implementation phase. Knowing what you expect your data to look like, planning for Product Data Governance, and knowing where your data will eventually end up is crucial to achieve the highest ROI on a data collection project.