Product Taxonomy and Product Catalog

Until recently, telecommunication operators might have been seen as the dinosaurs of the IT industry. Big, slow, and old, at least compared to the new technology companies that act more like cheetahs – fast, agile, constantly innovating, failing fast but coming up with something new all the time.

For decades, telecommunications has been and continues to be a critical aspect of our society. And while the speed at which the industry has changed has been slow, it continues to innovate and grow, nonetheless.

In the last decade, that slow pace changed for the whole industry, as tech has accelerated so quickly that they now must manage hundreds of products, thousands of propositions, and rapidly deploy new technology. With the increase in competition, it’s either keep up or be run out of business. Now, even Telcos must be fast and agile like a cheetah, albeit one with a large amount of luggage to carry.

Unsurprisingly, this shift has had a huge impact on the telecom industry. One area in which these changes had the biggest effects is Product Catalog Management.

Product Catalog Management

For companies with just a few products, a simple list may be enough to keep track of everything. When that number starts to grow, however, a method for grouping and sorting is needed because a flat list makes it impossible to navigate or even comprehend the products being offered.

To ensure that isn’t the case, new levels of complexity must be introduced into the product catalog to be able to manage a greater variety of products and the combination propositions that must be quickly and efficiently brought to market.

The science of categorization and grouping is called “taxonomy”. Usually, the first step of the Product Catalog evolution in a Telco organization’s life is defining and building their Product Taxonomy.[1]


  1. the science or technique of classification.
  2. a classification into ordered categories:
    a proposed taxonomy of educational objectives.
  3. Biology. The science dealing with the description, identification, naming, and classification of organisms.
  4. Corporate Taxonomy: The hierarchical classification of entities of interest to an enterprise, organization, or administration.

There are multiple use cases for a taxonomy, but it is hard, if not impossible, to build a single structure to satisfy all these use cases. One approach might be to build multiple taxonomy structures, but those, too, can be hard to manage.

To choose the right approach, we must first consider how the taxonomy is to be used and what the goals of it are. A few common factors to be considered in Product Taxonomy building are:

  • Make navigation simple so customers and/or users can find what they are looking for. It should be intuitive, and selecting the right product should be obvious.
  • Consider the technology similarities in the grouping of products.
  • Reflect the organization structure, i.e., if there is a separate Fixed Line department within the organization, then their products should be grouped together.
  • Be considerate of the financial reporting structures and that these are most often rigid, and usually dictated by regulation.
  • Include generic reporting requirements, with categories agreed up front to reflect what levels the organization wants to track so that key parameters can be reported on and summarized appropriately.

Choosing a Product Taxonomy Tool

It’s hard to manage a Product Taxonomy in a tool like Excel, which is why many recommend choosing some sort of specialized platform for it.

When creating the taxonomy, it’s crucial to use ID-based product identification instead of relying on product names because they will likely be inconsistent between the internal and marketing descriptions. In a world where product branding is so very important, the name of products may change very frequently, and having a static ID enables identification of the products with no need to update the hierarchy in case of a name change since the linkage is based on the non-changing, static IDs.

Product Information Management

The next step of the evolution is to enrich the Product Taxonomy data with relevant and useful information, called Product Information Management (PIM).

Having the list of products in an organized hierarchy is useful, but very soon the requirement to store useful internal and external information against the product will arrive from business stakeholders and it is bound to become a bit cluttered. Such useful information could be the internal contacts for a given product, internal and external documentation, or marketing collateral.

New products are constantly being developed, and old ones are getting decommissioned. As part of the central Product Taxonomy, this must also be tracked to show the product’s status. Even within a live status, different stages can be distinguished (e.g.: Introduction, Grow, Mature, Decline) in which different marketing strategy or technology management is needed. This enables better planning and the building of a product portfolio strategy. This crucial process is the Product Lifecycle Management (PLM), and best practice is to track the products in the central repository from cradle to grave, and into the inevitable afterlife.

Importance of a Central Product Catalog Solution

Products are typically modelled end-to-end, including the commercial, technical, service, and resource details in a single, standard model. Once the product management is mature enough, there will then be a need for a central Product Catalog solution.

Without defined standards, the Product Model will not work. An example of this is the TMForum organization defined data model for Product Catalog[2] which is part of the Information Framework (SID) Standard. Many operators have taken this model as part of their solutions; however, the interpretation and the level of adoption varies.

In the TMForum/SID Product Catalog model, there are 5 key entities used to model products:

  • Product Offering: The commercial representation of the product. This is what the customer buys… Price and terms and conditions defined.
  • Product Specification: The technical definition of the product. This is what is provisioned to the customer. It is focused on technology, with no commercial considerations.
  • Customer Facing Service Specification: The services the customer consumes. It is visible and known to the customer. It can be configured but cannot be sold on its own.
  • Resource Facing Service Specification: Internal, operational services needed to fulfill the Customer Facing Services. This is not visible to the customer and needs to be configured and managed by the operational team.
  • Resource Specification: Physical or logical resources required to fulfill a service. It can be customer facing such as a device explicitly allocated to the customer (e.g.: mobile phone) or could be only internal where the resource is utilized to fulfill a Resource Facing Service.

TMForum/SID defines the Product Catalog Data Model; however, it is not explicit enough, and can be interpreted in many ways. Without strong guidance, the Product Catalog tools may treat the entities in slightly different ways.

Another problem is that the SID framework cannot include everything, therefore the gaps are filled by the Product Catalog vendors, which are not always compatible with other solutions. Within each tool, how a Product is modelled can be very different, and incompatible, complicating any later move as a result of changing requirements or licensing.

Despite the challenges of the TMForum/SID model, it continues to get more and more attention among product owners. The standardization is key to product integration and automation. In order to stay competitive and enable digital ordering, a Product Catalog solution is a must-have for a modern Telco company.

When organizations fail to adapt to the changing world of product management and taxonomy, it results in a reduced speed to market, significantly diminished flexibility in the development of propositions, and ultimately falling behind their competitors and loss of market share.

Indeed, even where an organization recognizes the value provided from a taxonomy-driven product catalog management, successful implementation requires a number of factors to be understood, including:

  • Platform selection must ensure that the tools chosen are able to support the need.
  • Systems integration is required in a way that allows for a fully digital product lifecycle, driven by the underlying taxonomy.
  • Customization of products must be considered and supported, especially for Enterprise products, in a way that does not add excessive complexity.

When organizations have failed, it is typically the result of not thinking about the end-to-end implications of the platforms that are built. Examples of this include trying to use an existing CRM or another platform in ways not intended, which either fail entirely or result in extremely high development costs. Better to invest in a new platform that is designed with this in mind than reuse something inappropriate.

Becoming the Cheetah

These days, no Telco can afford to be the dinosaur. As more try to position themselves as a TechCo not Telco, there are many key enablers; however, lack of understanding of their products and propositions is a major stumbling block for many in the race to ‘Digital’.

Knowing your market offering in a way that can be used by all from the CSR through Product Manager and ExCo, consistently and repeatably, not only streamlines time to market but it also improves the ability to bring together propositions, not just products, and ensures that success or failure can be measured and understood in real time.

Key Telco Product Catalog Vendors on Market

Cartesian is an expert in Taxonomy and has the experience to help any Telco or TechCo understand the offerings they have and drive the transition to a truly Digital organization. We have a wealth of practical experience in helping our customers make the right decisions in Product Management to streamline delivery with a taxonomy able to handle unknown future product types easily.

Our specific experience has been across many product catalog applications, including:

  • Amdocs Enterprise Product Catalog (EPC) (also known as MEC: Master Enterprise Catalog)[3]
  • NetCracker Product Catalog[4]
  • Vlocity
  • Sigma Systems Enterprise Product Catalog[5]

The above examples are all built based on TMForum/SID data model.

How We Can Help

Contact Cartesian for further information on how we can help you build a winning taxonomy.