Tag: product complexity
Connect With Us
Customer Buying Patterns – What you can learn From Pizza Sales
There are 1,140 ways of ordering a pizza with 3-toppings, if the pizza offers 20 choices
First order take rates tell us about the relative popularity of different options. For example, consider a small set of possible pizza toppings.
|
Topping |
Take Rate |
|
Pepperoni |
40% |
|
Mushrooms |
20% |
|
Pineapple |
3% |
|
Canadian Bacon |
3% |
|
Green Peppers |
10% |
Customer buying patterns really start with second order take rates, which tell us about pairs of options, or toppings. Second order take rates tell us about relative popularity, but they also reveal something deeper: dependence. If you know that a pizza has pineapple on it, there is a very good chance that it also has Canadian bacon. This is dependence. In this case the reason is that there is a widely known “Hawaiian Pizza” that has both of these toppings. In general, customers don’t flip coins or roll dice. They select options that “hang together” in some way. The patterns can be seen in the combined take rates. Let me illustrate with three examples that are contrived to illustrate some important points. First consider pepperoni and mushrooms together.
|
|
|
Mushrooms |
|
|
|
|
No |
Yes |
|
Pepperoni |
No |
18% |
12% |
|
Yes |
32% |
8% |
|
In this table you can see that pepperoni has a 40% take rate, since 32% of pizzas have pepperoni without mushrooms, and 8% have pepperoni with mushrooms. In the same way, 20% have mushrooms, because 12% have mushrooms without pepperoni and 8% have mushrooms with pepperoni. This illustrates the first law of second order take rates: the first order take rates must be preserved. But this table contains no new information. Customers are apparently ordering pepperoni and mushrooms independently. This is revealed by the fact that 8% is exactly 20% of 40%. Knowing that a pizza has pepperoni does not give us any clue about whether or not it has mushrooms. Similarly, knowing that it has mushrooms is useless in guessing if it has pepperoni.
As a second example, consider the two toppings that are on every Hawaiian pizza: pineapple and Canadian bacon.
|
|
|
Canadian Bacon |
|
|
|
|
No |
Yes |
|
Pineapple |
No |
97% |
0% |
|
|
Yes |
0% |
3% |
For simplicity, I have made this an example of complete dependence: a pizza has pineapple if and only if it has Canadian bacon. Notice that the first order take rates (3% for each) are preserved.
The third example is the really important one: partial dependence. This is illustrated here by pineapple and green peppers.
|
|
|
Green Peppers |
|
|
|
|
No |
Yes |
|
Pineapple |
No |
89% |
8% |
|
Yes |
1% |
2% |
|
In this case, the first order take rates are also preserved: 3% for pineapple and 10% for green peppers. But these two choices are not independent. The take rate for pineapple and green peppers together is 2%, which is much greater than 10% of 3%, which would be only 0.3%.
Exercise for the reader: show that if we know that the pizza has green peppers, then there is a 20% chance that it has pineapple. (Much greater than its 3% first order take rate.) And if we know that it has pineapple, then there is a whopping 67% chance that it has green peppers!
So second order take rates capture information about how customers are combining toppings, and we can use that information to make predictions.
Comments Off
Is your sales history self-encrypting?
Emcien’s mission is to find the actionable intelligence that is hidden in the sales history of configurable products. We call this SKU intelligence. Many companies, however, save their sales history in a way that keeps any patterns hidden forever. I call this self-encryption. Many of these worst practices began as a way of saving space at a time when storage space was expensive.
A configurable product is one where the customer has to make choices to customize the product to his own particular needs or preferences. The valuable patterns are in the way these choices are made. The sales history should be at the right level of abstraction: in terms of the choices that the customer made. Here are four ways you may be encrypting your data.
- SKU Numbers. SKU numbers identify unique product configurations. They are a great shorthand for keeping track of what has been built and what is sitting in inventory. But if the sales history is kept in terms of SKU numbers, and the definitions of those SKU numbers are stored in a different place, then you may not be able to decipher your own history. By “different place” I mean a different database, different computer system, or anywhere that is not part of the history itself.
- Part Numbers. Customer orders get translated into Bills-of-Material (BOM) so that the requested item can be built and delivered. But what happens to the order afterwards? Often it is saved in terms of the part numbers. The customer ordered “2GB of RAM”, which became part 123-XYZ-645A. This was the right part number for 2GB of RAM from a certain supplier during a certain period of time. Remembering 123-XYZ-645A may be important for some warranty issues, but it is the wrong level of abstraction for understanding the customer. Many customers ordered “2GB of RAM”, but they got many different part numbers (different suppliers at different times). Part numbers change constantly, and unless a complete trail of part number changes and equivalences is maintained, a history in terms of part numbers is irretrievably fragmented.
- Standard Options. Most manufacturers make different models of their products, and the different models come with different “standard options”. The sales history doesn’t mention these options because there would be so much repetition (let’s save space!). The problem is that the set of standard options changes over time, even though the model names stay the same. Which options were standard on Model ABC in September 2007? Who remembers?
- Product Packages and Option Bundles. This is similar to the standard option problem. Some set of options is bundled together and sold as the “Sports Package” for some period of time. So the sales history says “Sports Package”. What was in the Sports Package in September 2007? Who remembers?
The sales history should be self-contained, with a record of each unit sold, expressed in terms of the options bought by the customer. If some options were implied by others, but could have been different, then they should be spelled out. If the data is saved in the right way, then the patterns in how customers buy the product can be revealed.
The difference can be dramatic. The message below appears to be gibberish.
|
S |
C |
O |
|
|
T |
D |
F |
|
S |
T |
I |
A |
I |
I |
R |
N |
|
|
N |
I |
L |
|
A |
|
D |
|
A |
S |
E |
E |
N |
H |
E |
I |
|
E |
H |
|
N |
|
E |
S |
E |
|
A |
C |
|
S |
R |
U |
H |
T |
|
R |
R |
M |
I |
|
D |
|
Y |
|
L |
E |
Y |
U |
O |
N |
E |
Y |
But suppose we use the key that Dan Brown uses in “The Lost Symbol”: the magic square discovered by Benjamin Franklin.
|
14 |
3 |
62 |
51 |
46 |
35 |
30 |
19 |
|
52 |
61 |
4 |
13 |
20 |
29 |
36 |
45 |
|
11 |
6 |
59 |
54 |
43 |
38 |
27 |
22 |
|
53 |
60 |
5 |
12 |
21 |
28 |
37 |
44 |
|
55 |
58 |
7 |
10 |
23 |
26 |
39 |
42 |
|
9 |
8 |
57 |
56 |
41 |
40 |
25 |
24 |
|
50 |
63 |
2 |
15 |
18 |
31 |
34 |
47 |
|
16 |
1 |
64 |
49 |
48 |
33 |
32 |
17 |
Then we see the hidden message: “Emcien can easily find the hidden treasure in your sales history”.
The value is that customers are speaking to you when they buy your products. This is the true Voice of the Customer (VOC). But due to the data encryption issue, companies are blind to this intelligence. Unleash this intelligence, and you can drive higher sales and margin by serving the customer with the right choices.
Comments Off
Recommendation engine for configurable products
The Amazon recommendation engine has received a lot of attention and imitation. It has been successful at increasing sales by pointing out that people who bought book x also bought book y. This simulates a helpful book store employee who has an extensive mental map of how books relate to each other. Recommendations have been most successful for books, movies, and music. Companies that sell complex configurable products could also benefit from a system of automated recommendations. Products like trucks, tractors, computers, lighting fixtures, valves, and industrial fans. These are products that the buyer can customize to his own preferences or needs. The buying process is complex, and sales agents make recommendations, just like the book store expert. But many of these products are far more complex than books.
How is a book different from a truck? Could a recommendation engine for books be used to recommend trucks? The purpose of this note is to consider the ways in which the two cases are similar and different, and to explore what a recommendation engine for configurable products might look like.
Books and trucks can both be described in terms of attributes (also called features or characteristics). Books can be described by their genre, author, language, and publication date for instance. Trucks can be described by their engine, transmission, wheelbase, gross vehicle weight, and many other attributes. Books, movies, and music can be classified in sufficient detail with ten or fewer attributes, while configurable products usually have a lot more. Heavy-duty trucks can have anywhere from 30 to 300 attributes. For books, the attributes are used to classify existing books. For configurable products, each attribute represents a choice for a customer who is ordering the product. Each attribute has several alternative options, so an order is really a list of option choices.
Amazon uses attributes to let customers search for a book, but the recommendation engine does not use them. The recommendation engine remembers each customer’s purchase history. For example, Joe has already bought “War and Peace” and “Crime and Punishment”. When he buys “The Sound and the Fury”, a connection is made between “The Sound and the Fury” and “War and Peace”, and another connection is made between “The Sound and the Fury” and “Crime and Punishment”. More accurately, the weights of these connections are increased. The connection between “The Sound and the Fury” and “War and Peace” depends on the number of customers that have bought both books. Commonality depends on common purchase by individual customers.
One big difference between books and trucks is that an individual will buy many books, but is unlikely to buy many trucks. So the basis for the connections between trucks can’t be the common purchases of individual buyers.
Another difference is that only books that have already been written are of interest. No customer is looking for a book that hasn’t been written yet, and you certainly can’t recommend one. But because of the very large number of choices, a buyer who is customizing a truck may arrive at a configuration that has never been built before. So our recommendation system must be able to accommodate trucks that don’t exist yet.
The helpful book store employee will jump from one book to another book that his customer might like. When we look at the helpful sales agent, he is doing something quite different. Based on the first, and usually most important, choices that the buyer makes, he will suggest ways of completing the order. The buyer may really only care about 10 of the 30 choices, and want guidance on what else to choose. The book store employee jumps from one complete item to another complete item. The sales agent is finding a path from a partial order to a complete order.
So we have an initial set of requirements for a recommendation engine for configurable products. It must help a buyer who has made some choices to make additional choices, so as to arrive at a complete order. From the seller’s point of view, we would want these recommendations to guide the buyer toward items that are advantageous. This might mean popular, in stock, and/or profitable. Its concept of the product (e.g. truck) must be broad enough to encompass configurations that have never been built before, and its concept of commonality must be based on something other than common purchases.
To show one way this might be done, consider a different way of making connections. When a customer buys a red truck with a V-8 engine, he is making a connection between red, a value of the Color attribute, and V-8, a value of the Engine attribute. So the customer’s vote is not recorded as a connection between two complete trucks, but as a connection between two attributes. More precisely, it is recorded as a connection between two values, or options, of the two attributes.
When a customer buys a truck with n attributes, we will record his “vote” n times, once for each of the options he has chosen. Then we will also record it nC2 more times for each pair of options. The symbol nC2 stands for the number of different pairs of attributes there are, and can be computed as n*(n-1)/2. For example 10C2=45. The relative popularity of the different pairs of options (like red and V-8) tells us something about how customers are buying the product, and gives us a different basis for making recommendations. (If you want pineapple on your pizza, you probably want Canadian bacon.)
If pairs of options are interesting, then so are triples of options. The same customer vote can be recorded for nC3 different sets of three options (10C3=120). Every option of every attribute has its own popularity (i.e. number of votes). Expressed as a fraction of total units sold it is known as a first-order take rate. Every pair of options also has a popularity, and as a fraction is defined as a second-order take rate. Similarly, each triple has a third-order take rate. Of course we can also define fourth, fifth, and higher-order take rates.
If customer purchases (votes) are recorded in this way, then we will have captured the buying patterns in the form of first, second, third, and higher-order take rates. A new customer who begins to select the options that are important to him will trigger these patterns, which will then serve as the basis for recommending a complete truck. So we see that two complete trucks may be related because they both contain instances of the same fifth-order take rate. This can be true even if neither truck has ever been built before.
We conclude that a recommendation engine for configurable products could be built by mapping customer purchases into a structure of take rates that record the relative popularity of options, pairs of options, triples of options, and so forth.
Comments Off
What does the stairway to complexity tell us?
If a product is too complex, where is the complexity coming from? Which features are causing the explosion in the number of build combinations? The stairway to complexity tells us where to look.
The stairway to complexity shows how the number of unique configurations drops as features are removed. Here is another stairway for a backhoe with 30 features.
The number of build combinations drops from 934 down to 1 as we remove the features. Behind the graph is the actual list of features in the order they were removed. In the table below, the features are ranked from 1 to 30, corresponding to the steps in the graph.
If we want to simplify our product, this ranking of the features tells us where to start. The greatest contributor to complexity is the Buckets, of which there are 34 different kinds. The number of build combinations would drop from 934 to 838 if we didn’t have to worry about Buckets.
Is the ordering of the features in the stairway the same as the ordering by number of options? The first feature in the stairway is certainly the one with the most options (34). But Tran_Control has the second largest number of options (9), and doesn’t appear in the stairway until step 15. So there is more going on than just the number of options.
The amount of complexity introduced by a feature depends not just on the number of options, but on the relative popularity of the different options. Having two options that are split 50% to 50% is much worse than if they are split 90% to 10%. (See earlier post: Entropy of a coin toss.)
Introducing a new feature only increases product complexity if it splits existing configurations that would otherwise be the same. One manufacturer insisted that his product was so complex because it was produced for many different countries. But the number of unique build combinations was exactly the same whether the Country feature was included or not.
Comments Off
Stairway to (Product) Complexity (a.k.a. Why Do I have SO Much Stuff!!!)
In the last post I introduced two ideas about the sales history of any product. First, the number of unique configurations, or build combinations, depends on which features are included in its description. Second, the number of unique combinations drops whenever a feature is removed. A natural question to ask at this point is: Which feature, if it were removed, would lead to the greatest decrease in the number of unique configurations?
This is an easy question to answer, if we have a way of counting the number of unique configurations in any input set of configurations. This is really just a matter of sorting, so suppose we have such a counting algorithm. We try removing the features, one at a time. In each case we apply our counting algorithm to get a score. The score is the number of surviving unique configurations. The feature with the lowest score is the winner (like golf).
Now suppose that we permanently remove the winner, and repeat the contest again. This will determine a second winner, which can also be removed. We keep repeating until there are no features left. Now imagine a graph with the number of features removed on the x-axis and the number of surviving unique configurations on the y-axis. This is the stairway to complexity.
The stairway shown above is for a product (commercial stoves) with 23 features. The number of unique configurations starts at 1223 and drops to just 1 as the features are removed. The features are removed by looking for the biggest drop at each step.
Abstract:
Product complexity is driven by large number of options. Companies struggle to determine which feature choices are driving complexity. They typically “randomly cut choices” to streamline and rationalize SKUs. The cost of product complexity is tremendous on engineering. The current PLM systems do not have a method to measure this and provide intelligent feedback to engineers on how to standardize platforms to reduce engineering and maintenance costs. This article clearly details the metrics around product complexity and how to solve this issue.
Comments Off
The Number of Choice Combinations Depend…
The number of choice combinations depend on which product features are included. The build combinations is the product mix or the marketing mix.
Let’s consider the sales history of our product. There are two very important numbers: the number of units sold and the number of unique configurations. The number of units is well defined, but the number of unique configurations is ambiguous. The ambiguity comes from the fact that there will be more unique configurations if we use more features, especially soft features, to describe our product.
One very special soft feature is a Serial Number, or VIN (Vehicle Identification Number). The whole purpose of the Serial Number is to make each instance of the product unique. So if we look at our sales history and include Serial Number, we will see that the number of unique configurations is exactly the same as the number of units of the product (instances).
If we want to begin to understand the demand for our product we have to see which instances are actually the same. That means we have to get rid of the Serial Numbers. When we do, the instances collapse into groups of now unique configurations; that is, unique without Serial Number.
If we are interested in the tangible features of the product, then we may want to take out other soft features as well. Geographic region is important for some purposes, but may be a distraction when we are interested in the physical product. Taking out the geographic region feature will cause another reduction in the number of unique configurations. The red, V8, convertible in Florida will get combined with the red, V8, convertible in New York.
Sometimes we are interested in the variants of our product ignoring color. We know that every real variant is going to come in several colors, but we want to look at the product without the distraction of color. This is sometimes called the “body in white”. So the red, V8, convertible and the green, V8, convertible collapse into the V8, convertible.
The point I am making is that the number of unique configurations depends on which features are included, and this number drops whenever a feature is taken away. Mathematically, this is called “projecting out the feature”.
The number of unique configurations is at most the number of units sold, and at a minimum it is just one. If we take away all of the features, then every unit looks the same, which means just one configuration. There is a path from one extreme to the other that we will introduce next time.
By the way – understanding this is important as product complexity is a key driver of process complexity.
Comments Off
Why product complexity matters
I was telling some friends at a brunch about what I do, and how variety drives cost in manufacturing. “But all the manufacturing has moved to China,” commented one person. I’ve heard this comment over and over.
A picture is worth a thousand words — and here’s one that fits the bill.
- Commoditization of labor in manufacturing
- Higher output per worker
- The percentage of cost in goods is much higher
