Master Products in Prophet Workspace - Many or Few?

When I worked on Prophet projects that involved setting up Prophet model from scratch or streamlining existing Prophet models, one of the common requests I came across was relating to no. of master products. Many Prophet users have such a perception, i.e. the lesser no. of master products in a Prophet workspace, the better it is.

Let's think about it, is this perception correct? When we are talking about of having a better Prophet model, what does the word "better" mean?

Define a BETTER Prophet Model

It is important for us to define what we expect from a "better" Prophet model, instead of focusing on the no. of master products in the model. Let me share some views if I am a Prophet user:

• It is easier for me to setup a new product in my Prophet model. I don't want to define 50 - 100 input variables when I setup a new product, especially those input variables that I could not really understand what they are for.
   
•  When I need to amend coding of an input variable or a core product in the library, the coding is not lengthy and it is easier for me to go through, especially in the diagram view.
   
• It is always a good thing if I can use a Same As product for my new product. But... I don't want to such convenience comes with updating 20 - 30 tables. I may need to study the coding again in order to update those tables.

It goes back to the efforts required in the model maintenance. One of the rules I have learnt from my actuarial models and solutions development projects, flexibility always comes with complexity - i.e. when we want to introduce more flexibility in a model or solution, we need to always take note that we may be going to introduce more complexity at the same time. Furthermore, it will also invite a lot of redundancy if we want to have a generic model / solution.

Let me give some examples for better clarifications. Try to imagine if we need to setup only ONE master product for all investment-linked products. To do so, we need to include all unit deducting riders with various product features in the master products, so that it be used for all investment-linked policies, either with and without riders.

If you are familiar with Prophet models, every rider needs to have a set of designated variables in defining the product features, including cost of insurance ("COI"), benefit amount, incidence rates, reinsurance premiums etc. - it may require a few hundreds of variables for (say) 5 riders. Yes, the master product is now flexible, but do you think it is a suitable master product for a single premium investment-linked product that is without rider (which is mainly for investment purpose)?

Maintenance in Master Products?

I think it is clear enough that the above-mentioned master product is not suitable for single premium product without riders. A better approach that I would recommend is to create a separate master product for this single premium product - so that we can reduce redundancy in the product and shorten the run time.

Some users may object this idea: "This will increase our maintenance work!" Well, it may sound correct when you first hear such comment. However, the truth is most of the time the master products are not even opened by the users after they are setup and tested. In other words, most master products normally do not require maintenance after they are finalized and promoted to production.

In conclusion, we should not be over concerns on the no. of master products - instead, we should create a separate master product if there are significant different product features (I should discuss the concept of input variables in a separate post). 

If you have two master products which you have only minor differences in one or two input variables (such as different ways of calculating current sum assured), it is correct that you should have only one master product for these two variables.