Don’t Wait Until AIoT Becomes Popular. Universities Must Prepare Their Lecturers and Students Now

What if the most valuable technology skill of the next decade is something our universities and polytechnics are only beginning to teach? And what if we miss the opportunity simply because we waited too long to prepare?

Throughout my career, from teaching at Universiti Teknologi Malaysia (UTM) to working at CELCOM, conducting research at MIMOS, and eventually building FAVORIOT, I have witnessed how technologies emerge and create opportunities for those who recognise their potential early.

When the Internet of Things (IoT) first attracted attention, very few people understood how to build complete connected systems. We had electronics engineers, telecommunications specialists and software developers, but finding someone who understood how everything worked together was difficult.

Those who started learning early gained valuable experience. They built prototypes, made mistakes, solved technical problems and gradually became the specialists that industries needed.

Today, I see a similar opportunity emerging with Artificial Intelligence of Things (AIoT). But this time, I believe our universities and polytechnics must act earlier.

AIoT Is More Than Learning Artificial Intelligence

Artificial Intelligence is becoming increasingly accessible. Students can use AI to generate code, analyse information, prepare assignments and develop applications. These are useful skills, but AIoT introduces another level of technical capability.

AIoT combines intelligence with the physical world. Imagine factories where machines detect unusual operating conditions, buildings that identify energy wastage, or environmental monitoring systems that provide earlier warnings of potential dangers.

Building these applications requires knowledge of sensors, communication networks, IoT platforms, machine learning, cybersecurity and operational processes.

Finding professionals who understand all these disciplines remains challenging. This creates an opportunity for students who begin developing AIoT expertise before it becomes widely available.

Before We Train Students, We Must Train Their Lecturers

Having spent years in academia, I strongly believe that educational change must begin with educators themselves.

We cannot expect lecturers to teach emerging technologies confidently if they have not been given opportunities to learn and experiment with them.

Universities and polytechnics should begin sending lecturers for specialised AIoT training, even before introducing dedicated AIoT programmes.

There are several reasons why this matters:

Lecturers become the first generation of AIoT educators. They develop the knowledge required to introduce AIoT concepts across existing engineering and computing courses.
Students benefit from practical teaching. Trained lecturers can guide students beyond theoretical lessons into real sensor connectivity, analytics and intelligent applications.
Final-year projects become more relevant. Students can develop solutions involving predictive maintenance, energy monitoring, smart agriculture and environmental intelligence.
Research opportunities expand. Lecturers can explore multidisciplinary research and collaborate with industry partners.
Educational institutions gain an early advantage. Universities that prepare their lecturers now may become recognised centres for AIoT education and applied research.

Training lecturers should not be viewed simply as another professional development activity. It is an investment in the future capabilities of their students.

Why Early AIoT Skills Matter

Students who begin learning AIoT today may enjoy several advantages. They can develop specialist knowledge before competition increases, gain experience across multiple technical disciplines and explore opportunities in manufacturing, agriculture, energy, utilities and smart cities.

More importantly, they can begin building real solutions while others are still learning introductory concepts.

I have always believed that practical experience gives young engineers confidence. When students successfully connect sensors, collect real-time data, apply machine learning and demonstrate useful results, they begin seeing themselves as solution builders rather than simply graduates seeking employment.

That confidence can influence their entire careers.

Universities Should Not Wait for Industry Demand

One concern I often have is that educational programmes sometimes respond only after industries begin reporting skills shortages.

By then, preparing lecturers, developing laboratories, revising curricula and producing graduates may take several more years.

We should reverse that approach. Universities and polytechnics should identify emerging technical capabilities and prepare their educators before demand becomes widespread.

Start by sending a small group of lecturers for AIoT training. Allow them to develop practical projects, share their knowledge with colleagues and introduce AIoT components into existing courses.

Over time, these efforts can grow into specialised laboratories, research groups and industry collaborations.

My Message to Education Leaders

When we started building FAVORIOT in 2017, IoT was still developing. The experience taught me that entering an emerging field early can be difficult, but it also creates opportunities to build expertise that others may take years to acquire.

I do not want our next generation of engineers to discover AIoT only when companies begin urgently searching for experienced professionals.

If we want students to become future AIoT experts, we must first give their lecturers the opportunity to become AIoT educators.

The next generation of AIoT talent may already be sitting in our classrooms. What they need are educators who can recognise their potential, guide their experiments and prepare them for opportunities that are only beginning to emerge.

My hope is that Malaysian universities and polytechnics will start preparing today, not because AIoT has already become popular, but because they believe our students deserve to be among the pioneers of tomorrow.

Why Are IoT Companies Afraid of Working With Other IoT Platforms?

After spending years building an IoT platform, I have learned something interesting. Sometimes, the biggest obstacle to collaboration is not technology. It is the fear of losing control.

Whenever I meet solution providers who have developed their own IoT platforms, I occasionally encounter a familiar reaction when discussing potential collaboration.

“We already have our own platform.”

“We don’t need another platform.”

“What happens if your platform eventually replaces ours?”

I understand their concerns. Building an IoT platform is not easy. It requires years of software development, technical expertise, financial investment and countless hours of troubleshooting. When you have invested so much into something, the last thing you want is another company coming along and taking away your customers.

But after building FAVORIOT since 2017, I have come to see this situation differently.

What if another IoT platform is not your competitor but the missing piece that makes your solution more valuable?

The Reality of Building an IoT Platform

When we started developing FAVORIOT, we had to make many decisions about which capabilities to build first. Connecting devices was only the beginning. We needed ways to manage devices, collect data, store information, create dashboards and trigger alerts.

As the platform developed, customers began expecting more capabilities. Analytics, machine learning, artificial intelligence, intelligent reporting and automation became increasingly relevant.

This taught me an important lesson.

An IoT platform is never truly finished.

There will always be new customer requirements, new technologies and new industry applications. Even companies with large engineering teams cannot realistically become specialists in every technology and industry.

Today, an IoT solution may require device connectivity, data storage, visualisation, analytics, AI, machine learning, rules engines, security and application services. Each component requires continuous development and maintenance.

The question is whether every company needs to develop all these capabilities independently.

I don’t believe so.

Why Must We Build Everything Ourselves?

Imagine a company that has developed a successful smart agriculture solution.

Its platform monitors soil moisture, temperature, humidity and irrigation systems. The company understands farming operations, knows its customers and has developed applications that solve genuine agricultural problems.

One day, a customer requests predictive analytics, intelligent reporting and anomaly detection.

Should the company recruit more engineers and spend another year developing these capabilities?

Or should it connect its existing solution to another platform that already provides them?

Personally, I would seriously consider the second option.

The company can continue owning its agriculture application, maintaining its customer relationships and protecting its intellectual property. The additional platform simply provides capabilities that strengthen the existing solution.

There is no reason why both platforms cannot coexist when their technical architectures and commercial arrangements support it.

We should stop confusing technology collaboration with business surrender.

My Experience Building FAVORIOT

At FAVORIOT, we have developed capabilities covering data ingestion, device management, storage, dashboards, analytics, machine learning, AI reporting and automation.

We also introduced Faybee, our AI assistant, and FAVORIOT MCP to support new ways of interacting with operational data and applications.

But I have never believed that FAVORIOT should develop every industry-specific solution ourselves.

We need companies that understand manufacturing, agriculture, energy, buildings, utilities, transportation and other industries.

These companies already possess something extremely valuable: industry knowledge and customer relationships.

FAVORIOT can provide an additional technology layer to strengthen their applications. In return, our partners can help bring our platform into industries where they already have expertise.

This is how I believe a healthy IoT business ecosystem should operate.

Your Competitor Could Become Your Sales Partner

There is another opportunity that many companies overlook.

When two technology companies collaborate, they are not simply sharing software capabilities. They may also be opening their respective business networks.

Imagine a solution provider with a strong industrial monitoring application but limited marketing resources.

Now imagine working with a platform company that has relationships with system integrators, enterprises, universities and technology partners.

The solution provider could gain access to potential customers it would otherwise struggle to reach.

Similarly, the platform company benefits because it can introduce a complete industry-specific solution rather than offering only its underlying technology.

Both companies can explore joint demonstrations, customer referrals, marketing campaigns, project proposals and co-selling arrangements.

Of course, clear agreements are necessary to protect customer relationships, intellectual property and commercial interests.

But these are business matters that can be negotiated. They should not automatically prevent collaboration.

Perhaps We Are Afraid of the Wrong Competitor

Over the years, I have seen technology companies spend enormous amounts of time developing features that already exist elsewhere.

Sometimes, this is necessary because the feature is central to their competitive advantage. But sometimes, it is simply because they believe everything must be developed internally.

Meanwhile, customers are waiting, competitors are moving and development costs continue increasing.

I have learned that building a successful technology business is not about owning every piece of technology.

It is about knowing what you do best, recognising what others do better and finding ways to create greater value together.

After nearly a decade building FAVORIOT, I increasingly believe that collaboration can create opportunities that individual companies may never achieve alone.

The next time another IoT platform company approaches you, perhaps you should not immediately ask whether it will replace your platform.

Instead, ask a different question.

“Can we combine our strengths, improve our solutions and win more customers together?”

Sometimes, the company you thought was your competitor could become one of your most valuable business partners.

The Museum Was Monitoring Its Environment. The Problem Was What Happened Between Inspections

One thing I have learned from IoT projects is that customers do not always have a technology problem. Sometimes they already have instruments, procedures and people doing the work. The weakness lies in what they cannot see between one observation and the next.

This was the situation at a national museum responsible for preserving valuable collections, including textiles, manuscripts, ceremonial artifacts and archaeological objects. Temperature, humidity and light can affect these materials over time, so environmental conditions within the storage areas needed to be carefully monitored.

The museum was already doing this. Staff conducted scheduled inspections, checked instruments and recorded readings. On paper, there was a monitoring process. In practice, there were hours between inspections when nobody knew whether conditions had changed.

What Problem Were We Actually Solving?

Suppose someone checks the humidity at 9:00 am and everything looks normal. At 10:30 am, the humidity rises beyond its acceptable range. If the next inspection is several hours later, the problem remains invisible during that period.

That was the gap we wanted to close. The museum needed continuous monitoring, automatic alerts when conditions became abnormal, historical trends and a digital record of what happened throughout the day.

We describe this condition as operational blindness. The organisation may be operating normally, but there are periods when it cannot see the actual condition of something important.

How Was the System Deployed?

Rather than trying to measure everything possible, the deployment concentrated on three important parameters: temperature, relative humidity and light.

LoRa sensors collected the readings from storage areas and sent them wirelessly to a gateway. The gateway transmitted the information through a 4G connection to the FAVORIOT Platform, where the data could be stored, displayed and continuously checked against configured thresholds.

Using wireless sensors and cellular connectivity also reduced dependence on new cabling and the museum’s internal network during the initial deployment.

The exact deployment duration was not recorded in the case study, so I would not attach an unsupported number of days or weeks to the project. What mattered was designing an architecture that could be deployed without unnecessarily disturbing the museum’s existing infrastructure.

What Changed for the Customer?

The biggest change was moving from scheduled observation to continuous awareness. Environmental conditions could now be monitored 24 hours a day, while alerts could reach designated personnel in less than 60 seconds when readings crossed configured thresholds.

The museum also gained a digital, time-stamped history of readings and events. Instead of manually collecting environmental readings during routine rounds, staff could rely on continuous data capture and focus their attention on situations that required intervention.

This is an important distinction. IoT should not simply create another task for employees. It should remove unnecessary work while helping people respond faster when their attention is genuinely needed.

Did It Save Costs?

We do not have documented figures showing the monetary savings from this project, so it would be misleading to claim a particular percentage or amount.

There were, though, clear areas where operational effort was reduced. Manual inspection rounds were no longer required specifically to collect environmental readings. The wireless architecture reduced the need for significant new cabling, while cellular connectivity reduced initial dependence on the museum’s existing network infrastructure.

For me, those are useful outcomes even before putting a ringgit value against them. Staff time has value. Avoiding unnecessary infrastructure work has value. Discovering an environmental problem earlier may have even greater value when the assets being protected cannot simply be replaced.

Connect, See and Act

This project explains our Connect • See • Act™ thinking very simply.

Connect means bringing conditions from the physical environment into the digital system through sensors and communications. See means turning those readings into continuous awareness, historical trends and alerts rather than occasional snapshots. Act means getting the right information to the right person while there is still time to respond.

The museum did not simply need more data. It needed to know when something was changing before that change became a bigger problem.

That is the difference between collecting data and creating operational visibility.

[Note: Favoriot Use Case – Museum Environmental Monitoring]

“Send Me a Proposal”: The Costly B2B Sales Mistake I Made as a Startup Founder

When a Proposal Felt Like a Breakthrough

In the early days of my startup, hearing a company say, “Send me a proposal,” felt like recognition. Someone had noticed our work and thought we might be able to help. I was happy to spend time on it because I could imagine the proposal becoming our first project with that customer. If it went well, perhaps a small project would grow into a long relationship.

A request worth millions of ringgit was even harder to resist. Before anything had been agreed, I found myself thinking about hiring, growth and what similar projects might mean for the next three to five years. For a founder building a company from the ground up, those possibilities feel real. They give you energy when the business needs it most.

The Work Begins Before the Deal Exists

My team and I would prepare the architecture, estimate the costs and ask partners for their prices. We wanted to give the customer our best answer. Yet sometimes we did not know enough about the site, devices, data, responsibilities or expected outcome to design a sound solution. When we asked, the reply was often, “Just give us your best proposal,” or “You suggest.”

That left us making assumptions about the scale of the work. We spent days debating options with partners and trying to price a project whose boundaries nobody had defined. The proposal might look complete when we submitted it, but much of it rested on guesses. Even a carefully written price could be wrong if the actual requirements later changed.

Then came the silence. Some customers never replied. Others said they would keep the proposal and budget for reference. Often, we never learned whether the project went to someone else, lacked funding, had no internal owner or was never ready to enter procurement. The hours we had spent preparing it were gone.

What Those Proposals Taught Me

That experience was frustrating because I had mistaken interest for commitment. A request for a proposal can be a serious step toward a project, but the words alone tell me very little. The lessons cost my small team time and money:

Find the problem owner. I need to know who will use the proposed solution, who is responsible for the outcome and who can approve the next step.
Ask what is known about the budget and timing. A customer may not have a final figure, but they should be able to explain whether funding exists and when a decision could be made.
Understand the buying process. A direct award, competitive tender and early market study call for different amounts of work.
Record what remains unknown. If key requirements are missing, I should not present assumptions as firm scope or a final price.
Protect the team’s time. Preparing a detailed design has value. Giving it away repeatedly leaves fewer resources for customers who are ready to act.

These are practical business lessons I did not learn at university. I learned them while trying to keep a startup moving with limited people and cash.

A Different Answer Today

When someone now asks for a large proposal without a clear scope, I first ask about the problem, budget, timeframe, project owner and procurement route. If they need us to investigate requirements, work through the architecture and develop a costed plan, I propose a paid consultation. It gives the customer something more useful than a proposal built on guesses, while allowing us to put proper care into the work.

I still welcome a genuine opportunity. I also understand that a proposal request may be the start of a conversation, rather than a sign that a project is ready. It took me longer than I wish to learn that distinction. The cost was real, but so was the lesson: a founder must believe in what the company can build and know when to ask whether the customer is ready to build it with them.

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.

Awareness does not automatically create demand. Someone can understand IoT very well without having a strong enough operational reason to buy a solution.
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.
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.
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.
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.