Transforming Product Information at OWC

Where Product Information Started

When I joined OWC in 2004, the online catalog reflected the information available from the company's ERP. Everest provided the core product record and several marketing description fields, but much of the detailed product information, compatibility information, specifications, and selling points still had to live as prose within those fields.

That was enough to identify and sell a product, but it wasn't enough to explain increasingly technical products to customers trying to determine exactly what would work with their hardware.

The important distinction was not that the information didn't exist. The problem was that much of it wasn't structured.

Breaking Out of the ERP

By 2015, my colleague Chris was creating individual product pages outside the constraints of the ERP, giving us far more freedom to present products than the ERP descriptions allowed. But building each page by hand was time-consuming. I was brought in to help with the data entry and coding, and the two of us became the team responsible for assembling the product information needed to sell each product online.

Working directly inside that process exposed me to its scaling problems and helped drive the standardization and systems work that followed. We approached the pages almost as product brochures, hand-coding the HTML and CSS for each one and incorporating all the product information we could find.

The freedom was valuable. We could explain a product properly, incorporate imagery, technical details and compatibility information, and organize the page around the buying decision rather than around the fields available in the ERP.

But the freedom came at a cost.

Each page was individually maintained. Cross-linking was manual. Search keywords sometimes had to be incorporated into the code when the appropriate terminology wasn't available through ERP data. Roughly 75% of our time was spent coding pages by hand, with the remainder divided among administrative work and other content responsibilities.

More importantly, copy-and-paste errors and duplicated information that wasn't completely updated could result in incorrect product information reaching the customer. For a company selling upgrades where compatibility matters, that could mean an incorrect purchase, a return or exchange, and lost profitability.

We had created a much better product experience, but the process used to create it couldn't scale.

A Hand-Assembled Product Experience

The page combined manually authored product information with dynamically supplied storefront values. Product positioning, features, imagery, specifications, included items, and compatibility information were maintained in the page, while transactional information such as SKU, availability, and price was supplied by the storefront.

<div class="ndsc_features_title">
    Conveniently share a keyboard between multiple devices
</div>

<div class="ndsc_features_subtitle">
    One touch quick switching
</div>

<div class="ndsc_features_text">
    ...
</div>

findInfo.itemNumber
itemAvailability(...)
thisPrice

Creating Structure Before We Had the System

Before pursuing a formal Product Information Management platform, we began improving the process ourselves.

Working with our lead Graphics Designer, we created a common structure that every product page would follow:

• ERP Information
• Product Imagery
• Copy
• Product Details
• Compatibility
• Flexible Content

The flexible section was intentional. We were still discovering how the information needed to be organized.

Over time, as we encountered more products and refined the structure, that catch-all section became unnecessary. We had developed an organization capable of accommodating the information consistently.

The result was still a manual HTML production process, but it was no longer arbitrary.

Standardizing the pages also made the existing catalog scrapeable. Information embedded in years of HTML pages could be extracted into spreadsheets, normalized, and prepared for eventual migration into structured databases.

We were effectively developing a product-information model before we had a PIM capable of storing it.

Making Compatibility Part of the Product

Compatibility was particularly important to OWC's business.

Product Development tested products against individual generations and configurations of Apple hardware. A component working with one year's version of a Mac did not necessarily mean it worked with the next. Processor changes, firmware requirements, connectors, and other hardware differences could all affect compatibility.

Our job was to turn that testing into information customers could actually use.

We maintained reusable descriptions of the machines and associated products with every compatible option rather than forcing customers to decipher the underlying technical differences themselves.

A customer shouldn't need to become an Apple hardware expert to buy an upgrade.

OWC had already done the testing. The product information needed to preserve that knowledge accurately enough that customers could relax knowing the product they selected would work.

Turning a Part Number Into a Control

The same need for reliable information became especially apparent when working with used and refurbished Macs.

Initially, a part number could be entered into the ERP and the specifications for that machine sent to us in an email for publication. There was little protection against an existing part number being reused or a specification being mistyped somewhere in the process.

Once incorrect information entered that chain, the error could propagate all the way to the website.

I created a master spreadsheet containing the specifications that changed across individual Apple releases, along with the upgrade configurations OWC offered. From that data, I developed a 25-position part-number schema in which each position had a defined meaning.

With the code key, someone could look at the part number itself and determine how that Mac was supposed to be configured and built to order.

Reaching the Limits of ERP, HTML and Spreadsheets

The improvements worked, but they also exposed the limitations of the underlying systems.

The ERP was designed for operational and ordering information, not the depth of structured product content we now needed. The HTML catalog could present that information but wasn't an appropriate database for maintaining it. Spreadsheets helped organize and transform the data but weren't a sustainable source of truth.

Product imagery presented a related problem. Images needed their own organized repository and relationships back to the products that used them rather than simply existing as assets referenced manually from individual pages.

The problem was no longer how to build product pages faster.

We needed an information architecture capable of managing product data, compatibility, digital assets, and the relationships among them at catalog scale.

Preparing 30,000+ SKUs for a PIM

OWC evaluated commercial Product Information Management platforms and selected Agility Multichannel.

My role extended beyond the eventual presentation of product information. I was involved in preparing the information, processes, and organization necessary to make a PIM implementation viable.

The catalog contained more than 30,000 SKUs, with information distributed among ERP records, years of product pages, spreadsheets, and other internal sources.

• Data cleansing and normalization
• Product taxonomy and information modeling
• Data governance
• Extracting structured information from standardized product pages
• Preparing and validating data for migration
• Mapping existing information to the new model
• Defining relationships among products, compatibility information, and digital assets
• Working across Product Development, Marketing, and technical stakeholders to determine how information should move through the organization

The earlier standardization effort paid off here. Instead of manually reconstructing years of product information, the increasingly predictable HTML structure allowed much of that content to be scraped into spreadsheets, reviewed, normalized, and prepared for database import.

Building the Workflow Around the Data

The PIM was only one part of the problem.

Reliable product information also required a workflow for getting information from the people who knew it into the systems and ultimately onto the website.

I designed and administered Jira-based workflows incorporating email, Confluence, and Pentaho. Rules could route requests to the appropriate subject-matter experts, collect the information required for a product, and support the generation of complete e-commerce product families from structured data and reusable templates.

The intended architecture wasn't simply to replace one system with another.

ERP still had a job to do. The PIM had a different job. Digital assets had their own requirements. The objective was to define authoritative information, structure the relationships among it, and ultimately synchronize data entry and movement across the systems rather than repeatedly re-keying the same information.

Where the Project Landed

By the later stages of the project, much of the difficult data-readiness work had been completed. Years of product information had been organized, cleansed, and prepared for loading, and the project was approaching implementation.

The implementation strategy ultimately changed before I left OWC, but the work reinforced something I've carried into every systems project since:

Installing the software isn't necessarily the difficult part.

The harder work is understanding the information, removing ambiguity, establishing ownership, creating a model that reflects how the business actually works, and designing processes that keep the information reliable after it enters the system.

From Product Pages to Product Information Architecture

What started with two people hand-coding individual product pages evolved into a structured approach to managing product information at catalog scale.

The goal throughout was the same: reduce the effort required to bring accurate products to market while making it easier for customers to confidently buy the right product.

What This Work Demonstrates