In the beginning of the 2000s, while I was still working for the small company I had cofounded, 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 asnwer 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 it. When we told him about our idea, he burst into laughter, and answered us that we were right.
So, what was our idea? Simply 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 proposed 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)!
We won the RFP. And our customer won the the local authority RFP.
The conclusion, for this project case, is simply: understand customer needs better than he understands them himself.