Tuesday, July 19, 2005

Engineering vs. Marketing Decision-Making Time-Horizons

I've noticed engineering and marketing groups differing sometimes over what time-horizon to be optimizing for when making a product trade-off. It comes up when engineering wants to build a low-level tool that has utility for the current and future products, call this generality. In these cases, marketing tends to be more concerned with the opposite of generality, namely specificity. Marketing just wants the tool to work well for the current product. Marketing's argument can be that it may be too early to generalize anyway, so may as well make the current product's instantiation of the tool work very well for the known case.

Sometimes a company might want to break generality for a tool because it’s particularly high value for a single product. Sometimes, though, it might want to break specificity for a single product’s application of a tool because it’s particularly high value for a multitude of future products.

I don't know what the "right" thing economical thing to do is in all these cases, but it sure would be nice to have a normative way of looking at it.

Friday, July 15, 2005

Change Management Problem Introducing User Toolkits

von Hippel and Thomke proposed "user toolkits for innovation" to address the age-old problem of communication breakdowns between engineering teams and product users that result in users not getting what they want. User toolkits are a way for engineering teams to expose enough control over their product for users to be able to customize or configure the product to address their specific need. Examples include a food flavorings company that provides buyers with a toolkit to create their own flavorings, a product category where it is difficult to create products because it is hard for buyers to describe in English the type of flavoring they want.

The user toolkit idea has a lot of merit as one solution to the communication problem companies face with their customers. But there is a change management problem in getting companies to adopt the idea of user toolkits. The problem is that companies believe they erode margins by not providing the full and complete product to end-users. They think that giving users a way to customize products is the same as shipping an incomplete product. If the users have to finish the product, they would not want to pay as much for it as if the product did exactly what the consumer wanted right out of the box.

Perhaps companies are right in believing that products are not as valuable if they require additional work on the user's part to configure them to their needs. Then again, maybe companies are misunderstanding the role of a user toolkit. Perhaps what companies are supposed to do is provide user toolkits in addition to complete products. In the beginning, a company may not be able to identify a mass-market for a specific complete product, so it should just put a user toolkit out there and then learn from consumers what are the most popular and valuable ways to configure the toolkit. Once a broadly-applicable adaptation based on the user toolkit is identified, the company can productize that adaptation and sell it for a higher margin than it sells the user toolkit for.