From Teaching IoT to Solving Real Problems: Lessons I Learned the Hard Way

Looking back at my years of building IoT solutions, I can see how much the conversation around IoT has changed. In the beginning, our challenge was convincing people that IoT mattered. Later, people wanted to learn how to build it themselves. Today, building an IoT prototype has become much easier, especially with generative AI helping people write code and solve technical problems. Yet one uncomfortable reality remains: the IoT market has not grown as quickly as many of us expected.

That experience has forced me to rethink what customers actually need from IoT. After years of developing FAVORIOT, conducting training, working on projects and watching pilots succeed technically but struggle commercially, I have learned that the biggest challenge is rarely the technology itself. The harder question is whether we are solving an operational problem that matters enough for someone to take ownership, allocate a budget and keep the solution running.

The Early Days Were About Explaining IoT

In the early days, many of our conversations started with a basic question: “What is IoT?” People had heard the term, but few understood how sensors, connectivity, cloud platforms and applications could work together. We spent considerable time educating customers, students and organisations about what IoT could do and why connecting physical assets could change the way operations were monitored.

At that time, simply demonstrating the technology could create excitement. When someone saw a sensor transmitting data to a cloud platform and displaying the information on a dashboard, it felt like something new. We could demonstrate remote monitoring, automatic alerts and real-time data collection, and people immediately became curious about the possibilities. We believed that once awareness increased, adoption would naturally follow.

Then People Wanted to Build IoT Themselves

As awareness grew, the questions changed from “What is IoT?” to “How can I build an IoT solution?” This created another chapter for FAVORIOT, where training became an important part of what we did. We conducted many IoT programmes involving sensors, Arduino, ESP32, Raspberry Pi, MQTT, cloud platforms, dashboards and application development.

The appetite for learning was strong because people wanted practical experience. Students wanted to build projects, lecturers wanted to introduce IoT into teaching and research, while engineers and professionals wanted to understand how connected systems could be applied in their organisations. IoT was gradually moving from something people heard about at conferences into something they could actually build with their own hands.

Then generative AI arrived, and we noticed another shift. Demand for traditional IoT training appeared to decline. One possible reason is that people can now ask an AI assistant how to connect an ESP32, generate MQTT code, troubleshoot an error or explain how a sensor works. Knowledge that once required attending a two-day workshop can now be accessed within minutes.

If IoT Is Easier to Build, Why Is the Market Still Slow?

This became an uncomfortable question for many IoT solution providers, including us. Sensors became cheaper, connectivity improved, platforms matured and technical knowledge became easier to obtain. Generative AI lowered the technical barrier even further, yet the commercial market for IoT still seemed to move much more slowly than the technology.

For a long time, we believed demonstrating stronger technology would help overcome this problem. We showed customers devices, dashboards, alerts, analytics and different ways of connecting physical assets. A good demonstration could attract attention, lead to discussions and sometimes result in a pilot project. Technically, many of these pilots worked exactly as expected.

The problem came afterward. Some pilots simply stopped. The sensors were working, data was flowing and dashboards were displaying information, yet the project never expanded. We slowly realised that proving technology could work was very different from proving that an organisation needed it badly enough to continue investing in it.

A Successful Pilot Can Still Become a Failed Project

That experience taught us to ask a different question: who owns the project after the pilot? Someone might approve an experiment, another department might provide the equipment and an IT team might help with connectivity, but nobody may actually be responsible for turning the pilot into part of daily operations.

Without operational ownership, a pilot can easily become a technology showcase rather than a working system. If nobody is accountable for the problem being addressed, nobody feels enough urgency to expand the solution. There may also be no operational budget, measurable outcome or internal champion willing to push the project beyond its experimental stage.

This changed the questions I now believe we should ask at the beginning of an IoT project. What operational problem is the customer experiencing? Who suffers when that problem occurs? What does the organisation lose when the problem remains invisible? Who receives the information generated by the system, and what action will that person take? Most importantly, who owns the outcome after the pilot finishes?

Customers Rarely Wake Up Wanting IoT

A maintenance manager probably does not arrive at work thinking about buying an IoT platform. He may simply want to know whether a remote pump has stopped running before someone complains. A facilities manager may want to understand why electricity consumption suddenly increased, while an environmental officer may need an early warning when water quality begins moving outside acceptable limits.

The same applies to energy systems, buildings, factories and remote assets. Customers are usually concerned about downtime, wasted energy, unnecessary site visits, equipment failures, delayed responses and things happening in their operations that they cannot see quickly enough. IoT becomes valuable when it helps expose those problems early enough for someone to act.

This has changed the way I think about FAVORIOT as well. Connecting devices remains necessary, but connection alone is not the outcome. Data must help someone see something they could not previously see, understand what is happening and decide what to do next. That is why Connect → See → Act represents something much deeper to me today than simply describing how an IoT platform works.

Lessons I Learned the Hard Way

After years of explaining IoT, teaching people how to build it, developing our own platform and watching projects move through different stages, several lessons have become difficult to ignore.

1. Awareness does not automatically create demand. Someone can understand IoT very well without having a strong enough operational reason to buy a solution.
2. Technical success is different from commercial success. Getting a sensor to transmit data and displaying it beautifully proves that the technology works. It does not prove that the organisation will continue paying for it.
3. Every pilot needs an operational owner. Someone inside the customer’s organisation must care about the outcome, be responsible for the problem and have enough influence to move the project forward.
4. Start with the pain, not the platform. Conversations about downtime, energy losses, unnecessary site visits, equipment failures and delayed responses are usually more meaningful than conversations about protocols, dashboards and technical specifications.
5. IoT creates value when visibility leads to action. Collecting more data is not enough. The real value comes when information helps someone recognise a problem earlier and respond before the consequences become more expensive.

Perhaps this has been one of the hardest lessons from building IoT solutions over the years. We spent the early years proving that IoT technology worked. We then spent years teaching people how to build it. Today, I believe the conversation has to move beyond both.

The future of IoT will not be decided by how many sensors we can connect or how impressive our dashboards look. It will be decided by whether we can help organisations see operational problems they could not see before and give the right people enough information to act.

That lesson took years of projects, pilots, training programmes, successes and disappointments for me to fully appreciate. Stop trying to sell customers IoT. Find the operational problem they desperately need to see, and make that problem visible.