Discover Product Modeling
Learning Objectives
After completing this unit, you’ll be able to:
- Explain the importance of a product model.
- List Shared Catalog components and capabilities.
- Discuss considerations that influence product-modeling decisions.
- Define commercial and technical products.
- Summarize the steps in the product-modeling workflow.
Before You Start
Before you start this module, be sure to complete the other badges in the trail Get Started with Product Designer. The work you do here builds on the concepts in those badges.
Also, consider completing the following recommended content.
- The Communications Industry
- The Energy and Utilities Industry
- The Media Industry
- Industries Shared Catalog
- Industries CPQ Foundations
- Industries EPC Foundations
A Solid Plan
Remember Devi Jacob, product designer at Infiwave? He’s responsible for maintaining the company’s catalog of commercial products and services.
Having developed good working knowledge of Shared Catalog and Product Designer, he rolls up his sleeves, ready to start building products. But first, Devi must formulate a solid strategy for how to set up the Infiwave product catalog and get the most from the new system. Foremost, he must ensure that the data model aligns with his company’s overarching business goals. And he can’t wait to streamline his own product-management work.
Importance of a Product Model
A product model is a specific version or configuration of a product, for example, a smartphone and smartwatch bundle offered for sale. Hierarchical product models represent the products that an organization offers to its customers, defining the relationships between those models. Simple product models help ensure that customers understand the offers presented to them.
Planning a product model involves creating a visual representation of it, such as a diagram. Here's an example product model for a single bundle with various layers of Shared Catalog components and, importantly, their relationships.
One approach is to sketch this diagram by hand and then refine it using the product-modeling tool of your choice. Most product models include a legend, like this one, to define the diagram elements and symbols.
Most of the product models and examples in this module are based on the communications industry. The good news is that the modeling patterns and guidelines are applicable to other industries, including media, energy, and utilities. You touch on those industries later in the module.
Product-Modeling Considerations
What’s the best way for Devi to model products for Infiwave? Several factors should influence his approach, including the industry and business context, customer locations, provisioning needs, and user interface. He also needs to understand how products relate to one another, for example, if they’re sold separately or together.
Some product aspects change often over time, like pricing and customer eligibility. So Devi must consider the effort required to maintain product configurations before building out the catalog architecture.
Product modeling decisions affect downstream systems that reference those products, such as order-management and provisioning systems. So it’s important to consider how to display and sell products in the Cart and what underlying information to store for downstream systems.
In light of all these factors, it can be challenging to create product models that support every context. Fortunately, that’s where Shared Catalog provides a solution: It gives you the flexibility to build product models that work best for your company.
Commercial and Technical Catalogs
With Industries Shared Catalog, Devi can keep track of both commercial and technical products, so that the right hand always knows what the left hand is doing. What’s the difference between commercial and technical products, you ask? Let’s use a restaurant as an example.
Commercial products are what customers see when they shop, like the food and beverage choices on a menu and their prices. Technical products, on the other hand, are hidden from customers. Recipes, food-handling procedures, service guidelines, and the restaurant inventory database are examples of technical entities. They’re required for the product, but customers can’t see them.
Commercial products form the commercial layer of the catalog, while technical entities make up the technical layer.
With Shared Catalog, commercial product details are displayed to customers in the Cart and include things like quotes, contracts, and bills—all entities that customers can view. The catalog contains product offers, product specifications, and product bundles, each with its own specific characteristics and relationships.
Technical products consist of underlying products, services, and resources to drive order fulfillment. Examples include shipping, activation, and billing requirements, or the hardware or software that make a commercial item usable. As mentioned, customers can’t see or buy these items on their own.
In a product model, you map technical products to the commercial products they support. This mapping ensures that product orders decompose into the various solutions that make the product attainable for the customer.
The separation of commercial and technical products has a number of benefits.
- Simplification: The product information shown to customers hides irrelevant technical information from the Cart view.
- Reusability and extensibility: For example, map one common technical service to several commercial products.
- Flexibility: Change the technical components of a product, without impacting its commercial structure.
- Enhanced system performance: Remove the need for duplicate product and offer entities.
Product-Modeling Workflow
Now that Devi has dipped his toes in the basics of product modeling with Shared Catalog, he’s ready to start building the product catalog for Infiwave. He takes a three-stage approach.
The first stage is requirement collection, which is essentially discovery. Next, comes the application of modeling patterns to build out the product catalog structures. Lastly, stakeholders review and approve his product models.
Let’s take a closer look at each stage.
| Stage | Description |
|---|---|
|
Requirement Collection |
In this discovery stage, the solution architect collects all the business, functional, and technical requirements from stakeholders. The main objective is to gain a full understanding of what’s needed in the product catalog and avoid errors or oversights that impact the process later on. |
|
Application |
This stage is all about defining modeling patterns. The product designer or architect uses the information collected in the previous stage and creates a diagram of modeling patterns that represent all necessary data and processes. The main goal of this stage is to reflect the company’s structure, products, and associated workflows. |
|
Review and Approval |
This is the final stage where the stakeholders evaluate and approve the overall model design against the primary functional and performance requirements. It’s difficult to please everyone with a single architecture solution. At the end of the day, the best approach isn’t always what every contributor had in mind. Compromise is key. |
In addition to following this process, Devi must collaborate with product teams to understand the many use cases that Infiwave customers face. This way, he can model products that match what customers want. He may not get the product model perfect the first time around, but that’s OK! He can always go back and fine-tune it based on new circumstances or best practices that come to light.
Looking Ahead
In this unit, you learned what a product model is and some important considerations for modeling products. You also discovered commercial and technical products and how to approach building a product model in the Shared Catalog.
In the next unit, you learn about requirement collection and the basic principles to follow when product modeling.