Mazlan Abbas

I Thought a Successful Pilot Would Naturally Become a Real Project. I Was Wrong

For a long time, I had a simple belief about pilot projects. If we could demonstrate that the technology worked, solve the technical problems encountered during testing, and show the customer that the solution could operate successfully in a real environment, then moving into a commercial deployment seemed like the natural next step. It made perfect sense from an engineering perspective. Why would an organisation spend months testing something, prove that it works, and then decide not to continue?

Over the years, I discovered that the real world does not always follow engineering logic. A successful pilot proves that something can work, but it does not automatically prove that a customer will buy it, that a budget exists, that management will continue supporting it, or even that the market will still exist when the pilot ends. Two projects in particular taught me this lesson. Both were government funded pilots, both involved technologies that we successfully tested, and both gave us reasons to believe there was a future beyond the pilot. Yet neither became the commercial project we had hoped for.

What makes these two experiences interesting is that they ended for completely different reasons. The first was affected by an extraordinary event that nobody could control. The second exposed weaknesses in the way we had qualified the customer and the commercial opportunity. Together, they changed the way I think about pilots and taught me that technical success is only one small part of building a sustainable technology business.

Raqib: When We Found a Market and Then the Market Disappeared

The first project was Raqib, a product we developed around 2018 and 2019. Raqib originally began as a smart elderly care solution, using connected devices to help families and caregivers monitor the location and wellbeing of elderly people. As we developed and tested the concept, we began to see another possible application that shared many of the same challenges: monitoring pilgrims performing Hajj and Umrah.

The problem made sense to us. Pilgrims often travel in large groups and move through unfamiliar places, sometimes in extremely crowded environments. Many are elderly, and there is always a possibility that someone becomes separated from the group or needs assistance. We believed that connected devices could provide tour operators and family members with better visibility of where pilgrims were and help them respond more quickly when something went wrong.

We decided to reposition Raqib towards this market and began testing the concept more seriously. We conducted local trials and asked several early users to carry the devices during their pilgrimage. I even tested Raqib personally during my own Umrah trip because I wanted to experience the product under the same conditions as our users. That field experience was far more valuable than testing the system from the comfort of our office because it exposed issues involving connectivity, battery life, device handling and actual user behaviour.

There were challenges, of course, but that did not discourage us. In fact, that was exactly what we expected a pilot to reveal. We identified the problems, worked on them and improved the system. By the end of those trials, we had become increasingly confident that the technology could work. We had moved beyond PowerPoint slides and laboratory demonstrations. Real users had carried the product into the actual environment for which it was designed.

From where I stood at the time, the next stage seemed obvious. We had tested the product, learned from the problems and improved it. Now we needed to build the market.

Then 2020 arrived, and everything changed.

COVID-19 Changed the Question Overnight

When COVID-19 spread across the world, international travel came almost to a standstill. Borders closed, flights were cancelled, Umrah travel was suspended for long periods, and Hajj participation was severely restricted. For Raqib, this was not merely an operational inconvenience. The very activity around which we had positioned the product suddenly became inaccessible to most international pilgrims.

There was nothing our engineering team could fix because there was nothing technically wrong with the product that could solve the situation. We could improve the software, extend battery life, redesign the interface or improve the platform, but none of those things could reopen international borders or bring pilgrims back to Makkah.

Initially, like many businesses, we did not know how long the disruption would last. Perhaps travel would resume after a few months. Perhaps the following pilgrimage season would return to normal. But uncertainty continued, and for a small company, waiting indefinitely carries a very real cost.

A product continues consuming resources even when customers disappear. Servers must be maintained, software requires updates, devices need support, engineers have to spend time fixing problems, and management must continue thinking about the product. More importantly, every hour and every ringgit spent keeping one product alive is a resource that cannot be spent somewhere else.

Eventually, we had to make a difficult decision. We could continue supporting Raqib while waiting for the pilgrimage market to return, without knowing when that would happen, or we could accept that circumstances had changed and redirect our limited resources elsewhere. We chose to shut down the service and move on.

It was painful because Raqib had not failed in the traditional sense. The technology had been tested. We had real users. We had solved many of the problems discovered during field trials. Yet the commercial opportunity disappeared because of something nobody on our team could have predicted or controlled.

That experience taught me my first major lesson about pilots: even when you do many things correctly, timing and external events can still determine the fate of a product.

The Second Pilot Taught Me a More Uncomfortable Lesson

Our second experience was very different because this time there was no pandemic, no global shutdown and no disappearing market. The project involved the Favoriot IoT platform and a local council that wanted to test the platform’s functionality, standards interoperability and ability to work with several of its existing smart city solutions.

From a technical perspective, this was exactly the type of challenge that interested us. Smart cities rarely operate with one system from one vendor. A council may already have different systems for parking, CCTV, environmental monitoring, flood monitoring, street lighting and other municipal services. These systems may have been purchased at different times from different suppliers, which often means they use different architectures, protocols and applications.

One of the values of an IoT platform is its ability to connect these different environments and make information available across systems. During the pilot, Favoriot successfully demonstrated that capability. We tested the platform’s interoperability and showed that it could work with several of the council’s existing smart city solutions.

Technically, the pilot achieved what it was supposed to achieve. Naturally, we were pleased with the outcome, and once again I believed that we had crossed the most difficult hurdle. If the platform had demonstrated its capabilities in the customer’s environment and met the pilot objectives, surely the next logical step would be a commercial deployment.

It never happened.

The local council eventually decided not to proceed with Favoriot as its platform. They had different ideas about how they wanted to move forward, and the commercial project that we had imagined never materialised.

This time, I could not blame COVID-19, market conditions or an unexpected global event. The technology worked, the market still existed, and the organisation continued pursuing its smart city ambitions. Yet our successful pilot did not become a commercial project.

That forced me to examine something much closer to home: perhaps we had been too focused on proving our technology and not focused enough on proving that there was a committed customer waiting at the other end.

A Pilot Participant Is Not Necessarily a Customer

This distinction seems obvious to me today, but when you are inside a pilot project it can be surprisingly difficult to recognise. A participating organisation can behave very much like a customer. People attend meetings, technical officers provide requirements, sites are made available, integration discussions take place, demonstrations are conducted and progress reports are written. Everyone appears engaged, so it is natural for the technology provider to interpret that activity as evidence of future commercial commitment.

But participation and purchasing intent are two very different things.

An organisation may participate in a government funded pilot because it wants to learn about a new technology, compare different approaches or satisfy the objectives of a particular programme. The technical team may genuinely like the product and the operational department may find the solution useful, yet none of these conditions necessarily means that someone has approved a budget to purchase it after the pilot.

Looking back, this was one of our biggest mistakes. We spent considerable effort answering the question, “Can Favoriot successfully do what the customer needs?” We did not spend enough time answering the equally important question, “If Favoriot proves that it can do this, is the organisation genuinely prepared to buy and operate it?”

Those are two completely different validations.

Government Funding Can Sometimes Hide the Real Market Signal

I remain supportive of government funded technology programmes because they can be extremely helpful for startups and local technology companies. They allow companies to test products in real environments, provide access to organisations that might otherwise be difficult to reach, and reduce some of the financial risks involved in experimentation. Without such programmes, many technologies might never get the opportunity to move from laboratory prototypes into actual field environments.

At the same time, founders need to recognise a weakness in this model. When someone else pays for the pilot, the participating organisation does not have to make the same financial decision it would face during commercial deployment. Trying a technology using grant funding is very different from allocating your own operational budget, going through procurement and signing a purchase order.

This can create a false sense of market demand. Everyone may be enthusiastic while the pilot is funded, but once the external funding ends, the organisation suddenly has to justify the expense internally. Management priorities are reconsidered, budgets must be found, procurement procedures begin, other projects compete for the same money, and the technology that looked important during the pilot may suddenly become optional.

If I were evaluating such an opportunity today, I would ask a much harder question before committing significant resources:

If the government funding disappeared tomorrow, would this organisation still be willing to pay for the solution?

The answer tells us far more about the commercial opportunity than enthusiasm during a demonstration.

Technical Validation Is Only One Part of a Successful Pilot

My engineering background naturally influenced the way I viewed pilots. We tend to focus on measurable technical questions. Does the device communicate reliably? Can the platform handle the required data? Does the API connect properly? Can different systems exchange information? Do alerts work? Is the dashboard displaying the correct information?

These questions matter, but they represent only technical validation. A commercially meaningful pilot must test several other assumptions at the same time.

First, we need to establish whether the technology genuinely solves the operational problem. Second, we need to understand whether the problem is painful enough for the organisation to spend money solving it. Third, we need evidence that the value created by the solution can justify its cost. Fourth, there must be people inside the organisation who are committed to moving forward. Finally, there must be a realistic procurement and budget pathway after the pilot.

A pilot can pass every technical test while failing all the commercial ones.

That was perhaps the biggest change in my thinking. I stopped seeing a pilot as merely a technical experiment and started seeing it as a test of the entire commercial hypothesis.

Lesson One: Find the Buyer, Not Just the Pilot Site

Today, one of the first things I would want to understand is who will actually buy the solution if the pilot succeeds. This can be complicated in government organisations and large enterprises because the person experiencing the problem, the person evaluating the technology and the person controlling the budget may all be different people.

The operational team may desperately want the solution. The IT department may approve the technology. Engineers may love the architecture. Yet if senior management has different priorities or there is no budget allocated, none of that enthusiasm guarantees a project.

Before committing significant resources to a pilot, I would want to understand who owns the problem, who owns the budget, who makes the final decision and how procurement will happen. I would also want to know whether those people are aware of the pilot and whether they have expressed any intention to proceed if it succeeds.

The question I should have asked more often years ago was remarkably simple: Who signs the purchase order when this pilot succeeds?

If nobody can answer that question, we should recognise the risk before we begin.

Lesson Two: Define What Happens After the Pilot Before It Starts

Another lesson is that success criteria should not stop at technical measurements. We may define that a platform must connect a certain number of devices, integrate several systems, achieve a particular uptime or demonstrate certain operational functions. Those are useful measures, but they do not tell us what happens when every technical box has been ticked.

Before starting a pilot, I would now want a discussion about the commercial next step. If the agreed objectives are achieved, does the solution move into production? Will deployment expand to more locations? Will the organisation request budget? Will a commercial tender be issued? When is the decision expected to happen?

Government procurement cannot always be guaranteed in advance, and I would never expect a pilot agreement to bypass proper procurement procedures. But there should at least be a credible pathway from technical success to commercial consideration.

Without that pathway, we may spend months building a bridge without checking whether there is a road on the other side.

Lesson Three: Look for Real Commitment

I have also become more cautious about completely free pilots. Free pilots can generate interest because they reduce the customer’s risk, but that same advantage makes it difficult to measure genuine commitment. When there is little cost to participate, organisations can experiment without having to make difficult internal decisions.

The customer does not necessarily need to pay the full commercial price during a pilot. Commitment can take many forms, including staff resources, infrastructure, integration support, access to operational data, management involvement or a smaller financial contribution. What matters is that the customer also has something invested in the outcome.

When both parties have something at stake, behaviour changes. Meetings become more serious, deadlines receive more attention and internal stakeholders are more likely to remain involved.

If the technology vendor is the only party carrying significant risk, the pilot can easily become an interesting experiment rather than the beginning of a commercial relationship.

Lesson Four: Ask What Could Stop the Project Even If We Succeed

This is perhaps one of the questions founders do not ask often enough. We spend so much time thinking about how to make a pilot successful that we forget to ask what could still kill the project afterward.

There may already be another preferred platform. A larger procurement exercise may be planned. Management priorities may change. The organisation may not have budget. The project may depend heavily on one internal champion who could be transferred to another department. Existing contracts may restrict what can be purchased. A new policy could change the direction entirely.

Understanding these risks before starting does not mean being negative. It simply means understanding the environment in which the technology will eventually have to survive.

A technically successful pilot does not remove organisational, political, financial or procurement barriers. Those barriers need to be identified and managed separately.

Lesson Five: Separate Bad Luck From Bad Decisions

Perhaps the most personal lesson from these two experiences was learning to distinguish between circumstances we could not control and mistakes we could have avoided.

COVID-19 was outside our control. We could not reopen borders, restart international pilgrimage or predict exactly when travel would return. The lesson from Raqib was therefore not that we should have somehow predicted a global pandemic. The lesson was that small companies need to manage exposure to external shocks, avoid becoming overly dependent on a single market condition, and be willing to stop investing when the economics no longer make sense.

The smart city pilot was different. We had greater control over how we qualified the opportunity. We could have asked harder questions about customer commitment, budget ownership, management support and the procurement pathway before investing significant time and resources.

This distinction matters because founders should neither blame themselves for everything nor blame circumstances for everything. When something does not work, I now try to ask whether the cause was within our control. If it was, the lesson should become part of our process. If it was not, the lesson should strengthen the way we prepare for uncertainty.

Lesson Six: Design the Pilot Backwards From Commercial Deployment

If I were designing these pilots today, I would begin from the end rather than the beginning. Instead of asking, “What technology should we demonstrate?” I would first ask, “What needs to be proven for this customer to confidently move into an operational deployment?”

That small change in perspective produces a very different pilot.

If management needs evidence of cost savings, the pilot should measure those savings. If cybersecurity approval is required, security requirements should be tested during the pilot rather than discussed afterward. If interoperability is the main concern, the pilot should prove interoperability with the systems that matter. If procurement requires a business case, the pilot should collect the operational and financial evidence needed to build that case.

Every activity in the pilot should reduce one of the uncertainties preventing the customer from moving forward.

When viewed this way, a pilot is no longer just proof that the technology works. It becomes a structured process for removing the reasons a customer might hesitate to deploy it.

The Dangerous Comfort of Being Busy With Pilots

There is another uncomfortable lesson that took me longer to appreciate. Technology companies can become very busy doing pilots without actually building a sustainable business.

Pilots create activity. There are meetings, presentations, site visits, demonstrations, progress reports, launch ceremonies and photographs. Engineers are busy solving interesting problems, customers are talking about the technology, and management feels that the company is making progress. Sometimes the pilot even receives publicity, which makes everything look even more promising from the outside.

Then the pilot ends. The final report is submitted, everyone shakes hands, photographs are taken, and a few months later the system is no longer operating.

A startup cannot survive indefinitely on demonstrations, no matter how successful those demonstrations appear. At some point, somebody must value the solution enough to pay for it, operate it and continue using it.

That is why I no longer measure the success of a pilot only by whether we achieved the technical objectives. I also ask whether the pilot moved us closer to an operational deployment and a paying customer.

The Questions I Would Ask Before Accepting Another Pilot

If another organisation approaches Favoriot today and says, “Let us run a pilot,” I will still be interested. Real world testing remains extremely useful, particularly in IoT where laboratory conditions rarely represent what actually happens at a customer site. But my enthusiasm is now accompanied by many more questions.

Before committing significant resources, I would want to understand the operational problem, its seriousness, who owns it, who will use the solution, who controls the budget and who has authority to approve deployment. I would ask what success looks like, what business outcome is being measured, whether there is a budget after the pilot, how procurement could happen and what circumstances might still prevent the organisation from proceeding.

I would not expect perfect answers. Large organisations are complicated, and government projects often involve long budget and procurement cycles. What matters is whether there is a believable commercial path beyond the experiment.

The answers help me distinguish between two opportunities that can look almost identical at the beginning: a pilot designed to explore technology and a pilot designed to become an operational project.

Both have value, but they should not be confused.

Perhaps the Real Pilot Is the Business Model

Looking back at Raqib and the Favoriot smart city project, I realise that we were testing much more than technology. Without fully recognising it at the time, we were testing timing, market readiness, customer commitment, organisational priorities, procurement realities and our own assumptions about how technology moves from experimentation into daily operations.

Raqib taught me that sometimes you can build something useful and still arrive at exactly the wrong moment. The smart city pilot taught me something more uncomfortable: proving that your technology works does not prove that a commercial customer exists.

Those lessons have stayed with me.

Today, when someone suggests another pilot, the engineer inside me still becomes curious. I immediately start thinking about devices, APIs, connectivity, architecture, interoperability and what we could demonstrate. But experience has taught me to ask another question before becoming too enthusiastic:

If we succeed, what happens the morning after the pilot ends?

Will the equipment remain installed? Will the platform continue running? Will the solution become part of the organisation’s daily operations? Will somebody allocate a budget and issue a purchase order, or will everyone shake hands, take a photograph and move on to the next experiment?

After experiencing both outcomes, I no longer believe that the purpose of a pilot is simply to prove that technology works.

A good pilot proves the technology. A better pilot proves that the technology creates measurable value. The best pilot proves that a real customer is willing to keep using and paying for it after the experiment is over.

That is the difference between demonstrating technology and building a sustainable business. It took me two very different pilots to understand that difference, but it is a lesson I now carry into every new opportunity.

Have you ever completed a pilot that everyone considered successful, only to discover that the commercial project never came? What stopped it, and what would you do differently today? I would be very interested to hear your experience in the comments.

Would we listen to advice from our future selves?

If you had a time machine and could send just one message to your past self, what would it say?

An interesting question: Would we listen to advice from our future selves?

Our priorities and perspectives change as we move through different stages of life. When we are older and wiser, we may believe we have valuable lessons to offer our younger selves. Yet our younger selves, driven by courage, curiosity, and a greater appetite for risk, might not be ready to listen.

Perhaps the risks we once took and the mistakes we made were exactly what shaped the wisdom we carry today.

The Moment I Realised Our Dashboard Was Not the Answer

For many years, I believed what most of the IoT industry believed.

If organisations could connect more devices, collect more data, and build better dashboards, they would naturally make better decisions. It sounded logical. Dashboards promised visibility. They displayed colourful charts, maps, gauges, KPIs, and alerts, becoming the centrepiece of almost every digital transformation project. Customers proudly demonstrated them during project reviews, while executives appreciated having a visual summary of their operations.

But after working on numerous IoT deployments across different industries, I started noticing something that challenged this assumption.

Many organisations with sophisticated dashboards were still struggling with the same operational problems they had before deploying IoT. Equipment failures continued to occur without warning. Water leaks remained unnoticed for hours. Production lines experienced unexpected disruptions. Critical alarms were often discovered through phone calls rather than on the dashboard, and operational teams still depended on WhatsApp groups to coordinate emergency responses.

It became increasingly difficult to ignore the contradiction. If these organisations had real-time dashboards filled with operational data, why were they still reacting to problems instead of preventing them?

That question changed the way I looked at digital transformation.

Looking Beyond the Dashboard

During site visits, I repeatedly encountered the same situation. The dashboards looked healthy, but the operations did not.

One water utility displayed every pumping station across the city on a beautifully designed dashboard. Every indicator appeared green and everything seemed normal. Yet maintenance engineers continued driving from site to site because they did not fully trust the information enough to make decisions remotely.

A manufacturing company had invested heavily in production dashboards covering every major process. Even so, supervisors continued walking the factory floor every hour because they relied more on direct observation than the information displayed on their screens.

In another project, management proudly demonstrated hundreds of connected IoT sensors streaming data into the cloud. When I asked how they detected abnormal conditions before customers reported them, nobody had a clear answer.

The dashboard had become a reporting interface rather than an operational decision tool.

Asking the Wrong Question

Many digital transformation initiatives begin by asking the wrong question.

“How should our dashboard look?”

While visualisation is important, it should never be the starting point. A far better question is:

“How will operators know what needs attention, what decision should be made, and what action should happen next?”

A dashboard is only one component of that process. If the operational workflow remains fragmented, adding more charts and graphs will not solve the underlying problem.

Data Does Not Automatically Create Visibility

Perhaps the biggest lesson I learned was that collecting data is not the same as creating operational visibility.

Data becomes valuable only when it is trusted, enriched with context, correlated across multiple systems, delivered to the right people at the right time, and directly linked to operational actions. Without these elements, dashboards simply display information without helping people understand what is actually happening.

Visibility is not measured by the number of charts on a screen. It is measured by how quickly people can recognise a problem, understand its impact, and respond with confidence.

The Dashboard Illusion

This experience led me to define what I now call the Dashboard Illusion.

The Dashboard Illusion occurs when organisations believe that visualising data automatically creates operational awareness. The dashboard creates a sense of confidence because it looks comprehensive, but many important operational realities remain hidden.

Sensors may have stopped transmitting data. Information may arrive too late to support timely decisions. Critical data may still reside in isolated systems managed by different departments. Operators may receive hundreds of alerts without knowing which one deserves immediate attention.

The dashboard appears complete, yet the organisation remains partially blind to what is happening on the ground.

That is Operational Blindness.

Operators Need Answers, Not More Charts

When operations are disrupted, people rarely ask for another graph or another KPI.

Instead, they ask practical questions.

What happened?
Where did it happen?
How serious is it?
What caused it?
Who should respond?
What action should happen next?
Has the issue been resolved?

These are operational questions, not reporting questions.

Most dashboards do not answer them directly. Instead, operators must interpret multiple charts, compare different systems, call colleagues, verify information manually, and piece together the situation before making a decision. Valuable time is lost during this process.

A Different Way of Thinking

Over time, my perspective shifted.

Instead of asking how we could build a better dashboard, I began asking how we could help organisations continuously understand what was happening across their operations.

That simple shift completely changed my thinking. The objective was no longer to produce attractive dashboards. The objective became helping organisations detect abnormal conditions earlier, reduce decision delays, coordinate responses more effectively, and improve operational outcomes.

Instead of measuring success by the number of connected devices, we started measuring how quickly an organisation could recognise emerging issues. Instead of focusing on visualisation, we focused on trusted operational data, operational context, and decision support.

From IoT Platform to Operational Visibility Platform

This experience also changed the way I viewed IoT platforms.

Traditional IoT platforms are excellent at connecting devices, collecting telemetry, storing data, and presenting dashboards. Those capabilities remain essential because they provide the digital foundation for connected operations.

However, they are only the beginning.

The next stage of digital transformation requires organisations to move beyond connectivity and towards continuous operational understanding. This is the role of an Operational Visibility Platform.

Rather than simply displaying data, an Operational Visibility Platform continuously gathers, correlates, analyses, and presents information from physical assets, operational technologies, enterprise systems, and business processes. Its purpose is to help organisations understand operational reality as it unfolds, enabling faster, evidence-based decisions.

Its goal is not to produce dashboards.

Its goal is to eliminate Operational Blindness.

Connect. See. Act.

This evolution eventually became the foundation of our philosophy at Favoriot.

Connect. See. Act.

Many organisations have successfully completed the first stage by connecting their assets. Some have partially achieved the second stage by visualising operational data through dashboards.

Far fewer have mastered the final stage, where people consistently act with confidence because they possess continuous operational visibility and trusted operational intelligence.

That is where the greatest business value is created.

The Lesson

Today, whenever someone asks whether they need a better dashboard, I usually respond with a different question.

“What operational problem are you trying to solve?”

If that question cannot be answered clearly, another dashboard is unlikely to make any meaningful difference.

Dashboards remain valuable tools for monitoring KPIs, presenting trends, and communicating information. They are an important part of every operational platform, but they should never be mistaken for the destination.

The real objective is not to build dashboards that look impressive. It is to build organisations that can continuously see what is happening, understand what it means, make timely decisions, and respond with confidence.

That was the moment I realised the dashboard was never the answer.

Operational Visibility was.

Why I Started Calling It Operational Blindness

“There has to be a better way to describe what I’ve been seeing.”

For years, that thought kept returning whenever I met customers. It followed me into boardrooms, factories, utility plants, government agencies, and Smart City command centres. Every meeting seemed different on the surface, yet they all ended with a similar feeling that something important was missing.

At first, I believed the problem was technology. I thought organisations simply needed more sensors, better connectivity, or a more capable IoT platform. Later, as artificial intelligence became the latest trend, I wondered if AI would finally solve the problem that had frustrated me for years.

The more I observed, the more I realised I had been asking the wrong question. The problem was never about having more technology. It was about why organisations continued making poor operational decisions despite having so much technology around them.

The Promise That Didn’t Match Reality

When I co founded Favoriot, I genuinely believed that if organisations could connect their devices and continuously collect operational data, better decisions would naturally follow. It sounded logical because connected systems should produce better visibility, and better visibility should improve operations.

That belief shaped much of our early thinking. We focused on connecting sensors, collecting data, building dashboards, and making information available in real time. Technically, everything worked exactly as we intended.

Then I started spending more time with customers.

Everything Looked Digital

I visited factories with sophisticated production monitoring systems. I walked into utility control rooms filled with SCADA screens and large video walls. I met building operators who proudly demonstrated their Building Management Systems, while Smart City command centres showcased dashboards that displayed hundreds of live data feeds.

Everything looked impressive. From the outside, these organisations appeared highly digital, highly connected, and fully in control. If someone judged only by the technology they saw, they would probably conclude that these organisations had already solved their operational challenges.

Yet the conversations told a completely different story.

The Same Answers Everywhere

Whenever I asked simple operational questions, I kept hearing remarkably similar responses.

“We’re still investigating the root cause.”

“Nobody realised the equipment had been deteriorating.”

“The maintenance team wasn’t informed in time.”

“Operations thought Engineering was handling it.”

“We have the data, but we’ll need time to retrieve it.”

These weren’t isolated incidents. They appeared in manufacturing, water utilities, agriculture, energy, healthcare, environmental monitoring, and Smart City projects. Different industries were using different technologies, but they were all struggling with surprisingly similar operational problems.

Technology Wasn’t the Missing Piece

As an engineer, I naturally tried to solve the problem by looking at the technology. Perhaps organisations needed more sensors. Perhaps they needed more dashboards or more sophisticated analytics. When AI became widely available, I even wondered whether intelligent algorithms would finally close the gap.

But the gap remained.

The more technology organisations deployed, the more puzzled I became. Multi million ringgit projects still depended on phone calls to verify incidents. Teams still relied on WhatsApp groups during operational emergencies. Reports still arrived after problems had already caused financial losses, and managers continued making decisions using fragmented information collected from disconnected systems.

The Frustration Started Growing

There were many evenings when I drove home replaying customer conversations in my head. Why does this keep happening? Why are organisations still surprised by problems they should have detected much earlier? Why do sophisticated dashboards still fail to prevent operational failures?

Those questions stayed with me because I couldn’t find a satisfying answer. Every new customer seemed to reinforce the same pattern instead of challenging it. It became increasingly difficult to believe that another dashboard or another AI model would somehow solve the underlying issue.

Slowly, I realised that I wasn’t looking at a technology problem. I was looking at something much deeper.

It Was Never About Data

One of the biggest turning points came when I realised organisations were not suffering because they lacked data. In fact, many had more operational data than they knew how to use. Sensors, PLCs, SCADA systems, ERP platforms, and IoT solutions were already generating enormous amounts of information every second.

The problem was that data does not automatically create understanding. Thousands of sensor readings cannot explain which issue deserves immediate attention. Beautiful dashboards cannot tell people which decision will prevent tomorrow’s failure. Artificial intelligence cannot produce reliable recommendations when operational information is incomplete, delayed, or disconnected from business context.

What organisations lacked was not data.

They lacked operational visibility.

Finding the Right Words

The phrase didn’t appear during a conference or while preparing a presentation. It arrived during one of those quiet moments when years of observations finally began connecting together.

This isn’t a data problem.

This isn’t an IoT problem.

This isn’t even an AI problem.

People are making decisions without seeing the complete operational reality.

Almost immediately another thought came to mind.

They’re operationally blind.

Operational Blindness.

The moment I spoke those words, everything suddenly made sense.

Suddenly the Pattern Was Obvious

Operational Blindness explained why organisations reacted instead of anticipated. It explained why departments worked in isolation despite sharing the same objectives. It explained why dashboards could display everything in green while operational performance quietly deteriorated underneath.

I began seeing Operational Blindness everywhere. A leaking pipeline that remained unnoticed until millions of litres of treated water had been lost. A machine whose vibration gradually increased until production stopped unexpectedly. A hospital where maintenance records were scattered across disconnected systems. A commercial building where energy costs quietly increased month after month because nobody recognised abnormal patterns early enough.

Different industries. Different technologies.

Exactly the same operational condition.

It Changed How I Saw Favoriot

That realisation also changed how I described our own company.

For years, I introduced Favoriot as an IoT platform because that was technically correct. Over time, I realised customers were rarely looking for another platform. They were looking for a way to stop recurring operational surprises, reduce uncertainty, and gain confidence in their daily decisions.

Customers don’t buy dashboards simply because they look attractive. They invest because they want fewer failures, lower operating costs, better compliance, improved reliability, and stronger business outcomes. The platform is only one part of that journey.

A Bigger Mission

Today, I no longer see Favoriot simply as a company that connects devices. I see it as helping organisations reduce Operational Blindness by connecting fragmented operational data, providing meaningful context, supporting faster decisions, and enabling coordinated actions across different teams.

That mission extends beyond IoT. It applies equally to manufacturing, utilities, healthcare, agriculture, logistics, smart buildings, critical infrastructure, ESG reporting, and even cybersecurity. Wherever operational decisions depend on trusted information, Operational Blindness can exist.

As artificial intelligence becomes increasingly capable, this challenge becomes even more significant. AI cannot compensate for missing operational context, disconnected information, or delayed data. Before organisations can become AI driven, they must first become operationally aware.

More Than Just a New Phrase

Looking back, I sometimes smile at how long it took me to recognise what had been sitting in front of me all along. I thought I was building an IoT platform, but what I was really trying to solve was a much larger operational problem that existed across almost every industry.

The phrase Operational Blindness represents years of customer conversations, personal frustrations, lessons learned, and moments of clarity. It gave me a way to describe a problem that many organisations experience every day but struggle to explain.

Perhaps the most meaningful breakthroughs don’t always come from inventing new technologies. Sometimes they come from finding the right words to describe a challenge that everyone has experienced but nobody has been able to name.

Have you ever experienced Operational Blindness in your own organisation? I would love to hear your story because every experience helps us understand this challenge better, and every lesson brings us one step closer to building organisations that can truly connect, see, and act.

Stop Selling “Smart City.” Start Selling the Thing That Actually Works.

A colleague in Bangkok sent me something last month that made me stop scrolling.

He’d been reviewing procurement data across a handful of ASEAN municipalities, trying to understand why so many “smart city” line items in city budgets kept getting quietly renamed, restructured, or dropped altogether after year two. Not cancelled outright. Just… rebranded into something else. A flood monitoring project. A cold chain upgrade. A dengue alert system.

Same money. Same sensors, half the time. Different name on the invoice.

Why does that happen?

The label became the liability

Here’s the uncomfortable finding buried in that data: in the very countries where “smart city” programs have run the longest, the term itself has started to carry baggage. Mention it in a council meeting now and you get polite nods and quiet skepticism. People have seen the glossy master plans. They’ve seen the dashboards nobody looks at after the ribbon-cutting. “Smart city” has become shorthand for over-promised and under-delivered, and everyone in the room knows it, even if nobody says it out loud.

I’ve sat in enough of those rooms myself, going back to my REDtone IoT and FAVORIOT days, to recognize the exact moment a pitch loses the audience. It’s not when the tech is weak. It’s the second you say “smart city” as the category, instead of naming the actual problem you’re solving.

Compare these two openings.

“We’re deploying a smart city platform for your municipality.”

Versus:

“We’re building a system that tells you a flood is coming to Nakhon Si Thammarat 36 hours before it hits, instead of after.”

One is a category. The other is a promise you can be held to.

Nakhon Si Thammarat isn’t hypothetical

I keep coming back to Nakhon Si Thammarat because it’s not a thought experiment. That province has taken real, repeated flood losses, year after year, the kind that show up in disaster relief budgets and insurance claims long before anyone writes a case study about them. Nobody there needs convincing that flood early warning has value. The ROI narrative writes itself: fewer evacuations done blind, fewer bridges washed out with no warning, fewer farmers finding out their fields are underwater from a neighbor’s phone call instead of a sensor.

That same budget line could have been labeled “smart city resilience initiative.” Would it have moved as fast through approval? I doubt it.

Vertical, not category

This is the part I think a lot of us in the industry got backwards for years. We built the category first, dengue and flood and cold chain as features, sub-modules living inside something bigger called Smart City. It felt efficient. One platform, many use cases, one procurement conversation.

But procurement doesn’t buy platforms. Health ministries buy outbreak prevention. Disaster management agencies buy lead time. Cold chain operators buy spoilage reduction they can put a ringgit figure next to. Nobody in those rooms has a budget line called “digital transformation.” They have a budget line called “vaccine wastage,” and that number is already too high, and somebody upstairs is asking why.

Cold chain monitoring, dengue and health surveillance, flood and disaster response, environmental monitoring, these are not features of a smart city. They are the smart city, minus a label that’s stopped helping and started hurting.

The money still often sits inside a smart city budget allocation. That part hasn’t changed. What’s changed is what you say out loud in the pitch meeting.

What I tell founders now

When a founder asks me how to position an IoT solution for government or municipal buyers these days, I tell them the same thing every time: find the named domain. Not the umbrella term. The named domain.

Don’t say you do smart agriculture. Say you cut fertilizer waste for palm oil smallholders by a measurable percentage. Don’t say you enable smart healthcare. Say you cut the time between a dengue cluster forming and a health officer knowing about it, from weeks to days.

Is this just marketing, a coat of paint on the same technology? Partly, yes. But it’s also something more honest than marketing. It’s an admission that “smart city” was always too big a promise for any single vendor, any single deployment, any single budget cycle to keep. The category asked cities to imagine a transformed future. The vertical asks them to solve a problem they already have a number attached to.

I’ve watched too many pilots die waiting for the transformed future to arrive. I’d rather help ship the flood warning that works.

The question worth sitting with

If you’re building or selling IoT into government right now, ask yourself honestly: could a mayor explain what you do in one sentence, using a number, without saying the words “smart city” at all?

If the answer is no, you don’t have a weak product. You have a pitch still hiding inside a category that’s already lost the room’s trust.

I wrote a deeper technical take on this over at IoT World.

Malaysia’s IoT Market Has The Infrastructure. So Why Is Adoption Still Crawling?

Every few months a new market research report lands in my inbox with a headline number for Malaysia’s IoT market. Billions of dollars. Double-digit CAGR. Smart city spend projected to grow at 27% a year through 2034. On paper, we look like a country sprinting toward a connected future.

I have been in this industry long enough, from MIMOS to REDtone IoT to building FAVORIOT from scratch, to know the difference between a market projection and a market. The projection is what analysts model when they extrapolate 5G rollout numbers and government budget announcements. The market is what actually gets deployed, paid for, and kept running past the pilot phase. In Malaysia right now, there is a real gap between the two, and I think it is worth naming exactly where that gap comes from.

The Infrastructure Story Is Genuinely Good

Let’s give credit where it belongs first, because the connectivity layer has moved fast. 4G coverage sits above 96% of populated areas. 5G adoption crossed 52% by the end of 2024, and coverage reached over 82% of populated areas by 2025. Malaysia has more than 7,000 5G sites deployed and pulled in over RM86 billion in data center investment in 2024 alone, making the country Southeast Asia’s leading data center hub.

That is not a small achievement. A country cannot build an IoT economy without pipes to carry the data, and Malaysia’s pipes are, by regional standards, excellent. If you had told me in my MIMOS days that we would have this level of physical infrastructure by 2026, I would have been thrilled.

But infrastructure was never the constraint. Demand was.

The Roadmap We Wrote, And The Reality We Got

Go back to the National IoT Strategic Roadmap, the document MIMOS helped shape more than a decade ago. It forecast IoT applications and services reaching RM34 billion by 2025, up from RM7.5 billion in 2020. Device production was projected to hit RM4.3 billion in the same window.

Nobody in this industry seriously believes we hit those numbers. I do not say that to be cynical about the roadmap. I say it because the gap between what we projected and what materialized is the single most instructive data point in this entire market. It tells us the bottleneck was never technological capability. It was adoption discipline, and adoption discipline is a much harder problem to solve with a budget allocation.

Seven Reasons Growth Keeps Stalling

I want to walk through the actual mechanics of why, because “slow adoption” is too vague to act on. Here is what I see happening on the ground, backed by what the data confirms.

SMEs are still building the foundation IoT depends on. Malaysia’s economy runs on small and medium enterprises, and a recent survey found only about 35% of surveyed SMEs had implemented basic digital systems beyond simple accounting software. You cannot sell predictive maintenance sensors to a factory floor that has not digitized its production logs yet. IoT vendors keep pitching step five to companies that are still working through step one, and the pitch lands as noise rather than opportunity.

The payback math does not match buyer expectations. Deploying an IoT platform requires real upfront investment in hardware, software, and integration with legacy systems, and for SMEs this cost is a genuine barrier to entry even when the long-term ROI is positive. Malaysian buyers, especially in manufacturing and plantation sectors, want a return inside 12 to 18 months. Most honest business cases for connected infrastructure deliver in 24 to 36. That gap kills deals at the finance desk long before the technical evaluation even starts.

We have a talent bottleneck on both sides of the table. Adoption requires skills in IoT, data analytics, cybersecurity, and cloud computing, and Malaysia faces a real shortage of professionals who can manage these deployments end to end. This hits twice. Customers cannot maintain what they buy, and system integrators cannot scale delivery teams fast enough to take on more projects. I see this constraint directly in how far my own SI partners can stretch their capacity.

We have become excellent at pilots and mediocre at scale. I have written about this before, going back years: many organizations in Malaysia are still exploring what IoT can do rather than actually implementing it at scale. Government and GLC procurement cycles routinely stretch 12 to 24 months, and by the time a tender closes, the internal champion who pushed for the pilot has often moved to a different role. The institutional memory that would carry a pilot into a fleet-wide rollout simply evaporates.

5G hype outran 5G reality, and it dented confidence broadly. This one deserves more attention than it gets. 5G speeds actually fell 46% as user numbers scaled during 2024 and 2025, with real-world performance landing at roughly half of what marketing promised. Enterprise deployments involving sensors and remote machinery hit ceiling effects faster than expected. The irony is that most industrial IoT use cases never needed 5G in the first place. NB-IoT, LoRaWAN, and plain 4G cover the majority of real deployments. But 5G dominated the boardroom conversation for two years, and when it underdelivered, some of that disappointment bled into skepticism about connected technology in general.

Security fear has outpaced security literacy. IoT devices expand the attack surface for cybercriminals, and data privacy regulations around data ownership add another layer of complexity. Malaysia’s breach history has not helped confidence here. 2023 recorded the highest number of data breaches on record, with fifteen ransomware cases reported per week. For risk-averse government agencies and GLCs, “where does my data actually sit” has become a conversation-ending question, and few local vendors carry the certifications to answer it with authority.

Policy attention has moved on to AI, and IoT lost its dedicated spotlight. Look at where Budget 2026 puts its weight. RM53 million for the Malaysia Digital Acceleration Grant targeting blockchain, AI, and quantum computing. RM18.1 million for the National AI Office. RM2 billion earmarked for a Sovereign AI Cloud. IoT is barely named as a standalone priority anymore. Compare that to Budget 2025’s allocation of just RM15.1 million for smart city development under the Housing and Local Government Ministry, a rounding error next to the AI figures. Without a dedicated policy push, and without a compliance mandate the way India’s FASTag requirement forced RFID adoption almost overnight, Malaysian IoT adoption stays voluntary. Voluntary adoption is slow adoption by definition.

The Pattern Underneath The Pattern

Put these seven factors together and a single story emerges. Malaysia does not have a technology problem. It has a demand-side maturity problem sitting on top of a fragmented supply side. The billions poured into 5G, fiber, and data centers were supply-push investments, and they worked. The AI Nation agenda is also supply-push. What never got properly addressed is demand-pull: regulatory mandates that force adoption where voluntary uptake has failed, financing instruments that convert IoT capex into manageable opex, and system integrator capacity that can deliver at the scale procurement teams keep promising.

Where This Actually Gets Interesting

Here is the part I think most people in the industry are missing, and it is the reason I am not pessimistic about where this goes next.

AI cannot function in the physical world without sensor data. Every company now scrambling to bolt AI onto their operations is going to discover, within the next year or two, that they have nothing meaningful to feed their models. You cannot build a predictive maintenance AI without machine telemetry. You cannot build a smart agriculture AI without soil and climate sensors. You cannot build a smart building AI without occupancy and energy data. The instrumentation layer that IoT was supposed to build over the last decade is exactly the layer AI needs and mostly does not have.

Malaysia spent ten years underinvesting in that instrumentation layer relative to its own roadmap. That is the bad news. The good news is that the correction is coming, driven not by an IoT mandate but by AI ambition that will hit a wall without sensor data behind it. Companies that quietly kept building connected infrastructure through this slow period, the ones who treated IoT as the unglamorous plumbing rather than the headline act, are positioned to become the data supply chain for Malaysia’s AI Nation agenda.

That is not a consolation prize. That is the actual opportunity. The market did not fail. It just took longer to arrive at the reason it needed to exist.

Malaysia’s IoT-specific market figures vary considerably across research houses, and several published reports use templated methodology that should be treated with caution. The directional pattern across every credible source, however, is consistent: infrastructure has outpaced adoption, SMEs remain the binding constraint, and enterprise pilots are not converting to scale at the rate the roadmap assumed.

Why My Best Ideas Arrive Before Sunrise: How Early Morning Writing Became My Greatest Investment

“Why do I keep waking up before sunrise just to write?”

It is a question I have asked myself many times over the years. Nobody expects an article from me every morning. There is no publisher waiting impatiently for another manuscript, no customer demanding a fresh blog post before breakfast, and no deadline forcing me to switch on my laptop while the rest of the house is still asleep. Yet almost every morning, without needing an alarm to remind me, I find myself making a cup of coffee, settling into the same chair, and opening a blank document. Somewhere along the way, this routine stopped feeling like work. It became something I genuinely looked forward to. I realised that I was no longer writing because I needed to. I was writing because I could no longer imagine starting my day any other way.

Many people begin their mornings by checking emails, scrolling through social media, or immediately responding to messages that arrived overnight. I used to do that too. Before long, I noticed that I was allowing other people’s priorities to dictate how my day unfolded. Instead of beginning with clear thoughts, my mind was already crowded with requests, problems, and distractions before I had even given myself a chance to think. Writing changed that completely. It became my opportunity to spend the first hour of every day listening to my own thoughts before listening to everyone else’s.

What started as a simple habit gradually became one of the most valuable investments I have ever made in myself.

The Early Morning Gives Me Something the Rest of the Day Cannot

There is something remarkably different about the world before sunrise. The silence feels almost tangible. The constant stream of emails has not yet begun. WhatsApp groups remain quiet. News headlines have not started competing for attention, and the endless interruptions that define a normal working day simply do not exist. During those precious moments, the world seems to slow down just enough to allow the mind to breathe.

I have often wondered why my clearest ideas almost always appear during these early hours. I do not think it is because I suddenly become more intelligent at six o’clock in the morning. Instead, it is because my mind is still uncluttered. It has not yet been overwhelmed by meetings, urgent phone calls, customer requests, financial decisions, or the countless small issues that naturally arise when running a business. The ideas that emerge during this quiet period feel more genuine because they are not competing with dozens of other voices demanding attention.

Some mornings I begin with only a vague thought or a simple question. By the time I finish writing, that small idea has often grown into something much larger. What seemed uncertain at the beginning suddenly becomes surprisingly clear. I have learned not to wait for perfect inspiration before writing because, more often than not, inspiration appears only after I begin.

Writing Is How I Discover What I Really Think

People often imagine that writing is simply recording thoughts that already exist. My experience has been completely different. I have found that writing is not the final step in thinking. It is the thinking process itself.

Many times I start an article believing I already understand a subject. As I begin putting words onto the page, I quickly realise that some parts of my reasoning are incomplete, while others are built on assumptions that I have never questioned. Writing forces those weaknesses into the open. It refuses to allow vague ideas to hide behind complicated language or technical jargon. If I cannot explain something clearly enough for another person to understand, it usually means I have not fully understood it myself.

This is one of the reasons why writing has become such an important discipline in my life. Every article becomes a conversation with myself. As I write, I constantly challenge my own conclusions. Does this really make sense? Have I overlooked another perspective? Would a customer see this differently? Am I explaining the problem or merely describing the symptoms? Those quiet questions rarely appear during busy meetings because there is never enough time to pause and reflect.

The blank page has become one of my most honest critics. It never accepts weak arguments. It never rewards unclear thinking. Every paragraph demands that I organise my thoughts before moving to the next one. Over time, I have realised that writing has sharpened my ability to analyse problems far beyond the articles themselves. It has influenced how I approach business decisions, technology strategy, and even personal challenges.

Every Morning Is a Personal Strategy Session

As the founder of a technology company, I spend much of my day making decisions. Some decisions are relatively small, while others shape the direction of the company for years to come. Questions about product development, partnerships, customer needs, market positioning, hiring, pricing, and long-term strategy constantly compete for attention. It is very easy to become trapped in responding to whatever feels most urgent rather than focusing on what is genuinely important.

Morning writing has become my way of avoiding that trap.

Before opening my inbox or joining my first meeting, I spend time reflecting on questions that rarely receive enough attention during the working day. Rather than asking what needs to be completed today, I ask what deserves to exist five years from now. Instead of focusing only on immediate customer requests, I think about the larger problems that customers may not even realise they have yet.

Questions such as these often become the starting point of my writing:

Are we solving the right problem, or are we simply improving an outdated solution?
What assumptions have we accepted without questioning?
What have our customers been trying to tell us through their behaviour rather than their words?
Where is the industry heading, and are we preparing early enough?
Which activities create real value, and which merely keep us busy?

Many of these reflections eventually find their way into our business strategy. Some become new product features. Others shape our marketing message. Occasionally, an article written during a quiet morning evolves into an entirely new business concept. Looking back, I realise that ideas such as Operational Blindness did not suddenly appear during a brainstorming workshop. They emerged gradually through months of writing, reflecting, and connecting observations that initially seemed unrelated.

Writing Has Refined My Vision as a Leader

Leadership is often associated with speaking confidently, making difficult decisions, or inspiring people to follow a vision. While those qualities certainly matter, I have come to believe that effective leadership begins much earlier. It begins with developing the discipline to think clearly before expecting others to believe your ideas.

Writing has helped me refine not only my communication but also my vision. Every article forces me to revisit what I believe, why I believe it, and whether those beliefs still make sense in today’s environment. As industries change and technology continues to evolve, leaders cannot afford to cling to outdated assumptions simply because they once worked. Writing provides me with a structured way to revisit those assumptions regularly.

When I look back at articles I wrote several years ago, I sometimes smile because I can clearly see how much my thinking has changed. Earlier in Favoriot’s journey, I often described the company as an IoT platform provider. Today, I increasingly describe Favoriot as an Operational Visibility Platform because my understanding of the customer’s real problem has matured. We were never simply helping organisations connect devices. We were helping them see their operations more clearly so they could make better decisions.

Without years of writing, I might never have noticed that shift in perspective. The articles became milestones marking the evolution of my thinking.

My Articles Have Become My Personal Knowledge Library

One benefit of writing consistently that I never expected is the knowledge archive it has created. Whenever I prepare for a keynote speech, customer presentation, university lecture, workshop, or panel discussion, I rarely begin with a blank page. Instead, I revisit articles I have written over the years. Those articles remind me not only of what I once believed but also why I believed it at that particular point in time.

They serve as more than a collection of published ideas. They document my personal growth as an entrepreneur, engineer, educator, and technology leader. Sometimes I discover ideas that remain just as relevant today as when I first wrote them. Other times, I find conclusions that I would now challenge because experience has taught me something different.

I value both equally.

The articles that stood the test of time reinforce my convictions. The articles that no longer reflect my current thinking remind me that growth requires the humility to change our minds. Without that written record, many valuable lessons would simply fade into memory, leaving little evidence of how far my thinking has evolved.

Writing Allows Me to See Connections Others May Miss

One of the greatest gifts that writing has given me is the ability to recognise patterns across seemingly unrelated subjects. I may begin writing about manufacturing and unexpectedly discover lessons that apply equally well to healthcare, agriculture, education, or smart cities. A discussion about artificial intelligence often leads naturally into conversations about organisational culture, leadership, or decision-making. Those connections rarely appear during ordinary conversations because we are usually too focused on solving immediate problems.

Writing encourages a slower, deeper form of thinking. It creates enough distance from day-to-day activities to reveal patterns that would otherwise remain hidden. Many of the frameworks I now use, including Connect, See, Act and Operational Blindness, were not invented during formal planning sessions. They emerged because writing repeatedly forced me to look at familiar problems from different perspectives until a larger pattern finally became obvious.

The Best Meeting of Every Day

Looking at my calendar, it may seem that the most important parts of my day are the meetings with customers, partners, investors, universities, or government agencies. Those conversations certainly matter, but they are not the meeting that shapes me the most.

The most valuable meeting happens before any of those begin. It is the quiet hour I spend alone with a keyboard, an empty page, and a mind that is still free from the demands of the day.

That hour reminds me that writing is far more than producing articles for other people to read. It is where I clarify my vision, refine my strategies, challenge my assumptions, capture lessons that would otherwise disappear, and record the gradual evolution of my thinking. Every article becomes another chapter in a journey that is still unfolding.

Tomorrow morning, while much of the world is still asleep, I know exactly where I will be. Not because another blog post needs to be published, but because I have learned that the clearest ideas, the strongest strategies, and the most meaningful insights often arrive long before the first meeting of the day ever begins.

The Most Valuable Lesson I Learned Did Not Come from Success. It Came from Changing My Mind

“What if the biggest reason we stop growing is not because we do not know enough, but because we become too attached to what we already believe?”

The longer we work in an industry, the easier it becomes to confuse experience with certainty. Experience teaches us to recognise patterns, anticipate problems and make faster decisions, but it can also make us overly protective of ideas that once worked well. Over time, those ideas may become part of our identity, and questioning them can feel almost like questioning ourselves.

Some of my most meaningful breakthroughs did not happen when I discovered a new technology, attended another conference or read another business book. They happened when I finally admitted that one of my long-held beliefs no longer matched the reality in front of me. That admission was never comfortable, but it often opened the door to a clearer understanding of what customers needed, what the market valued and what my own role should become.

Changing my mind was not a sign that I had failed. It was a sign that reality had taught me something that experience alone could not.

I Once Believed the Best Technology Would Naturally Win

For many years, I believed that if we built a strong technology product, customers would eventually recognise its value. The reasoning appeared logical because good technology should solve problems, and a technically solid product should stand out in the market.

Coming from an engineering and technical background, I placed great importance on architecture, reliability, scalability, security and functionality. I believed that if we could build a platform that connected devices, stored data, supported multiple communication protocols, displayed dashboards and triggered alerts, customers would naturally understand why it mattered.

“Surely, people will see how much effort has gone into building this,” I thought to myself.

When we started Favoriot, much of our attention was placed on the IoT platform itself. We worked on device connectivity, data collection, dashboards, alerts, application programming interfaces and project management capabilities. These were necessary foundations, and without them, the platform could not function properly.

The mistake was not in building those capabilities. The mistake was assuming that the platform itself was what customers wanted to buy.

That belief slowly began to change through repeated conversations with customers, partners and system integrators. There was no single dramatic meeting where someone told me that I had misunderstood the market. Instead, reality revealed itself through small moments that appeared repeatedly.

A prospect would ask how quickly we could show a working use case. A partner would ask whether the platform could support a specific operational requirement. A customer would listen politely to a technical presentation and then ask a much simpler question.

“How will this help us detect the problem earlier?”

That question was more powerful than many technical presentations because it forced me to recognise the difference between what we had built and what the customer was trying to achieve.

Customers Rarely Wake Up Wanting an IoT Platform

A factory manager does not wake up in the morning hoping to purchase another platform. A building manager does not arrive at work thinking about MQTT connections, database architecture or cloud infrastructure. A city officer does not begin the day wishing for another dashboard to display inside a command centre.

They are thinking about problems that are already affecting their operations.

They may be worried about rising energy bills, recurring equipment failures, delayed maintenance, water leakage, public complaints, safety incidents or reports that are already overdue. Their attention is focused on the operational pressure in front of them, not on the technology category behind the solution.

This distinction may appear obvious when written down, but it took years of customer conversations for me to fully understand its importance. Customers do not usually purchase technology because they admire its architecture. They purchase it because they need a faster, clearer and more reliable way to solve a problem.

That realisation changed the way I began to see Favoriot. We were not simply offering a platform that could connect devices and display data. We were helping customers and partners shorten the distance between a problem occurring and someone taking action.

The technology remained necessary, but it could no longer be the centre of the conversation.

More Features Did Not Automatically Create More Value

Another belief I had to question was the assumption that more features would automatically make the product more valuable.

Like many technology companies, we often believed that expanding the feature list would make the platform more attractive. More functions appeared to mean more capabilities, more possible use cases and a wider market.

That logic was understandable, but customer value is not measured by the number of features shown in a brochure. It is measured by whether the product helps someone solve a problem with less confusion, delay and risk.

A platform may contain fifty features, but a customer may only need five of them to prevent a costly equipment failure. Those five features carry more practical value than the other forty-five combined.

Sometimes, adding too many features can make the conversation harder rather than easier. The presentation becomes longer, the customer becomes distracted and the real business problem disappears behind technical terminology.

It is similar to bringing an entire hardware shop to repair one leaking tap. The customer may be impressed by the number of tools, but the main concern remains very simple: when will the leak stop?

“Are we showing customers everything we have built, or are we helping them understand what they can solve?”

That question forced me to reconsider how we explained the platform and how we defined value.

Three Beliefs That Gradually Changed

Over time, my thinking shifted in three important ways.

I moved from believing that strong technology would sell itself to understanding that technology must be tied to a clear operational problem. Customers may appreciate technical quality, but they usually make decisions based on outcomes, urgency and business impact.
I moved from believing that more features would create more value to understanding that relevance matters more than quantity. A small number of capabilities that solve a painful problem can be more valuable than a long feature list that creates confusion.
I moved from believing that the IoT platform was the final product to seeing it as the foundation of a much larger solution. The platform enables devices, applications, alerts and data flows, but the real outcome is better visibility, faster response and stronger decisions.

These changes did not happen overnight. They came from listening carefully to the questions customers kept asking and noticing which parts of our explanations truly mattered to them.

The Platform Was Not the Final Product

The biggest shift came when I began to understand that Favoriot was not merely the product. It was part of a larger system that helped people solve operational problems more quickly.

The platform connects devices, receives data, stores information, presents dashboards and triggers alerts. These capabilities matter because they provide the foundation on which an application or solution can be built.

Yet the customer does not judge success by whether data successfully reached the cloud. The customer judges success by what happened after the data arrived.

Did the maintenance team receive an early warning before equipment failed?

Did the building manager detect unusual energy consumption before the monthly bill arrived?

Did the farm operator know that soil conditions had changed before crops were affected?

Did the local council receive enough warning to respond to rising flood levels?

Did management understand why an incident occurred and what action should follow?

These questions reveal the true value of the solution because they connect technology directly to operational outcomes.

The real product was not connectivity. The real product was better visibility, earlier action and greater confidence in decision-making.

This change in thinking also changed how I saw my own role. I was no longer simply explaining how an IoT platform worked. I had to help customers identify what they could not currently see, why that blind spot mattered and how trusted operational data could help them act earlier.

That was a more difficult conversation, but it was also far more meaningful.

When Data Fails to Create Operational Clarity

This shift eventually led me to think more seriously about Operational Blindness.

Years ago, many IoT discussions focused heavily on connecting devices, collecting data and building dashboards. A project was often celebrated when sensors successfully transmitted data to a platform and colourful charts appeared on a screen.

From a technical perspective, the system was alive.

Yet a connected organisation is not always an informed organisation.

Imagine a factory with thousands of sensors reporting every minute. Temperature data is arriving, vibration levels are being recorded, energy consumption is visible and production machines are connected.

On paper, the project appears successful because devices are communicating and information is being collected continuously.

In practice, the maintenance team may still discover equipment failures too late. Managers may still depend on WhatsApp messages to understand what happened during the night shift. Different departments may still keep separate spreadsheets, while executives continue waiting for weekly reports before learning that a recurring problem has been growing for several days.

The project delivered data, but it did not deliver operational clarity.

That difference changed the way I evaluated technology projects. I began to see that data alone does not remove blindness. In some cases, more data can create the appearance of visibility while leaving the organisation just as uncertain as before.

A dashboard may show that everything is green, while someone on the factory floor already knows that a machine sounds unusual. The system says normal, but experience suggests that something is wrong. Nobody acts because the information is incomplete, delayed or disconnected from its operational context.

That is Operational Blindness.

I Began Asking a Different Question

For many years, one of the most common questions in IoT was simple.

“How do we connect more devices?”

That remains a useful technical question, especially when an organisation has many isolated assets. Yet I no longer believe it should be the first question asked.

A better starting point is:

“What decision is the organisation unable to make today because it cannot see the full picture?”

That single question changes the direction of the entire discussion.

Instead of beginning with sensors, we begin with a delayed decision. Instead of beginning with dashboards, we begin with a blind spot. Instead of asking how much data can be collected, we ask which information is needed, who needs it, when they need it and what action should follow.

Consider a cold-room operator. The real problem is not that the company lacks temperature data. The problem is that a temperature change may go unnoticed for long enough to damage stored goods.

The most useful question is not whether a sensor can be installed. The better question is how early the team must be warned to prevent a loss.

Once that answer becomes clear, the device, network, platform, alert rules and reporting process can be designed around the required decision. The technology begins to serve the operation instead of forcing the operation to adapt to the technology.

Experience Can Become a Comfortable Prison

There is a strange irony in experience. It helps us make better decisions because we have seen similar situations before, but it can also trap us when we assume that tomorrow will behave like yesterday.

The beliefs that once helped us succeed may later prevent us from seeing a new reality. This becomes especially dangerous in technology and business because markets change, customer expectations shift, competitors appear and new business models emerge.

We may continue presenting the answer to a question that customers stopped asking several years ago.

“Am I defending this idea because it is still correct, or because it has been part of my identity for too long?”

That is not an easy question to ask because changing our mind can feel like admitting that our earlier view was wrong. Yet there is a clear difference between being inconsistent and being willing to learn.

Inconsistency means changing direction without a sound reason. Learning means changing direction because new evidence has revealed a better path.

That distinction matters because leaders often feel pressured to appear certain. We may worry that changing our views will weaken our credibility, but refusing to change in the face of strong evidence can be far more damaging.

Unlearning Is Often Harder Than Learning

Learning something new usually feels rewarding. We gain knowledge, understand a new concept or add another skill to our toolkit.

Unlearning is more painful because it asks us to release something familiar. It may require us to admit that a strategy we defended was incomplete, simplify a product we spent years expanding or change the story we have been telling about our own business.

For Favoriot, this shift was never about abandoning the IoT platform. The platform remains the foundation of what we do.

What changed was my understanding of its true role.

The platform helps system integrators, product builders, universities and organisations move faster. It reduces the need to build every backend component from scratch and helps teams collect real-world data, create applications and respond to operational events.

The customer outcome is not simply the use of Favoriot. The customer outcome is fewer blind spots, earlier warnings, clearer operations and better decisions.

That may appear to be a small change in wording, but it influences product design, sales conversations, training programmes, partnerships and the way success is measured.

Success Can Sometimes Confirm the Wrong Lesson

Failure often forces us to reflect because something clearly did not work. Success can be more dangerous because it may convince us that every assumption we made was correct.

A project may succeed because of timing, persistence, relationships or a particular market condition. Yet we may conclude that our entire approach was perfect, repeat it in a different environment and then wonder why the same result does not appear.

That is why some of my most valuable lessons did not come from celebrating what worked. They came from examining what no longer worked and having the courage to change my mind.

I once believed that strong technology would naturally attract customers. I now believe that strong technology must be connected to a clear operational problem.

I once believed that more features would create more value. I now believe that value comes from helping people make better decisions with less confusion and delay.

I once believed that the IoT platform was the product. I now see it as the foundation that allows people to build, deploy and improve real solutions faster.

Each of these changes began when I stopped defending an old belief long enough to consider a better one.

Experience Becomes Wisdom Only After Reflection

Experience is valuable, but experience alone does not automatically become wisdom. A person can repeat the same year of experience twenty times without learning anything new.

Wisdom appears when we examine what happened, question the assumptions behind our decisions and allow reality to correct us.

Sometimes growth does not require another course, another certification or another book. Sometimes it begins with a quieter act of honesty, when we admit that something we once believed no longer serves us.

We stop protecting the old answer and begin asking a better question.

For me, one of those better questions became:

“What decision is the organisation unable to make because it cannot see the full picture?”

That question helped me move beyond devices, dashboards and features. It helped me recognise the deeper issue hidden inside many technology projects.

It also reminded me that my own thinking could suffer from the same blindness I was describing in organisations. I could accumulate years of experience and still fail to notice that the world had changed.

That may be the most humbling lesson of all.

Progress sometimes begins with learning something new, but some of our greatest progress begins when we become willing to unlearn something old.

What belief did you once hold strongly, only to discover later that reality had taught you a different lesson? I would love to hear your experience in the comments.

Nine Years, 141 Countries: What the Favoriot Numbers Are Really Telling Us

(Article based on July 9, 2026 Favoriot Statistics)

What does it take for a platform built in a small office in Malaysia to end up with a user in Suriname, another in the Cook Islands, and one in Greenland?

The honest answer is: nobody plans for that. You plan for the first ten users. The rest is what happens when you keep showing up, year after year, and the internet does the rest.

I went back into the Favoriot user registry recently, not the pitch deck version of our story, the raw one. 10,984 registered accounts. 141 countries. Records stretching from a single Tuesday morning in March 2017 to a signup that came in at 12:50am today. It felt like the right moment to read the numbers as a story rather than a spreadsheet.

Day one was quieter than you’d think

The very first entry in the system is dated March 31, 2017, 9:36am, a demo account, ours, set up to make sure the platform actually worked before anyone else touched it. Seventeen days later, the first real user outside our own team registered. By the end of that year, Favoriot had 136 users. Nearly all of them Malaysian. Nearly all of them people we could have named from memory.

2018 wasn’t much louder: 191 new signups, still a story confined mostly to home ground. If you’d shown me that number in 2018 and asked whether this platform would one day count users on every inhabited continent, I’m not sure I would have bet on it.

Then 2019 happened

Something shifted. New signups jumped from 191 to 2,097, an eleven-fold increase in a single year, still the single biggest year of growth Favoriot has ever recorded. But the more telling number isn’t the user count. It’s the countries. Favoriot went from being registered in 6 countries to being registered in 92 countries, 86 new countries added in twelve months. That’s not a marketing campaign. That’s a platform quietly crossing borders because IoT builders were finding it, using it, and telling the next person.

That single year did more to internationalize Favoriot than the two years before it combined.

The year the world stayed home, and found us anyway

2020 tells its own story. Total new signups dropped from the 2019 peak, as you’d expect in a year when everything slowed down. But look at the mix: 38.3% of that year’s new users came from outside Malaysia, the highest international share in Favoriot’s history, before or since. When the world went indoors, remote monitoring, sensors, and connected devices stopped being a “nice to have” conversation and became the conversation. People searching for IoT platforms that year found their way to us in Brazil, in Ecuador, in Nigeria, in places we had never run a single ad.

The long, steady climb

What followed wasn’t another explosion, it was something harder to pull off: consistency. 1,825 new users in 2021. 1,411 in 2022. 1,246 in 2023. 1,105 in 2024. 1,006 in 2025. And 706 already this year, with months still to go. Nine straight years without a single one falling to zero. That’s not a viral moment. That’s a platform that keeps earning its next user the same way it earned its first, by working.

Home, and how far from home

Malaysia remains the anchor. Roughly 8 in 10 users with a known country still call Malaysia home, and that’s exactly as it should be for a platform that grew up here. But sitting alongside that anchor is a footprint that now reaches 141 countries and every populated continent:

Asia beyond our own borders accounts for over 1,200 users, led by India (365), Indonesia (244), the Philippines (141), Thailand (72), Pakistan (51), China (40), Singapore (34), Vietnam (30), and Bangladesh (29). Europe has quietly built up 260 users across 35 countries, Portugal, Germany, France, the UK, Russia, and Poland among them. The Americas contribute close to 300 users spanning 26 countries, from the United States (59) and Canada (29) down through Brazil (47), Mexico (39), Ecuador (27), and Argentina (17). Africa’s 180 users span 29 countries, Egypt, Tunisia, Kenya, Nigeria, Morocco, Algeria, and Sudan among them. And even Oceania, the smallest slice, has 33 users across 7 countries, Australia and New Zealand among them.

That’s not a company with an “international strategy” slide. That’s a platform that IoT builders in 141 countries decided, on their own, was worth signing up for.

Why this matters more than the total

It would be easy to just say “almost 11,000 users” and move on. But the number that actually matters is the 141, because it means the problem Favoriot set out to solve in Malaysia was never a Malaysian problem. It was an IoT problem, everywhere devices needed to talk to each other and someone needed to make sense of the data. Kuala Lumpur just happened to be where we started solving it first.

Nine years ago, day one looked like a single demo account and a hope that it would work. Today it looks like 10,984 people across 141 countries who decided to build something on top of what we started. If that’s not proof that a good idea built in Malaysia can travel, I’m not sure what would be.

The next chapter is still being written, one registration at a time.

Dr. Mazlan Abbas, Founder, Favoriot

Source: Favoriot platform user registry, March 2017 to July 2026 (10,984 registered accounts, 141 countries represented).

Nine Years, 141 Countries: What the Favoriot Numbers Are Really Telling Us

Why I Almost Let Malaysia’s Market Size Kill Favoriot’s Biggest Dream

The Number I Kept to Myself

For years I carried a number I never said out loud in meetings. Thirty four million. That is the size of Malaysia. It is the size of the market that raised Favoriot, fed our first customers, and forgave our first mistakes.

It was also, quietly, the size of the ceiling above my own ambition.

You knew this a long time ago. Why does it hurt to admit it only now, at fifty something, with a PhD and a company that people already respect?

Because admitting it means admitting that comfort had a cost. And I do not think anyone enjoys discovering that the very thing that kept them safe is now the thing quietly holding them back.

Through My Own Eyes

I did not start Favoriot as a young man with nothing to lose. I started it at fifty six, after MIMOS, after Celcom, after a PhD I earned while still trying to prove something to myself. I had already failed in public before Favoriot even existed. Raqib, a smartwatch, did not survive. Favorsense did not survive. Dscover did not survive.

Each failure took something from me. Confidence, mostly, and a little bit of the certainty that I knew what I was doing. But each one also handed me a single sentence I could not have written any other way: customers do not want more sensors, they want to stop feeling blind about what is already happening inside their own operations.

That sentence, operational blindness, is the only thing from those years I would not trade back.

Through the Eyes of the Team Who Stayed

I think often about the people who joined Favoriot when it was still unproven. Engineers who chose a small Malaysian platform company over safer jobs at bigger names. They did not sign up to serve one country forever. They signed up because they believed the problem we were solving was bigger than the market we were solving it in.

I imagine what it must feel like from their side, building something at 2am that works beautifully, then watching it get used mostly by customers a short drive away. Talented people do not stay motivated by small ceilings. They stay motivated by the size of the problem, not the size of the postcode.

If I have learned one thing about leadership in this company, it is that I owe them a bigger horizon than the one I have been offering.

Through the Eyes of Someone We Have Not Met Yet

Somewhere right now, in Nairobi or Riyadh or Ho Chi Minh City, there is a founder running a hardware company. Good sensors, good gateways, good relationships with customers. And somewhere in the last few months, a customer asked them a question that made them go quiet for a second: where is the dashboard, where is the alert, can we host this locally, can we put our own name on it.

I know that silence. I have lived inside it.

That founder does not know Favoriot exists yet. They do not know that eight years of our own local failures produced exactly the missing piece they need. That gap, between what they already built and what they still need, is not a sales opportunity to me. It feels more like an obligation. We found the answer to a question they are quietly struggling with, and we have been too comfortable to bring it to them.

The Lessons I Am Carrying Into This Next Chapter

Build the platform before you chase the market, not the other way round. We needed years of local mistakes before the Operational Data Platform was strong enough to stand next to anyone, anywhere.

Credibility travels further than a brand name does. Nobody overseas knew Favoriot five years ago. Some of them already know me, through papers, through talks, through the slow accumulation of trust that has nothing to do with advertising.

The partners worth having were never going to come from a cold email. They come from warm introductions and founder to founder honesty, the same honesty I wish someone had extended to me back when Favoriot was unproven and unknown.

And the hardest lesson, the one I am still learning: waiting for the home market to feel finished is not patience, it is fear wearing a more respectable name.

What I Am Choosing Now

So this is the choice in front of us. Stay where it is comfortable and let a good company quietly become a small one. Or reach for the founders, the engineers, the cities and the farms outside our borders who are living the exact problem we already know how to solve.

I am choosing the second one, not because I am certain it will work, but because the alternative, staying safe inside thirty four million people, has stopped feeling like enough of a reason to keep going.

Malaysia gave Favoriot everything it needed except the size of the dream. The world is next, and I would rather fail reaching for it than succeed quietly inside a ceiling I helped build myself.

What ceiling have you built for yourself without noticing, and what would it take for you to finally name it?

I wrote a deeper technical take on this over at IoT World .

Raqib: When We Found a Market and Then the Market Disappeared

COVID-19 Changed the Question Overnight

The Second Pilot Taught Me a More Uncomfortable Lesson

A Pilot Participant Is Not Necessarily a Customer

Government Funding Can Sometimes Hide the Real Market Signal

Technical Validation Is Only One Part of a Successful Pilot

Lesson One: Find the Buyer, Not Just the Pilot Site

Lesson Two: Define What Happens After the Pilot Before It Starts

Lesson Three: Look for Real Commitment

Lesson Four: Ask What Could Stop the Project Even If We Succeed

Lesson Five: Separate Bad Luck From Bad Decisions

Lesson Six: Design the Pilot Backwards From Commercial Deployment

The Dangerous Comfort of Being Busy With Pilots

The Questions I Would Ask Before Accepting Another Pilot

Perhaps the Real Pilot Is the Business Model

Share this:

Like this:

Share this:

Like this:

Looking Beyond the Dashboard

Asking the Wrong Question

Data Does Not Automatically Create Visibility

The Dashboard Illusion

Operators Need Answers, Not More Charts

A Different Way of Thinking

From IoT Platform to Operational Visibility Platform

Connect. See. Act.

The Lesson

Share this:

Like this:

“There has to be a better way to describe what I’ve been seeing.”

The Promise That Didn’t Match Reality

Everything Looked Digital

The Same Answers Everywhere

Technology Wasn’t the Missing Piece

The Frustration Started Growing

It Was Never About Data

Finding the Right Words

Suddenly the Pattern Was Obvious

It Changed How I Saw Favoriot

A Bigger Mission

More Than Just a New Phrase

Share this:

Like this:

The label became the liability

Nakhon Si Thammarat isn’t hypothetical

Vertical, not category

What I tell founders now

The question worth sitting with

Share this:

Like this:

The Infrastructure Story Is Genuinely Good

The Roadmap We Wrote, And The Reality We Got

Seven Reasons Growth Keeps Stalling

The Pattern Underneath The Pattern

Where This Actually Gets Interesting

Share this:

Like this:

The Early Morning Gives Me Something the Rest of the Day Cannot

Writing Is How I Discover What I Really Think

Every Morning Is a Personal Strategy Session

Writing Has Refined My Vision as a Leader

My Articles Have Become My Personal Knowledge Library

Writing Allows Me to See Connections Others May Miss

The Best Meeting of Every Day

Share this:

Like this:

I Once Believed the Best Technology Would Naturally Win

Customers Rarely Wake Up Wanting an IoT Platform

More Features Did Not Automatically Create More Value

Three Beliefs That Gradually Changed

The Platform Was Not the Final Product

When Data Fails to Create Operational Clarity

I Began Asking a Different Question

Experience Can Become a Comfortable Prison

Unlearning Is Often Harder Than Learning

Success Can Sometimes Confirm the Wrong Lesson

Experience Becomes Wisdom Only After Reflection

Share this:

Like this: