In the beginning of the 2000s, while the small company I had cofounded in 1990 was still active, we decided to answer a Request for Proposal submitted by a waste removal company, for a system allowing to check whether all planned daily garbage collections had been performed. At this time, we didn’t know a lot about the waste removal market. But we knew we were experienced enough in technologies we would have to assemble in order to answer the RFP: onboard equipment and embedded software, GNSS positioning, wireless communications, Geographical Information Systems, etc.
As this market was new for us, we did what we were usually doing in such a situation: we tried to really understand how the company was working, which problems they had, and why they had submitted the RFP. For this last question, the answer was really clear: in their turn, the waste removal company was answering an RFP from the local authority. And this RFP was requesting that every morning, the company should provide the local authority with reports listing planned garbage collections that had been performed, planned garbage collections that had not been performed (and the reason), and garbage collections that had been performed while not planned.
We spent lot of time talking with the manager of the company. At the beginning, it was not so easy to get access to him. But after a while he understood that even if we were not experienced in his market, we really wanted to solve his day-to-day problems in a durable way. And he accepted to answer more questions, and let us speak with some supervisors and some truck drivers. We asked for details about various types of trucks they were using, how long they were on the road every day, whether some electronics was already installed, if the drivers were alone in their truck, the reasons why some planned collections were not performed, security problems they were facing, etc.
After a while, we also understood that two other system providers would answer the RFP. The two of them were experienced in the waste removal field, and had already provided systems for some large cities in Europe. We spent some time gathering information about those systems. They were based on the usual architecture: onboard equipment with embedded GNSS receiver and GSM module, central application software (digital maps, reports, etc.), and truck tracking using GSM network (CSD or SMS at this time). How could our proposal win, against those competitors?
A few days before finalizing our proposal, we got an idea. One more time, we called the company manager, because we wanted to be sure about our idea. When we told him about it, he burst into laughter, and answered us that we were right.
So, what was our idea? We had noticed that the local authority RFP did not contain any request for a “real-time” tracking function. Consequently, there was no requirement to fit every truck with a GSM module! We answered with a system based on an onboard equipment able to store one day of data. And at the end of the day, data was downloaded using a cable that was connected to the equipment. So, no recurring costs (no mobile data subscription) and a lower equipment cost (no GSM module)!
Our customer won the local authority RFP. And, consequently, we won his company’s RFP.
The conclusion is simply: understand customer needs better than they understand them themselves.
This example relates to the development of a full system. But above way of considering user needs can be applied to subsystems as well. In all cases, the key is the ability to listen to the customer, to separate functional view from technical view, and to be experienced in associated technical fields.