Tag: product choices
Connect With Us
Four Times the Sales Transactions With the Same Head Count!
Products have so many choices. Customers hate the experience of having to answer 50 questions to get to selection. Asking them 50 questions translates to poor customer experience and it is actually bad for you too. Here is why. Every sale begins with a customer calling out the top 3 or 4 items they want in a product. I wish there were big blinking lights that could now say “Big Opportunity!” This moment is the biggest opportunity for you to recommend a product choice that meets his needs, while being good for you as well.
In ‘days of yore’, that is what a good salesman would do. He would look over his shoulder and see what he had in stock, and gently guide the customer to one of those products. But those were the days when products were fewer, choices were fewer, and sales guys could look over their shoulder and see what they had in stock. Gone are those days! Today – sales is outsourced. It is one of the biggest and most critical functions’ that has been outsourced. Sales are done though dealerships, channels, etc. Even when a company has internal sales resources, the sales teams tend to be big or have heavy turn over. So – you have a newbie selling your product more often than not.
As product choices have continued to skyrocket, this poses a tremendous challenge on sales reps, sales channels and outside sales people. They lack the tools and automation to quickly hone in on customers’ needs and recommend product choices. The lack of these tools is causing tremendous challenges to sales people and customer. Here is a list of some of the outcomes:
- Poor customer experience due to inability to recommend good product choices at point of sale .
- Lost sale because customers do not like to answer endless questions to get to a product choice. More often than not – this is bad for the seller as well. Long list of questions result in random choice selections. This causes one-off products and poor product selection.
- Longer sales cycle – Every sales rep will tell you that he wants to recommend a good product choice and close the sale. The faster you can recommend a product, the higher the conversion rate.
Today’s sales tools and CRM include contact management and pipeline management. We do not expect the sales reps to remember the names and contact information of their customers. But why do we expect them to memorize the product features and choices? Why do we take them through endless product training sessions, even as the products are changing?
CRM needs product selection information to enable a sales rep to close the deal. Jane Barrett, Research Director at AMR presented some of the benefits, in her presentation to an SAP user group in October 2009.
Here is a short list of the benefits of empowering sales reps with guided selling at point of sale –
- Sales cycle time drops dramatically, from days to instantaneous.
- Increase in profit (2% in one case) by continuous up selling and offering alternatives at point of sale
- Four times as many sales transactions can be handled with the same headcount. (400% sales productivity improvement!)
If you do not use product recommendation tools, your sales staff is working at 25% sales productivity. In affect, you have 4x the staff you need to do the same job
Call To Action – Please talk to your sales reps and channels on how they are currently selling your product and their current challenges. If they do not have automation and tools to recommend product selection, you have a significant opportunity for improvement. A potential opportunity to improve sales productivity by 400% !
Comments Off
Do Customer Buying Patterns Exist?
Customers have to make choices in order to buy configurable products. Do they make these choices at random, or are there patterns? When we look at the sales history for a configurable product, like a car or a computer, can we tell if customers have just been flipping coins and rolling dice? Or do their choices hang together and make sense? To answer this question, we would have to look at how they buy combinations of options. In the previous post, I took a pizza as a simple configurable product, and looked at how customers ordered pairs of toppings. Just by looking at the sales numbers we could detect that the selection of pineapple and Canadian bacon are not independent. Even if we had never heard of a Hawaiian Pizza, we could discover it in the data.
Even more information is hidden in combinations of three toppings at a time, or four toppings at a time. Any combination of toppings will have appeared on some of the pizzas that have been sold (or maybe none). The relative popularities of all the different combinations has a clear message: customers are not flipping coins. Some toppings naturally go together, and others do not. Pepperoni, broccoli, and anchovies is just unlikely. If a particular pizza restaurant has a few “house specials”, like the Meat Lovers and the Veggie Delight, we can see them in the data, even if we don’t know their names.
What is true of the pizza is also true of other configurable products: computers, trucks, tractors, lighting fixtures, industrial fans, and so on. All products that have variety. Customers make choices, but not by rolling dice. There are combinations that go together and combinations that do not. A pizza maker can juggle the preferences of his customers in his head. But when a product has 30 or more features, intuition is overwhelmed. The number of combinations explodes so fast that the unaided human mind can’t see the patterns. At this point, mathematical models and intense number crunching can reveal the patterns and let the product manager for a line of trucks be as confident as a pizza maker.
Do Customer Buying Patterns Exist?
Buying patterns are real, and they manifest themselves in how customers buy combinations of options. With the computing power we have available today we can detect and capture them. These patterns can then be used to design “house specials”, forecast future sales, and guide customers to what we want to sell them.
So, who else is talking about customer buying patterns?
Intel Talks about Changing technology buying patterns
Customer Buying Patterns have Changed. What’s Your Plan?
An entire report that summarizes the results of a consumer usage and purchasing pattern survey conducted in March of 2007. The survey was conducted with In-Stat’s Technology Adoption Panel (TAP) — a dynamic, online panel of more than 19,000 technology users and decision makers. Over 1,400 technology users responded to this focused survey.
Findings in this report include consumers’ time spent on PCs, when they last purchased a personal-use PC, the PC’s features/form factor/usage, the desired features of future PC purchases, changes in usage patterns, and consumers’ thoughts about new technologies.
The changing patterns include -
- When consumers are likely to make their next PC purchase.
- The features consumers state they want
- The features consumers state they really want, based on changes in their usage/buying patterns.
- How consumers view new technologies
However – buying patterns are constantly changing. As social networking grows, we are watching new markets emerge every day. There is gold for companies who can continually detect these patterns and offer the right products and feature mix.
True Demand Intelligence – Knowing who is buying what, where and why
Demand Intelligence – Knowing Who is Buying What, Where and Why
SKU numbers are an easy way to keep track of items that are built, stocked and sold. The SKU number itself is arbitrary and contains no ‘intelligence’.
The SKU number was invented for a very good reason. When this practice started, the number of SKU’s was small, and people and systems needed a simple way to track what they had. So ASP-678 may be the SKU number for a toothpaste tube with spearmint flavor, whitening, and tartar control. However, customers do not look for SKUs. They look for toothpaste with whitening, tartar control, flavors, sizes, etc. Customers buy attributes, and combinations of attributes. Some companies code the attributes into the SKUs, by concatenating two or three character codes (like SPWHTC). But this is at best a clumsy way of handling a few attributes. Companies want to know what attributes customers are looking for, and SKU numbers hide the attributes.
As the number of attributes starts to grow, whether you have them coded into the SKU number or not, the problems start to mount! The most important one is that companies do not know what customers are buying, or trying to buy. As the number of choices grows, the number of combinations grows much faster and companies drown in their own SKUs.
SKU intelligence is going behind the SKU numbers and ‘detecting what attributes customers are buying’. Knowing who is buying what, where and why is “True Demand Intelligence”.
Products have attributes. For example, a computer has a processor, a memory, and a hard drive. For each attribute there may be several alternative choices. This means that there are many different product configurations. Some companies make only a fixed subset of all the possible configurations and give each one a SKU number. Other companies allow customers to order exactly what they want, and if this is something new, then they create a new SKU number for it. In either case, a SKU number is supposed to represent a unique product configuration.
If you are trying to figure out what your customers want, then SKU numbers are a form of encryption. You have to look at your sales history in terms of the underlying attributes, and the choices for those attributes. Instead of looking at one SKU number you need to look at perhaps 20 separate attributes. The SKU number is a way of collapsing those 20 dimensions into a single dimension, with tremendous information loss. One of the things that is lost is proximity to other SKU’s, based on attribution. A customer who bought SKU A-1234 might have been satisfied with (or really looking for) SKU B-3728. These two SKUs have the same choices for 18 of the 20 attributes, and differ on only two. This is obvious when the unique configurations are represented as a set of attribute choices, but hidden when they are represented as SKU numbers. The first step in analyzing a sales history has to be expressing it in terms of the underlying attributes. Each SKU number has to be expanded into a list of choices. Then we can begin to find patterns in how the choices are made. The leather seats and the DVD player are usually bought together. Engine block heaters are not ordered on convertibles. Buying patterns exist at the attribute level, not at the SKU level.
“Buying patterns” are popular combinations of attribute choices. These can be pairs of attributes, triples of attributes, or even more. Popularity is measured by the share of sales that have that combination. Buying patterns are helpful in selling, because they reveal how customers can be moved to configurations (SKUs) that we have in stock, or that we would prefer to build. Experienced sales people are skilled at moving customers, but If these patterns are represented in some kind of knowledge base, then a computer can make the recommendations.
Customers also have attributes. The simplest is perhaps geographical location. There are patterns that involve both product attributes and customer attributes. Customers in Florida are more likely to buy convertibles; customers in North Dakota are more likely to buy engine block heaters. Customers may have several attributes, for example demographic attributes for individuals or industry attributes for companies. (We don’t assign SKU numbers to customers!) If your sales history contains information about the customer as well as information about the product, then we can look for buying patterns that are associated with certain kinds of customers.
As an example, for a desktop computer the list of attributes might be: Processor, Memory, Hard Drive, Keyboard, Monitor, Mouse, CD/DVD, Application. A specific SKU number like A-1234 is a code for a specific configuration, say (2GHz, 2GB, 120GB, Ergonomic, 22” flat panel, Wireless, R/W Combo, Gaming). The Application attribute is really a customer attribute, with values like Home, Small Business, or Entertainment, as well as Gaming. This would make it possible to look for typical Gaming configurations and typical Entertainment configurations.
SKU numbers are a useful shorthand for record keeping. Each SKU number represents a unique product configuration. But analyzing SKU numbers is like analyzing telephone numbers. To see the buying patterns, you have to go to the attribute level. The patterns exist among the attributes, so you have to decode the SKU numbers to see them.
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
Part I: Reporting, Business Intelligence, Data Mining, Analytics: Actionable Tasks!
Software vendors use so many big words and confuse customers. Our customers have often asked us to clarify – so here I go. The definitions in this article are based on research of these terms, and the collective opinion of many of our customers and prospects. Over numerous conversations with our customers and the discussions of the terminology, the clarifications always go back to the origin of the terms and then move on to change in usage. Hence this article folows that flow. I would love your feedback as it is important to help buyers understand this.
Business Reporting
Business Reporting, as the term suggests presents the data from the database in an easy to read format. This originated when business users were frustrated that all the data was locked up in databases. There was a lot of data, but no one could get access to it without calling on IT folks. Hence Business Reporting was born.
Business Intelligence
This is a fancy name for business reporting. Business intelligence (BI) is a broad category of technologies that allows for gathering, storing, accessing and analyzing data to help business users make better decisions. In a 1958 article, IBM researcher Hans Peter Luhn used the term business intelligence. He defined intelligence as: “the ability to apprehend the interrelationships of presented facts in such a way as to guide action towards a desired goal.”
In 1989 Howard Dresner (later a Gartner Group analyst) proposed Business Intelligence as an umbrella term to describe “concepts and methods to improve business decision-making by using fact-based support systems.” Then in the late 1990s the usage became widespread (Remember the Bubble!). Then. everything with any data reporting was called Business Intelligence. So today, Business Intelligence is a glorified term for “Business Reporting”.
Data mining
Simply put, Data mining is hitting the data with all mathematical methods available to a mathematician! The data source can be almost anything – news papers articles, financial reports, sales data, medical data, … . This means that the data can have structure or can be un-structured. And the mathematical methods that can be applied can include neural networks, genetic algorithms, statistics on steroid and anything else they can think of.
One may ask – why are they doing this? What are they mining? Well, the simple answer is that they are mining the data looking for patterns; any patterns that can reveal relationships. So the methods used are varied and the kinds of data that are mined can come from a myriad of sources.
The results of data mining are lots of data! In fact – the result of Business Reporting and BI has been data overload. Now that’s the bad news. In a world of information overload, the last thing that we need is more data. We have less time today than we have ever had before. Business users do not need more data. They need quick conclusions on what the data is saying, converted into actionable tasks. Simply put – “Please tell me what to do”.
… More on the discussion of analytics to action in the next blog.
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
Recommendation Engine To Empower Sales Process
There exists a great opportunity for companies to streamline their front end and specifically the quote to cash processes which will deliver immediate relief from the current economic reality. Emcien provides a “Recommendation Engine” for configurable products, empowering the sales process. In spite of tremendous technology advances, we see a selling process within companies that is very archaic, people intensive and time consuming. It involves sales people, sales engineers, quotes managers, configuration specialist, ……..
My favorite quote, also a dismal statistic, is from a Sales VP – “4 out of 5 quotes are lost because we cannot serve up the right stuff immediately at the point of sale“.
My second favorite quote is from a customer who was trying to buy a drive from a very well known company. “I am still waiting for a quote, so they don’t have my cash”, he said.
Why? Because after he gave them his requirements, they left and caucused, came back and asked more questions, caucused more…. 2 weeks later, he still did not have a quote. “Why is so complex” he asked. ”Because we have only one process”, he was told.
A Director at a lighting fixtures company told me that “EVERY customer request had to be touched by his staff” before they could issue a quote. 80% of the stuff ordered was repeat stuff, or close to repeat. Wouldn’t it be a lot more efficient for him (and the customer) to treat it that way! “We have only one process”, he said.
With Frank Hecker’s permission, I am republishing his article – “What Sales Engineers do”. It explains roles in the quote-to-order process that date back to World War II. In today’s economic environment, we cannot afford the luxury of so many roles and so much complexity for every unit we sell. We need to manage the 80% repeat sales in an efficient way, and leave the complexity for one-offs and custom builds. Companies that offer technical products have a quote-to-cash process that is completely outdated, very expensive and is a big opportunity for financial gain. Here is Frank’s article -
What “Sales Engineers” Do
“Sales engineer” (sometimes known as “systems engineer”, or “SE” for short) is one of those unique professions made possible by specialization of labor in an advanced post-industrial economy. Simply put, SEs apply their technical expertise in support of the sale of complex technological products, typically computer hardware, software, and/or services.
Note that even though many companies use the term “systems engineer” to describe this function (and I myself used the term in earlier versions of this text), what I’m describing here has very little to do with the formal discipline of systems engineering that arose after World War II out of the Bell System and large Cold War military/industrial projects like SAGE and Atlas. (For more on this see the book Rescuing Prometheus by Thomas P. Hughes.)
I haven’t done any detailed research on this, but I suspect that the use of the term “systems engineer” to describe a sales support position originated with IBM, probably within the sales teams devoted to serving large military and aerospace customers. With the advent of computers to replace and supplement products like card sorters (the original “business machines” in IBM’s corporate name) the products being sold became so complex that the typical salesperson was unable to fully understand and explain them. (As the old joke goes, “What’s the difference between a computer salesman and a used-car salesman? Answer: The used-car salesman knows when he’s lying.”)
Hence the need arose for sales teams to include technically knowledgeable people who could assist the actual salespeople, particularly in complex tasks like creating proposed system configurations to meet particular customer requirements. I suspect that the term “systems engineer” was adopted for such individuals both because this work was done within the context of engineering the complete systems of which the computers formed a major part, and also because calling them “engineers” was seen as giving them greater prestige and credibility in the customers’ eyes.
If the use of “systems engineer” in a sales context did in fact originate at IBM, I’m guessing that it then spread from IBM to other computer hardware and software companies. (Many sales VPs at high-tech companies got their start as IBM sales reps.) At some companies the SE function was renamed to something else — “marketing support analyst”, “sales technical support consultant”, “sales support analyst”, “sales engineer”, and so on — but the nature of the position itself remained essentially the same.
SEs perform the following activities in support of the sales process:
- soliciting technical requirements from customers
- giving presentations on and demonstrations of products
- providing informal advice on what products might fufill the customer’s needs
- writing more formal documents such as proposals and targetted white papers
- serving as a point of contact for non-routine technical issues at major accounts
- assisting salespeople with the creation and execution of an overall sales strategy for an account
Some of the things that systems engineers do not typically do (except when there’s no one else to do them!) include
- selling products
- providing routine post-sales product support
- developing products
- providing consulting services for system design and integration
These functions are performed by other people and groups, namely sales representatives, technical support people, engineers/developers, and professional services consultants respectively.
The principal qualifications for being a systems engineer are technical knowledge in the appropriate domain(s), verbal and written communications skills, and the ability and desire to work closely with salespeople. Having these qualities combined in a balanced way in a single person is relatively rare; in particular, most people with technical knowledge prefer to be engineers and developers, and most people interested in sales prefer to be sales representatives. This leaves people like me to soldier on as best we can.
Frank Hecker
About the Author: Frank Hecker is Director of Grants and Programs with the Mozilla Foundation, a nonprofit organization promoting choice and innovation on the Internet through its support of the Mozilla project and related initiatives. Prior to joining the Mozilla Foundation full-time Frank was a sales engineer with Opsware Inc, supporting sales of Opsware IT automation software and services to the Federal government. He has also worked for CollabNet, supporting sales of CollabNet services relating to open-source and other collaborative software development, and for Netscape Communications Corporation and America Online, Inc., as Director of Systems Engineering for the Netscape government sales group in Bethesda, Maryland. At Netscape he was sales technical lead for the Netscape/DoD worldwide site license, the FORTEZZA, FIPS 140-1, and Netscape Security Services projects, and many other sales activities; he was also a key contributor to Netscape’s decision to release source code for the Netscape browser, and was appointed one of three Netscape Fellows. His professional interests include the technical, business, and public policy aspects of open-source software, information systems security, assistive technologies, and online education. He was the winner of the 2009 Catalyst Award for his work in promoting open source accessibility, and was named one of Washingtonian Magazine’s top 100 leaders of Washington’s tech world
. He blogs at <http://blog.hecker.org/>
Comments Off
The Entropy of a Coin Toss.
A product is a collection of features, and each feature has mutually exclusive options. If a feature has only two options, then the choice is like a coin toss. The information contained in that choice is measured by entropy.
Entropy is a concept from classical thermodynamics that deals with the amount of disorder in a physical system (see http://en.wikipedia.org/wiki/Entropy). It was extended to information theory by Claude Shannon (see http://en.wikipedia.org/wiki/Entropy_(information_theory)). Shannon used entropy as a measure of the amount of information in a message. The simplest example is a coin toss. If we toss a fair coin, there is a 50% chance of getting tails, and a 50% chance of getting heads. Shannon defined the outcome of this experiment as having an entropy, or information content, of one bit. If I send a message (say 0 or 1) to tell you the result (tail or head), that message contains one bit of information.
Things start to get interesting when the coin is not fair. Consider a two-headed coin. The tossing experiment always results in heads, and the message will always be 1. According to Shannon, the information content of this message is zero.
If the coin is weighted so that the probability of tails is 25% and the probability of heads is 75%, then Shannon assigns an entropy of 0.811278. There is some information in knowing the outcome of the coin toss, but not as much as for a fair coin, because we already know that it will probably be heads. The graph below shows the entropy as a function of the probability of getting heads. When this probability is zero or one, the entropy is zero. The entropy reaches its maximum of one when the coin is fair (50%).
Where did the 0.811278 come from? How is the entropy actually computed?
We can’t answer this without introducing logarithms to the base two. In English, two to the third power is eight, so three is the logarithm of eight to the base two. We can write “blog” to mean log to the base 2, or binary log. If p denotes the probability of heads, then entropy is computed by the formula:
Entropy = -p*blog(p) – (1-p)*blog(1-p).
Logarithms to the base 2 arise naturally because one coin toss (2 outcomes) has entropy one, two coin tosses (4 outcomes) has entropy two, three coin tosses (8 outcomes) has entropy three, and so forth.
Comments Off
Q&A with John Sloan, former director, Jeep Brand Global Product Marketing
In today’s post, John Sloan talks about challenges dealers face in ordering inventory that best matches customer demand.
Emcien: Describe the Chrysler-Emcien initiative that examined dealers’ struggles with complexity in the ordering process.
JS: In a soft “push” market where volume is driven by heavy incentives versus the merits of the brand / model, managing cost is paramount. A key piece to focus on is product inventory. Dealers get roughly 60 days of no-interest floor plan. In a soft market, vehicles can easily sit for longer than two months before being sold, so it’s critical that vehicles be easy to order, stock and sell. Simple is better.
Emcien worked on a model to simplify the Chrysler PT Cruiser product mix. There were thousands of possible build configurations for the PT Cruiser, creating significant complexity for engineering and the assembly plant, as well as the supplier extended enterprise. Emcien’s ability to accurately forecast demand is invaluable for a complicated product line because it can assist with reducing the build configurations to those that best match demand. The PT Cruiser initiative validated the power of the Emcien inventory model.