What Is a Good Product Model

Ah yes, you guessed it - this is yet another reflection on product catalog management. I often have the opportunity to participate in product catalog review sessions, where customers invite us to evaluate their catalog-driven solutions, particularly regarding their product modeling approach. I am very happy if it happens at the beginning of a project; and often less happy if it happens too late when it is really difficult to make changes. Recently, I teamed up with Misha Raev to share our insights on this process - what to focus on, where to look, and why it matters. This is nowhere a complete guideline but we needed to start somewhere.

Introduction

In catalog-driven business architectures, the product catalog serves as the cornerstone of a company’s business model, processes, and operations. It is the "sacred book" that defines what the company offers to the market, how it delivers those offerings, how it supports its customers, and ultimately, how it generates revenue. There is nothing more critical than the product catalog. When properly designed and managed, the results can be extraordinary; when mismanaged, the consequences can be severe.

This context naturally leads every company to ask a crucial question: How do we design, implement, and operate our product catalog in a way that will make our business successful? What are the best practices for catalog management, and what should we avoid at all costs to prevent complications?

Every company, of course, wants to succeed without having to learn from costly mistakes. Unfortunately, the typical response to these questions is often the dreaded, "It depends." It depends on the company’s business model, the market segment, the IT architecture, the capabilities of the catalog management solution, and numerous other factors.

The problem with this answer is that it's not actionable. Yes, there are many variables that affect the outcome, and no, there isn’t a one-size-fits-all solution. But there are universal guidelines and guardrails that can be applied in virtually any situation. So let’s break down this “It depends” answer and uncover practical insights. After all, advice is only valuable if your customer can actually use it.

What Is a Product Model?

As usual, before tackling the original question, let’s reframe it a bit. When we talk about product catalogs, we’re essentially dealing with product models. I like to think of the product catalog as a container for these models. So, the question of how to design, implement, and operate a product catalog is really about how to design, implement, and operate the product models within it. Before we dive into best and worst practices for product modeling, it’s helpful to pause for a moment and clarify what a product model actually is.

A model, in a general sense, is a simplified representation of something that serves various purposes depending on the context. The bold part is crucial, as it’s at the heart of that familiar "it depends" answer. A model is only as good as its ability to serve a particular purpose. The exact same model can be perfect for one context and a complete disaster in another.

In the realm of product management, a product model represents a real-world product or service and enables key business processes such as product management, quotation, contracting, ordering, invoicing, and more. Again, the bold elements highlight the different contexts in which a product model is applied. Broadly speaking, we work across three primary macro-domains: Sales, Fulfillment and Operations, and Billing; plus sometimes we add the dimension of the interaction channel (mobile, web, assisted, partner, etc.).

To give you a couple of examples of different expectations from a product model coming from different contexts:

• Customers encounter product models “surfacing” in marketing materials, brochures, catalogs, self-service portals, mobile applications, and invoices. It’s essential that these product models are easy to understand, clearly highlight the value to the customer, and specify the costs associated with the offering
• Sales agents use catalog-enabled quotation and contracting tools, which should facilitate quick proposal creation. The product catalog must allow users to configure an offer with minimal clicks and be intuitive enough to understand without needing to refer to documentation or instructions
• For Fulfillment and operations, the model should capture sufficient information to complete order provisioning and initiate invoicing seamlessly
• Product managers oversee the portfolios and look for flexibility in product structure (e.g., the ability to add add-ons) and pricing configurations. A model that is too rigid makes it challenging to craft competitive market offers, while one that is overly flexible complicates the pricing structure and may negatively impact customer experience

I like to think of product modeling as a game of darts. The goal is always to hit the bullseye - getting the model as close as possible to perfectly fitting its purpose. However, the challenge here is that instead of aiming at just one dartboard, you're aiming at three, corresponding to the key architecture domains. And you only have one dart. If the idea of throwing three darts at once resonates better with you, that’s also a great analogy. The bottom line is that no single product model will ever be perfect for every context, but it can be “good enough” to support each individual purpose. This is where we, as architects and designers, need to balance the requirements provided by marketing, sales, operations and other teams and come up with a a comprehensive and cohesive product model. That’s where the optimization challenge begins!

Key take-aways at this moment:

• A particular product model may perform exceptionally well in one domain (e.g., Billing) but poorly in another (e.g., Sales). I've often seen product models designed for the Billing domain where each product configuration is treated as an independent product or offering. This approach simplifies billing but severely restricts the sales and ordering experience.
• Multiple product models can be created for the same product or service. While these models may share core characteristics, they can vary in specific aspects tailored to the needs of a particular domain. This is one way to achieve catalog-driven architectures while allowing flexibility to meet the unique requirements of different domains or applications.

Product Model Characteristics

Returning to the question of whether a particular product model is good or bad (for a given context), I frequently work with customers who ask for my opinion on their implemented product models, often within the context of Salesforce Communications Cloud. When evaluating a product model, I focus on several key characteristics. Based on this assessment, we typically develop an action plan to improve the model where necessary. Here are the characteristics I often use to support my assessment.

Common Characteristics

Reality Check

This is the kind of check that relies on common sense. Ideally, the moment you first open the product model, your initial reaction should be something along the lines of, "Okay, I can follow this, and it makes sense." However, if instead you're left thinking, "What am I even looking at?" or "I've never seen anything like this before," that’s a clear warning sign.

Of course, this assumes you're familiar with the product domain. If, despite having a basic understanding of the product being modeled, you struggle to navigate the model or can’t easily see how it relates to the real-world product or service, that’s a major red flag.

It’s perfectly normal not to grasp every acronym or specific part of the model on your first pass. But your initial impression—your gut feeling, if you will—should be one of general comprehension. If you're having trouble making sense of it, chances are others will too.

Completeness (or Comprehensiveness)

This is the time to address the "Where is X in this model?" type of questions. At this stage, we ensure the model accurately represents all components and configurations necessary to support key business processes and scenarios. A few examples include:

• Every chargeable component is represented in the model (typically as a product offering)
• If a product is configurable, the model should reflect relevant characteristics to support that customization
• If a product has a modular structure, the model should clearly capture this

Business teams are particularly skilled at identifying potential gaps, so collaborating with someone from the business side - such as a member of the sales team - can significantly enhance the assessment process and lead to more thorough results.

Modularity and Reusability

After assessing the completeness of the model and verifying that it supports all necessary business processes and scenarios, the next step is to evaluate its modularity. In product management, modularity refers to the design principle of breaking a product model into smaller, self-contained parts (or modules) that can be developed, modified, replaced, or reused independently.

Modularity is crucial because it promotes component reusability. This allows businesses to create new products and offerings by combining previously defined, reusable components. It also enables the sharing of components across product portfolios and business lines. This is a powerful way to drive consistency across the organization and gain greater control over time to market.

On the other hand, monolithic models - those with little to no reusable components - offer few opportunities to leverage pre-existing, defined product elements. The result? Delayed time to market and higher catalog management costs.

A word of caution: while monolithic models have their drawbacks, overly modular models aren’t always ideal either. For instance, product models that treat every tiny element as a separate reusable component can create an overly complex experience for both customers, sales agents and the operations team. For practical purposes, I have a little “should it be a component” litmus test that roughly helps me to not end up on any of the extremes of the spectrum (neither monolith, nor overly-modular)

Extensibility

Closely tied to model modularity is the concept of model extensibility. It’s important to remember that a product model is not a static, one-time creation - it's a tool designed to serve a specific purpose. As that purpose evolves, the product model may need to adapt as well. Therefore, the model should be built to allow extensions without causing significant disruption to business operations or incurring high implementation costs. In most cases, extensibility is made possible by modularity, as modular designs allow you to easily add, change, remove, or rearrange components.

When starting new projects, we often begin with a Minimum Viable Product (MVP) phase. In this phase, we establish the foundational product model, which will evolve as new customer requirements arise. These requirements could involve not just additional components (add-ons) but also new business processes to support, such as inventory lifecycle changes or MACD (Move, Add, Change, Delete) scenarios. This is where model extensibility becomes critical - it enables businesses to incrementally increase the value of their tools and solutions as they grow and adapt to new needs, without a major disruption to any business process enabled by that model

Alignment with industry frameworks (TM Forum SID)

In the telecommunications industry, standardization is key to ensuring smooth operations and interoperability between different service providers, operators, and vendors. To address this, TM Forum, a global industry association, developed a set of frameworks known as the TM Forum Frameworx. These frameworks aim to provide a standardized approach for managing business operations, processes, and systems within the telecommunications ecosystem.

One critical component of these frameworks is the TM Forum Information Framework (SID). The Shared Information/Data (SID) model defines a comprehensive information architecture that helps describe the key business entities and their relationships. These entities include customers, products, services, resources, and more, covering both technical and commercial aspects of telecommunications.

Here we ensure that the product model aligns with the Offering-Product-Service-Resource structure outlined in the TM Forum Shared Information/Data (SID) model. This process validates that the product model contains distinct, loosely-coupled layers, with each component logically fitting into its respective layer.

On one occasion, I reviewed a product model where the product and service layers were tightly coupled - a design choice made to accommodate the (somewhat limited) capabilities of the selected IT applications. This decision ultimately led to a significant expansion of the product model, causing the sales application to struggle with performance issues due to the sheer size of the model.

Short remark: the layer-based approach to product modeling is a topic on its own, and I plan to explore it in more detail in a future post - covering why it’s needed, how to approach it, and how to implement it. One important point to note now, however, is that each layer of the model (offerings, products, services, resources) can - and likely will - be managed by separate applications (catalogs). As a result, our single, multi-layered product model is usually split into 3 single-layered product models spread across separate - but interconnected - catalog management applications ??

Implementation-Related Characteristics

In addition to the common characteristics of the product model, there are also implementation-specific considerations. The product model will eventually be deployed within a catalog management system and used by various catalog-driven applications such as sales, contracting, fulfillment, and billing. These implementation-related factors help evaluate how well the product model aligns with the envisioned IT architecture and the vendor solutions selected to support it. Ultimately, if the product model cannot be effectively integrated or utilized by the software due to system limitations, it will fail to fulfill its intended purpose

Relevance (or Compactness)

Sometimes, product models contain components that, while potentially useful, are not essential - or may even hinder - business processes and scenarios. For instance, imagine a product model designed specifically to support only a catalog-driven sales process. In this case, the model must include relevant details about product offerings and specifications. However, information about service and resource specifications (the lower layers of the PSR model) is unnecessary, as it serves no purpose in the sales process. Even if accurate, these details are irrelevant in this context and should be removed, particularly if they add complexity or burden catalog-driven sales applications. The key is to keep the model simple and focused. If a component seems interesting but serves no practical purpose for any application, it’s best to eliminate it from the model.

Run-time aspects

The core promise of catalog-driven solutions is that you define a product model in a central, almost "magical" location known as the product catalog. From there, specialized catalog-driven applications interpret these product models to deliver the corresponding run-time experience - this includes factors like user interface, responsiveness, scalability, etc.

At this point, we assess how a particular business application would perform when given a specific product model:

• Will it provide an intuitive and functional user interface?
• Can it support various scenarios such as new provisions, modifications, or disconnections?
• Will it maintain reasonable performance across orders with varying volumes or complex configurations?
• Can it integrate with other business applications in a way that is both flexible and efficient?

These run-time aspects are heavily influenced by the capabilities of the specific vendor application, so having expertise in that area - or collaborating with someone who does - is essential. If the same model enables a number of applications from different vendors - the model has to be evaluated against each application individually. Remember the three “dartboards” from the very beginning?

Capabilities by Your IT applications

Finally, building on the previous points, it's important to consider the capabilities (and limitations) of your IT applications. As we've discussed, specialized catalog-driven applications (such as sales, fulfillment, billing, etc.) interpret product models to deliver the desired run-time experience. If the product model includes constructs, components, or structures that your catalog-driven application cannot interpret, the value of that model diminishes (or you may end up with a higher level of solution customization). It's akin to giving someone a product manual in Bulgarian when they don’t understand the language; the pictures might offer some guidance, but the overall outcome remains uncertain.

Given this, it's crucial to evaluate product models not just in light of your application's current capabilities, but also their future potential (i.e., the product roadmap). This forward-thinking approach ensures that the model remains relevant (or become even more relevant) as the application evolves

How to Action on This

At this point, I hope you have gained greater clarity on how to evaluate the quality of a product model. While the characteristics outlined above don't provide a definitive formula for creating a flawless model, they establish important boundaries and guardrails to guide the process. With these principles in place, your product modeling team can define its own "commandments" for creating robust models. By adhering to these guidelines, you significantly enhance the likelihood of success.

In addition to these guidelines, it is equally valuable to consider what not to do. Often, it's easier to define actions to avoid than those to embrace. This concept is especially relevant when dealing with complex problems that may have multiple viable solutions. By clearly defining the "no-go" zones, we help customers steer clear of common pitfalls - mistakes that, if left unaddressed, could severely hamper their business.

In the next post, I’ll share a list of top anti-guidelines and anti-patterns that I've encountered in past implementation projects. These examples will illustrate why some seemingly straightforward solutions can be deceptive - and why they often lead to failure.

One crucial observation is that all the characteristics we've discussed are somewhat qualitative. For instance, I can review a product model and evaluate its modularity, identifying potential issues and offering feedback ranging from "This won’t work" to "I love it!" However, this type of assessment is inherently subjective - there’s no quantifiable (numeric) score, like 74 out of 100, that you can assign. This is a bit of a setback, as quantifying something is often the first step in improving it. Without the ability to measure a product model’s quality, optimizing it becomes much more challenging.

Fortunately, there are emerging tools designed to address this very issue. Several companies are developing solutions to help consultants, businesses, and stakeholders measure key aspects of product models. In the upcoming post, I will write about some of these tools and show how they can assist in ensuring the success of your solution.

As usual, happy product modelling!