We heard a familiar lament just a couple weeks ago from a VP of Engineering at one of our clients: “If the Sales team would just tell us the customer requirements, we could get on with designing the product.” We’ve heard something similar hundreds of times, and it sounds innocuous at first – what could be wrong with better understanding customer requirements?  But we have come to believe that the organizational constructs, processes and frameworks built around ‘customer requirements’ don’t work very well because the very idea is a myth – thinking that there is a precise list of exactly what the customer wants to buy is a dangerous over-simplification of how the world actually works.

A story might help illustrate our point.  Several years ago, we were working with a company that makes turbochargers. One critical feature of a turbocharger is ‘actuation,’ essentially the opening of the valve that allows the turbocharger to function, compressing the incoming air to enable more efficient combustion in the engine.  There are three ways to control actuation: pneumatic, electronic, or pneumatic with electronic position-sensing.  The company needed to know which to build into their development plans, as creating a world-class offering in all three types would be prohibitively expensive.

At the time, they were working with one of their largest customers,  a major German Auto OEM, on redesigning their 1.6-liter diesel engine design that would utilize a turbocharger.  The team contacted their account manager who worked with this customer and had spent hundreds of hours with their engine designers.  He was confident that this customer needed pneumatic actuation.  But when someone on the team asked him ‘why?,’ the response was a blank stare.  Clearly their customer’s engineers must be aware of the competing technologies, and they chose pneumatic – what was their thinking?

Somewhat reluctantly, the account manager set up a meeting with the engine designers at the OEM.  When it got to the critical question of actuation, the customer engineers began talking about the benefits of a fully electronic system in terms of durability and reliability.  The account manager jumped in, “but wait a minute, you told me clearly that for this engine you need a pneumatic actuator.  What’s going on?”  They replied that the immediate need was for pneumatic because their engine control module (the brain that runs the engine) had no available input/output ports.  Since anything electronic would require additional i/o ports, those solutions were verboten until the company had spent the tens of millions of Euros to redesign the engine control module. Pneumatic wasn’t really their preference – it was a compromise necessitated by something that had nothing to do with turbocharger performance! If our client had bet the future on this ‘customer requirement’ it would have led them to create an inferior product.

In general, several things are wrong with the concept that the job of the commercial team is simply to tease out customer requirements and document them for the rest of the organization:

• First, customers often don’t know what they want.  This is not an indictment, rather it reflects the truth that customers are expert in their business not yours – they don’t know what they don’t know.  And lots of research suggests that people are really bad at predicting how they will react to something they have not seen before. 
• Customers don’t have absolute needs, rather they make trade-offs.  We had a client that asked their largest and most important customer what they needed in their next generation product.  They replied, “we need it to be 20% lighter, 20% smaller footprint, and 20% cheaper.”  It wasn’t until after our client had built a prototype that they learned that the most important thing was the footprint.  In fact, the customer would have accepted a heavier product that cost more for an even smaller footprint – the 20 percent targets were arbitrary design goals.
• Not everyone inside the customer wants the same thing.  This may sound obvious, but it can be critical if overlooked. Just ask the suppliers to the automotive industry who spent millions of dollars designing things that the engineering groups at their customers ‘needed’ only to find that when they talked to purchasing, the required price was last year minus three percent.
• Somewhat related to the previous point, customers will often ask for things that they aren’t actually willing to pay for.  So a customer might say that they need an orange colored display, but how much do they need it?  Will they pay $5 for it, or $50 or nothing?  Without this more nuanced understanding, how can we know how much to spend on developing that feature? As one of our clients says: almost every problem has a solution, but not every solution has a customer willing to pay for it.
• Not every customer wants the same thing. We have written at length about segmentation and it is critical here as well.  Even if you have perfectly identified the requirements for a given customer, you need to know how many other customers need the same thing before deciding whether it is worth investing in.
• Lastly, even in the rare case where you can document a customer’s complete ‘spec’ for what they will buy, you have probably already lost.  If you weren’t the one who helped the customer write that spec, it is a safe bet that one of your competitors did.  Investing to match what your competitor already offers is just earning you the right to compete on price; and even then, the incumbent probably gets a chance to match.

If the goal is not to document ‘customer requirements,’ what is it? Our view is that the only way out is to become a student of your customer and their business.  This typically requires engaging them outside of the sales process (where they know that everything they say is an input to a negotiation) and really understanding the business trade-offs they face.  It is critical to set aside your biases and objectively understand the customer’s perspective and the context in which they make decisions and then understand how far we can generalize that perspective.

You will know this is working when everyone across the organization is instinctively asking ‘why’ questions whenever the idea of customer requirements surfaces and not just jumping immediately to the ‘how’ do we meet that requirement.  Another story highlights how this should work:

A company we know made portable gas detectors.  These are small battery-operated devices, typically clipped on the collar of a worker, that detect poisonous gas and emit an audible warning.  The device is a regulatory requirement in certain dangerous operating environments, most notably in oil refineries.  One of their larger customers has approached our client and asked if they could add a small light indicating a low battery. Thinking that they were being responsive to an important customer, they said ‘sure,’ and were well on the way to designing in that feature.

While the engineers were busy redrawing the circuitry, a product manager was asked to determine how to price this new feature. Using an approach like we described above, this product manager set out to understand why this customer wanted a low battery indicator and figure out what they might pay for it.  Walking the customer through a day in their life (clearly not part of a sales negotiation), they discovered that the value was potentially quite large.  Workers are not allowed to work with a non-functioning detector, so when a battery dies, they either ignore it, which is both a safety and compliance issue, or they stop working and walk back to a base station where they can get a new detector.  This was a major productivity issue at a refinery with hundreds of workers spread over sometimes dozens of square miles, and almost certainly an issue that would be relevant to lots of customers, not just this one.

Armed with this more nuanced understanding of the customer needs, the product manager designed a complete solution that would provide their customers with spare detectors, battery charging stations and software that ensured that each worker left their base with a working detector that would last through their shift.  In addition, the system would automatically document compliance if their customer was ever audited.  The result was that our client was able to capture an additional $30 per detector – far more than the $2-3 per detector that engineering was originally thinking based on the relatively small cost of adding the indicator light.

Thinking beyond ‘customer requirements’ is not easy.  It may require new skills to generate the required market insight, and it typically means an ongoing and robust two-way dialogue between commercial and technical teams, not a one-time hand-off of a requirements spec, as it is often conceptualized.  But as these stories indicate, getting it wrong can be disastrous and getting right can lead to exciting new opportunities to create value in ways you or your customers have not even imagined!