There is a train of thought that the route to success in a business is giving a customer what they say they want. At some level this is obviously good advice. But there are two problems with it. Firstly, the customer always wants incremental improvement on what they already have, and rarely is imaginative enough to ask for what they really need. And secondly, this can lead to design by committee producing a product that has too many features to be usable.
A nice example of this is Apple’s design of the iPhone. Nobody knew they wanted it. In a vague sort of way they probably wanted a phone from Apple knowing it would be Mac and iPod-like. Luckily Apple didn’t simply go and ask all the carriers what they wanted, they designed what they wanted to and then found a carrier willing to take it largely unseen. Of course lots of people were involved in the iPhone design, not just CEO Steve Jobs and chief designer Jonathan Ive (another Brit, by the way, referring back to my post about the benefits of easier immigration) but it was designed with a conceptual integrity rather than a list of tick-the-box features. The first version clearly cut a lot of corners that might have been fatal: no 3G data access, no GPS, no cut-and-paste, no way to send photos in text messages, only a couple of applications honored landscape mode. The second version came with 3G and GPS. Most of the rest of the initial peeves are now fixed in the 3.0 version of the operating system (which, as a registered iPhone developer, I already have installed). But the moral is that they didn’t ask their customers to produce a feature list, and they didn’t make an attempt to implement as much of that list as possible.
When I was at Cadence we were falling behind in place and route. So we decided to build a next generation place and route environment including everything the customers wanted. It was to be called Integration Ensemble. We asked all our customers what the requirements should be. So, of course, it ended up as a long list of everything every group had ever wanted, with little conceptual integrity. In particular, for example, customers insisted that integration ensemble should provide good support for multiple voltages, which were just going mainstream at that time, or they wouldn’t even consider it. We specced out such a product and started to build it. With so many features it would take longer to build than customers would want to wait but customers were insistent that anything less than the full product would be of no use. Then these same customers all purchased Silicon Perspective since what they really needed was good placement and fast feedback, which was not at the top of their list. Silicon Perspective did not even support multiple voltage supplies at that point. The end of that story was that Cadence expensively acquired Silicon Perspective and Integration Ensemble was quietly dropped. The customers got what they wanted even though they never asked for it.
One area where marketing is especially easy is when the developer is the customer for the product, when they are “eating their own dogfood” as the saying goes. This is one of the factors driving success in open source software: the developers are usually their own customers. iPhone and other Apple products are also like this; the designers all will use the product. EDA software (and many other products from jet-engines to heart-pacemakers) are generally not like this, so marketing in the sense of product definition is required. Generally in this type of environment open source has been unsuccessful and a lot of the intellectual property (in the most general sense) of the product is not so much in the implementation but in the compromises around what to put in and what to leave out. Doing a good job of specifying products is one of the hardest parts of marketing, requiring a deep understanding of the customer problems and a deep enough understanding of the technology and engineering involved to deliver a solution.