Democratizing Innovation

3 Why Many Users Want Custom Products

The high rates of user innovation documented in chapter 2 suggest that many users may want custom products. Why should this be so? I will argue that it is because many users have needs that differ in detail, and many also have both sufficient willingness to pay and sufficient resources to obtain a custom product that is just right for their individual needs. In this chapter, I first present the case for heterogeneity of user needs. I then review a study that explores users' heterogeneity of need and willingness to pay for product customization.

Heterogeneity of User Needs

If many individual users or user firms want something different in a product type, it is said that heterogeneity of user need for that product type is high. If users' needs are highly heterogeneous, only small numbers of users will tend to want exactly the same thing. In such a case it is unlikely that mass-produced products will precisely suit the needs of many users. Mass manufacturers tend to want to build products that will appeal to more users rather than fewer, so as to spread their fixed costs of development and production. If many users want something different, and if they have adequate interest and resources to get exactly the product they need, they will be driven either to develop it for themselves or to pay a custom manufacturer to develop it for them.

Are users' needs for new products (and services) often highly heterogeneous? A test of reason suggests that they are. An individual's or a firm's need for a many products depends on detailed considerations regarding the user's initial state and resources, on the pathway the user must traverse to get from the initial state to the preferred state, and on detailed considerations regarding their preferred end state as well. These are likely to be different for each individual user and for each user firm at some level of detail. This, in turn, suggests that needs for many new products and services that are precisely right for each user will differ: that needs for those products will be highly heterogeneous.

Suppose, for example, that you decide you need a new item of household furnishing. Your house is already furnished with hundreds of items, big and small, and the new item must “fit in” properly. In addition, your precise needs for the new item are likely to be affected by your living situation, your resources, and your preferences. For example: “We need a new couch that Uncle Bill will like, that the kids can jump on, that matches the wallpaper I adore, that reflects my love of coral reefs and overall good taste, and that we can afford.” Many of these specific constraints are not results of current whim and are not easy to change. Perhaps you can change the wallpaper, but you are less likely to change Uncle Bill, your kids, your established tastes with respect to a living environment, or your resource constraints.

The net result is that the most desired product characteristics might be specific to each individual or firm. Of course, many will be willing to satisfice---make compromises---on many items because of limits on the money or time they have available to get exactly what they want. Thus, a serious mountain biker may be willing to simply buy almost any couch on sale even if he or she is not fully happy with it. On the other hand, that same biker may be totally unwilling to compromise about getting mountain biking equipment that is precisely right for his or her specific needs. In terms of industrial products, NASA may insist on getting precisely right components for the Space Shuttle if they affect mission safety, but may be willing to satisfice on other items.

Evidence from Studies of User Innovation

Two studies of innovation by users provide indirect information on the heterogeneity of user need. They provide descriptions of the functions of the innovations developed by users in their samples. Inspection of these descriptions shows a great deal of variation and few near-duplicates. Different functionality, of course, implies that the developers of the products had different needs. In the 2000 study of user modifications of library IT systems by Morrison, Roberts, and von Hippel, discussed earlier, only 14 of 39 innovations are functionally similar to any other innovations in the sample. If one type of functionality that was repeatedly developed (“web interface”) is excluded, the overlap is even lower (see table 2.2). Other responses by study participants add to this impression of high heterogeneity of need among users. Thirty percent of the respondents reported that their library IT system had been highly customized by the manufacturer during installation to meet their specific needs. In addition, 54 percent of study respondents agreed with the statement “We would like to make additional improvements to our IT system functionality that can't be made by simply adjusting the standard, customer-accessible parameters provided by the supplier.”

Similar moderate overlap in the characteristics of user innovations can be seen in innovation descriptions provided in the study of mountain biking by Lüthje, Herstatt, and von Hippel (2002). In that study sample, I estimate that at most 10 of 43 innovations had functionality similar to that of another sample member. This diversity makes sense: mountain biking, which outsiders might assume is a single type of athletic activity, in fact has many subspecialties.

As can be seen in table 3.1, the specializations of mountain bikers in the our study sample involved very different mountain biking terrains, and important variations in riding conditions and riding specializations. The innovations users developed were appropriate to their own heterogeneous riding activities and so were quite heterogeneous in function. Consider three examples drawn from our study:

●  I ride on elevated, skinny planks and ladders, do jumps, steep technical downhills, obstacles and big drops. Solution devised: I needed sophisticated cycling armor and protective clothing. So I designed arm and leg armor, chest protection, shorts, pants and a jacket that enable me to try harder things with less fear of injury.

●  I do back-country touring and needed a way to easily lift and carry a fully loaded mountain bike on the sides of steep hills and mountains and dangle it over cliffs as I climbed. Solution devised: I modified the top tube and the top of my seat post to provide secure attachment points for a carrying strap, then I modified a very plush and durable mountaineering sling to serve as the over-shoulder strap. Because the strap sits up high, I only need to bend my knees a little bit to lift the bike onto my shoulders, yet it is just high enough to keep the front wheel from hitting when I am climbing a steep hill. Eventually, I came up with a quick-release lateral strap to keep the main strap from sliding off my shoulder, but it will easily break away if I fall or land in a fast river and need to ditch my bike.

●  When riding on ice, my bike has no traction and I slip and fall. Solution devised: I increased the traction of my tires by getting some metal studs used by the auto industry for winter tires. Then I selected some mountain biking tires with large blocks of rubber in the tread pattern, drilled a hole in the center of each block and inserted a stud in each hole.

Table 3.1 Activity specializations of innovating mountain bikers.

Source: Lüthje,Herstatt, and vonHippel 2002. This table includes the 111 users in the study sample who had ideas for improvements to mountain biking equipment. (Of these, 61 had actually gone on to build the equipment they envisioned.) Many of these users reported experience in more than one category of activity, so the sum in each column is higher than 111.

Evidence from Studies of Market Segmentation

Empirical data on heterogeneity of demand for specific products and services are sparse. Those most interested in studying the matter are generally mass manufacturers of products and services for consumers---and they do not make a practice of prospecting for heterogeneity. Instead, they are interested in finding areas where users' needs are similar enough to represent profitable markets for standard products produced in large volumes. Manufacturers customarily seek such areas via market-segmentation studies that partition markets into a very few segments---perhaps only three, four, or five. Each segment identified consists of customers with relatively similar needs for a particular product (Punj and Stewart 1983; Wind 1978). For example, toothpaste manufacturers may divide their markets into segments such as boys and girls, adults interested in tooth whitening, and so on.

Since the 1970s, nearly all market-segmentation studies have been carried out by means of cluster analysis (Green 1971; Green and Schaffer 1998). After cluster analysis places each participant in the segment of the market most closely matching his needs, a measure of within-segment need variation is determined. This is the proportion of total variation that is within each cluster, and it shows how much users' needs deviate from the averages in “their” respective segments. If within-segment variation is low, users within the segment will have fairly homogeneous needs, and so may be reasonably satisfied with a standard product designed to serve all customers in their segment. If it high, many users are likely to be dissatisfied---some seriously so.

Within-segment variation is seldom reported in published studies, but a survey of market-segmentation studies published in top-tier journals did find 15 studies reporting that statistic. These studies specified 5.5 clusters on average, and had an average remaining within-cluster variance of 46 percent (Franke and Reisinger 2003). Franke and von Hippel (2003b) found similar results in an independent sample. In that study, an average of 3.7 market segments were specified and 54 percent of total variance was left as within-segment variation after the completion of cluster analysis. These data suggest that heterogeneity of need might be very substantial among users in many product categories.  ²

A Study of Heterogeneity and Willingness To Pay

A need for a novel product not on the market must be accompanied by adequate willingness to pay (and resources) if it is to be associated with the actual development or purchase of a custom product. What is needed to reliably establish the relationship among heterogeneity of demand, willingness to pay, and custom product development or purchase is studies that address all three factors in the same sample. My colleague Nikolaus Franke and I conducted one such study in a population of users of web server software, a product used primarily by industrial firms (Franke and von Hippel 2003b).

Franke and I looked in detail at users' needs for security features in Apache web server software, and at users' willingness to pay for solutions that precisely fit their needs. Apache web server software is open source software that is explicitly designed to allow modification by anyone having appropriate skills. Anyone may download open source software from the Internet and use it without charge. Users are also explicitly granted the legal right to study the software's source code, to modify the software, and to distribute modified or unmodified versions to others. (See chapter 7 for a full discussion of open source software.)

Apache web server software is used on web server computers connected to the Internet. A web server's function is to respond to requests from Internet browsers for particular documents or content. A typical server waits for clients' requests, locates the requested resource, applies the requested method to the resource, and sends the response back to the client. Web server software began by offering relatively simple functionality. Over time, however, Apache and other web server software programs have evolved into the complicated front end for many of the technically demanding applications that now run on the Internet. For example, web server software is now used to handle security and authentication of users, to provide e-commerce shopping carts, and gateways to databases. In the face of strong competition from commercial competitors (including Microsoft and Sun/Netscape), the Apache web server has become the most popular web server software on the Internet, used by 67 percent of the many millions of World Wide Web sites extant in early 2004. It has also received many industry awards for excellence.

Franke and I created a preliminary list of server security functions from published and web-based sources. The preliminary list was evaluated and corrected by experts in web server security and Apache web server software. We eventually ended up with a list of 45 security functions that some or many users might need. Solutions to some were already incorporated in the standard Apache code downloadable by users, others were available in additional modules, and a few were not yet addressed by any security module generally available to the Apache community. (Security threats can emerge quickly and become matters of great concern before a successful response is developed and offered to the general community. A recent example is site flooding, a form of attack in which vandals attempt to cause a website to fail by flooding it with a very large number of simultaneous requests for a response.)

Users of the security functions of web server software are the webmasters employed by firms to make sure that their software is up to date and functions properly. A major portion of a webmaster's job is to ensure that the software used is secure from attacks launched by those who wish illicit access or simply want to cause the software to fail in some way. We collected responses to our study questions from two samples of Apache webmasters: webmasters who posted a question or an answer on a question at the Apache Usenet Forum  ³ and webmasters who subscribed to a specialized online Apache newsgroup.  ⁴ This stratified sample gave us an adequate representation of webmasters who both did and did not have the technical skills needed to modify Apache security software to better fit their needs: subscribers to apache-modules.org tend to have a higher level of technical skills on average than those posting to the Apache Usenet Forum. Data were obtained by means of an Internet-based questionnaire.

The Heterogeneity of Users' Needs

Franke and I found the security module needs of Apache users were very heterogeneous indeed both among those that had the in-house capability to write code to modify Apache and those that did not. The calibrated coefficient of heterogeneity, H_c, was 0.98, indicating that there was essentially no tendency of the users to cluster beyond chance. (We defined the “heterogeneity of need” in a group as the degree to which the needs of i individuals can be satisfied with j standard products which optimally meet their needs. This means that heterogeneity of need is high when many standard products are necessary to satisfy the needs of i individuals and low when the needs can be satisfied by a few standard products. The higher the coefficient the more heterogeneous are the needs of users in a sample. If the calibrated heterogeneity coefficient H_c equals 1, there is no systematic tendency of the users to cluster. If it is lower than 1, there is some tendency of the individuals to cluster. A coefficient of 0 means that the needs of all individuals are exactly the same.  ⁵ )

Even this understates the heterogeneity. Responding Apache webmasters went far beyond the 45 security-related functions of web server software that we offered for their evaluation. In our questionnaire we offered an open question asking users to list up to four additional needs they experienced that were not covered by the standard list. Nearly 50 percent used the opportunity to add additional functions. When duplicates were eliminated, we found that 92 distinct additional security-related needs had been noted by one or more webmaster users. ⁶

High heterogeneity of need in our sample suggests that there should be a high interest in obtaining modifications to Apache---and indeed, overall satisfaction with the existing version was only moderate.

Willingness to Pay for Improvements

It is not enough to want a better-fitting custom product. One must also be willing and able to pay to get what one wants. Those in the Apache sample who did innovate were presumably willing to pay the price to do so. But how much were the users in our sample---the innovators and the non-innovators--- willing to pay now for improvements? Estimating a user's willingness to pay (WTP) is known to be a difficult task. Franke and I used the contingent valuation method, in which respondents are directly asked how much they are willing to pay for a product or service (Mitchell and Carson 1989). Results obtained by that method often overestimate WTP significantly. Empirical studies that compare expressed WTP with actual cash payments on average showed actual spending behavior to be somewhat smaller than expressed WTP in the case of private purchases (such as in our case). In contrast, they generally find willingness to pay to be greatly overstated in the case of public goods such as the removal of a road from a wilderness area.  ⁷

To compensate for the likely overstatement of expressed relative to actual WTP in our study, Franke and I conservatively deflated respondents' indicated willingness to pay by 80 percent. (Although the product in question was intended for private use, webmasters were talking about their willingness to spend company money, not their own money.) We asked each user who had indicated that he was not really satisfied with a function (i.e., whose satisfaction with the respective function was 4 or less on a 7-point scale, where 1 = not satisfied at all, and 7 = very satisfied) to estimate how much he would be willing to pay to get a very satisfactory solution regarding this function. After deflation, our sample of 137 webmasters said they were willing to pay $700,000 in aggregate to modify web server software to a point that fully satisfied them with respect to their security function needs. This amounts to an average of $5,232 total willingness to pay per respondent. This is a striking number because the price of commercial web server software similar to Apache's for one server was about $1,100 at the time of our study (source: www.sun.com, November 2001). If we assume that each webmaster was in charge of ten servers on average, this means that each webmaster was willing to pay half the price of a total server software package to get his heterogeneous needs for security features better satisfied.

Increased Satisfaction from Customization of Apache

Recall that it takes some technical skill to modify Apache web server software by writing new code. In table 3.2, Franke and I examined only the technically skilled users in our sample who claimed the capability of making modifications to Apache web server software. For these technically skilled users, we found significantly higher satisfaction levels among those that actually did customize their software---but even the users that made modifications were not fully satisfied.

Table 3.2 Skilled users who customized their software were more satisfied than those who did not customize.

Source: Franke and von Hippel 2003, table 8. In this table, 45 individual functions are grouped into five general categories. The satisfaction index ranges from -21 to +21.

One might wonder why users with the ability to modify Apache closer to their liking were not totally satisfied. The answer can be found in respondents' judgments regarding how much effort it would require to modify Apache still more to their liking. We asked all respondents who indicated dissatisfaction of level 4 or lower with a specific function of Apache how much working time it would cost them to improve the function to the point where they would judge it to be very satisfactory (to be at a satisfaction level of 7). For the whole sample and all dissatisfactions, we obtained a working time of 8,938 person-days necessary to get a very satisfactory solution. This equals $78 of incremental benefit per incremental programmer working day ($716,758 divided by 8,938 days). This is clearly below the regular wages a skilled programmer gets. Franke and I concluded from this that skilled users do not improve their respective Apache versions to the point where they are perfectly satisfied because the costs of doing so would exceed the benefits.

Discussion

Heterogeneity of user need is likely to be high for many types of products. Data are still scanty, but high heterogeneity of need is a very straightforward explanation for why there is so much customization by users: many users have “custom” needs for products and services.

Those interested can easily enhance their intuitions about heterogenity of user need and related innovation by users. User innovation appears to be common enough so that one can find examples for oneself in a reasonably small, casual sample. Readers therefore may find it possible (and enjoyable) to do their own informal tests of the matter. My own version of such a test is to ask the students in one of my MIT classes (typically about 50 students) to think about a particular product that many use, such as a backpack. I first ask them how satisfied they are with their backpack. Initially, most will say “It's OK.” But after some discussion and thinking, a few complaints will slowly begin to surface (slowly, I think, because we all take some dissatisfaction with our products as the unremarkable norm). “It doesn't fit comfortably” in this or that particular way. “When my lunch bag or thermos leaks the books and papers I am carrying get wet---there should be a water proof partition.” “I carry large drawings to school rolled up in my backpack with the ends sticking out. They are ruined if it rains and I have not taken the precaution of wrapping them in plastic.” Next, I ask whether any students have modified their backpacks to better meet their needs. Interestingly enough, one or two typically have. Since backpacks are not products of very high professional or hobby interest to most users, the presence of even some user innovation to adapt to individual users' unmet needs in such small, casual samples is an interesting intuition builder with respect to the findings discussed in this chapter.