The Product Catalog Problem
At ATG, we’re lucky enough to spend most of our days with clients who are transforming the way their company sells its offerings. The motivation for this change can differ from organization to organization. Some companies have outgrown and outpaced their homegrown back-end systems. Others are merging subscription revenue with a traditional one-time sale business model, and many more are striving to cut their time-to-market with new products.
Engagements vary, but over the years, we’ve learned there are a few common aches and pains. These pain points typically surround the heart of an organization - its product catalog.
The product catalog is a simple concept – it is a list of a company's products and pricing. However, the waters muddy quickly as companies grow and product data starts innocently scattering throughout a myriad of applications and databases.
For example, assume you work at a cell phone provider. Ask yourself a very simple question: What is your product? The answer should be straightforward. You sell phones and data plans that your customers need to stay connected with family and friends. However, when taking a closer look at this set of offerings (when changing a business model or adding a new system, this must happen very early in the project), the complexity becomes very apparent.
Let’s keep going - the next two steps in our exercise might be a little more eye-opening.
First, write down each application where data about your product is stored. Second, list the attributes about the product that are stored in the system (call it a rough data model). Circling back to our cell phone carrier example, assume we have some representation of our product in the following systems:
E-Commerce
Your company website allows customers to upgrade/downgrade phones, adjust data services, and manage their online profile
Mobile App
CPQ
Contract Management
Order Management & Procurement
Billing
Revenue Treatment & Financial Mgmt.
Other
I’ll spare listing out the data attributes for the sake of brevity, but it shouldn’t take long to realize we’ve got a bit of a mess on our hands. With some level of product data stored in a mere seven systems in this example, we'll have a heck of a time adding products or modifying any of our existing offerings.
Let’s circle back to our very first question: What is your product? On the surface, you sell phones and data plans as a subscription. Your e-commerce platform might require substantial meta data about the phone: brand, model, color, marketing description, resolution, camera megapixels, list price, discounted price, etc. Conversely, your procurement system needs to know serial number, SIM card info, data limits, and other information about the phone’s hardware. Your Financial Management System (FMS) system needs to know the phone’s price, the contract’s start/end dates, the taxable portion of the sale, and all associated product codes.
Product Catalog Maintenance
We could repeat this exercise for the remaining applications listed above, but the underlying issue is the same. What a product “is” changes depending on the lens of the system and its user group. If your head doesn’t hurt yet, ponder how all the above scales when we bundle products together, or sell in different countries and languages. Hopefully the product catalog problem has unmasked itself. How can you keep these systems in sync, improve your revenue numbers, and be the fastest to market with new offerings that respond to our customers’ needs?
The good news is, we’ve got options.
At Advanced Technology Group, we often break an organization’s product catalog domains into three groups: Customer Facing/Selling, Billing, and Provisioning/Fulfillment. In each of these catalogs, what a product “is” will vary. A cell phone subscription might be a bundle in the selling catalog because it is the join of a cell phone and a data plan. Alternatively, the billing system looks at these components as separate products with an additional OTC (one-time-charge) being assessed for initial procurement.
Finally, the fulfillment catalog might also view the sale as requiring two products, though it doesn’t care about the OTC from the billing system or the color of the phone from the selling system. Isolating a product catalog into these groupings often proves beneficial, as the data about each product is grouped by business function. However, with each catalog being isolated, the overhead with managing each catalog can be burdensome.
An emerging trend in the market is to take a platform-based approach. Take Salesforce, a CRM (Customer Relationship Management) platform traditionally allowing folks to manage customers from Lead to Order. Now, with their launch of both Salesforce CPQ and Billing products, SFDC is making a strong case for being the lead-to-cash solution for many of today’s emerging service providers. Through the various revenue stages (lead, opportunity, quote, contract, order, provision, bill, renew), the product data needed to close the sale can come from the same model (depending on the complexity of your business), reducing the number of integrations needed to take a quote and make it an invoice.
This isn’t a silver bullet approach, as the tail-end of the solution is still maturing with each Salesforce release, but there are some serious advantages worth considering.
Second, and probably most common, is a distributed approach. A distributed product model isolates product catalogs by business domain. This method often aligns with organizations employing a “best in breed” systems strategy, where the company’s back office system count is higher as each step in the lead-to-cash process may take place in a different application.
Finally, some organizations turn to a centralized model, requiring a heavy reliance on event-messaging and APIs to pass product data from a centralized master catalog to the appropriate systems. In this approach, an MDM-like (Master Data Management) strategy is used, where a master catalog is built to hold every attribute of a product needed by all systems. When a new product is added (or an existing product is modified), an event driven process is invoked to publish the appropriate data additions/updates to select systems. Call this the unicorn approach because it requires applications that can be interacted with via API, and an engineering team capable of building out an architecture to facilitate product updates.
To summarize the above, this Product Catalog stuff is hard. There’s no easy way to flip the switch and embrace any of the above solutions, even though all the above problems are real. Despite that, we strive not to understand what a product is but what a product is in a specific context.
If you’re shuffling your people, process, and/or technology to transform their business model, a little upfront thought goes a long way. Take some time to understand where your product data lives today, where it will live tomorrow, and how this data flows through the Lead to Cash process.
Mitch Colyer is a highly-sought consultant in the cloud billing and CPQ space. He has been at Advanced Technology Group since 2014 and works out of the Missoula Solution Center.
In his free time, Mitch enjoys hunting, fishing, and gerbil ranching.
