The Difference between “Want” and “Need”
We often hear Steve Jobs or Henry Ford quoted as reasons why companies should not listen to their customers. People love to throw “Customers don’t know what they want until you show it to them” (Jobs) and “If I had asked people what they wanted, they would have said a faster horse” (Ford) as reasons why innovation should be a company run, insular, closed to the public process where a handful of smart employees define the future.
The problem with using these statements to defend insular, introverted innovation is two-fold. First, such a position misunderstands both the context within which these statements were made and subsequently the point both innovators were attempting to make. Second and most importantly, the position of supporting insular innovation simply isn’t supported and in fact is refuted by the extant research on the drivers of innovation. The companies with the highest levels of innovation are and always have been outwardly focused and intent upon learning how customers interact with their products (see The Power of Customer Misbehavior and our research on innovation and scalable organizations).
Let’s tackle the misunderstanding of these statements first. Both Jobs and Ford are identifying the difference between what customers want and what a given market needs. Their point is that what a customer says they want is seldom what a market (a large group of customers) truly need – or at the very least that what customers want won’t be as good as identifying and meeting their true need. Specifying and fully developing a want is misguided by an untested hypotheses associating the to-be product with a desired outcome. Because the specification isn’t guided and course-corrected by iterative testing against a market environment, the longer the program of development runs (and the larger the product), the more likely it is that the product will miss the maximum opportunity. Waterfall development, while appropriate in some areas (such as negotiated contracts without room for testing against a real need), is all about developing a want codified within a product specification.
The alternative approach is to start with a necessary outcome (e.g. first digital encapsulated music player without removable mass storage media, or better transportation) and a hypothesis as to how to get there (hard drive for mass storage and software for transferal, 8 HP 2 speed engine and transmission with 2 or 4 seats). In these cases, neither product took a long time to build (especially for “hardware”). Instead, the companies looked to bring a product to market quickly and learn from it. To show how quickly the teams were iterating and fixing the mistakes in their initial products, Apple released a new generation of their iPod or a new model every year for at least six straight years and corrected such initial deficiencies as not supporting Windows for the iTunes OS and not having a solution for digital music downloads (the iTunes store). Ford produced 4 new car models (the Model AC, Model C, Model B and Model F) within the 4 years after initial Model A launch in 1903. These vehicles addressed the engine being underpowered, overheating, weight limitations, etc.
The point here is that great product teams understand that the greatest value is derived from achieving the outcomes associated with a need, not the specifications of a want. Needs are met by defining a measurable outcome, building a testable hypotheses (minimum viable product or MVP) as to what will partially fulfill that outcome and then iteratively and rapidly correcting the hypotheses (MVP) to achieve the desired results.