When working with clients on parameters for a conjoint design, there is often an assumption that the design includes a current product configuration, or base case. This base case provides a benchmark against which new configurations can be compared.
Having a benchmark can be both useful and comforting when analyzing the conjoint results. Replicating a base case allows us to reference important metrics that are known for that product (for example, market share, CPU, revenue, etc.). As we configure new products and compare their appeal to our base case, we can gain insight into how these key metrics might be impacted.
Aside from establishing a benchmark, having a base case is also critical if there is concern about cannibalization. If the expectation for the new product is that it will compete in the market with a current configuration it is critical to understand what impact the new product will have on the current landscape.
However, allowing for a base case in the conjoint design is not always warranted. As products become more dissimilar from current offerings it can become difficult to include a base case. Trying to integrate the components of a current and new product that don’t share many characteristics can lead to conjoint parameters that are too complex to administer, or create apples to oranges comparisons. It is not wrong to leave out a base case as long as it is understood there will be no benchmark comparison.
One hybrid solution to consider is to allow for a set choice that reads something like “None of these, prefer the PRODUCTS currently available”. This is similar to a typical “none” option in the conjoint but provides a bit more information; specifically, that they would not leave the category but are not interested in the new, very different product configuration. Of course this solution would not be appropriate in all instances but does provide a good compromise.
Ultimately, the extent to which “real products” are modeled with a conjoint study’s parameters is a function of the specific information needs and the complexity of the design. Most of the time we want to include that dose of “reality” in our design but don’t be afraid to leave it behind if warranted.