Tag: Self Improvement

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.

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.

  1. 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.
  2. 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.
  3. 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
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 .

Mastering IoT & AIoT with FAVORIOT – eBook [Download]

Mastering IoT & AIoT with FAVORIOT — Free eBook by Dr. Mazlan Abbas
Dr. Mazlan Abbas · FAVORIOT
A Field Guide for IoT & AIoT Builders

From First Sensor
to Systems That Matter.

In Mastering IoT & AIoT with Favoriot, Dr. Mazlan Abbas walks you through a ten-act journey — the same one every IoT builder lives through — from that first spark of curiosity to deployments that actually change how decisions get made.

🔥 Free download — pay what you want, starting at $0

Get Your Free Copy Now

PDF · Instant access — no experience required. Written for builders, not just engineers.

Mastering IoT & AIoT with Favoriot — book cover
The Problem

Most IoT projects never make it past the demo.

Not because the technology fails — because the thinking behind it does. This book was written to close that gap.

01

Cool demos, no outcomes

Dashboards get built, sensors get connected — and nothing downstream ever changes. Data is collected, but never acted upon.

02

The wrong starting point

Teams start with the technology instead of the decision it’s meant to inform, and the project drifts before it ever ships.

03

No practical path forward

Most resources are either too academic or too vendor-specific. What’s missing is a field-tested method to go from idea to working system.

Inside the Book

A ten-act journey, shaped by real deployments.

Told through relatable, real-world scenarios — smart vehicles, environmental monitoring, cold-chain tracking, and smart city systems — this book mirrors the actual path every IoT builder walks, following the Build-Readiness Ladder:

Cloud→ Dashboard→ Intelligence→ Decisions→ AIoT
The Starting Point

Why most IoT projects fail

Before you build anything, you’ll learn to recognize the common failure patterns that quietly derail IoT projects long before launch.

The Shift

From “cool demos” to measurable outcomes

A reframing of what success actually looks like — moving away from proof-of-concept theatre and toward systems that deliver decisions.

The Method

Idea to working system in four weeks

A practical, repeatable method focused on the part that matters most: turning raw data into decisions people can act on.

The Proof

Real scenarios across real industries

Smart vehicles, environmental monitoring, cold-chain tracking, and smart city systems show how IoT and AIoT come together in practice.

The Mindset

Why technology alone is never enough

The book’s central challenge: connecting the dots between sensors, data, people, and decisions — because dashboards don’t create value, actions do.

Who This Book Speaks To

Written for every role in the ecosystem.

Whether you’re just starting out or already delivering IoT for clients, the method holds.

St

Students

Building your first IoT project and want a real method, not just theory.

Lc

Lecturers

Shaping the next generation of IoT talent with field-tested material.

SI

System Integrators

Delivering solutions to clients and needing a sharper delivery framework.

Bz

Business Leaders

Seeking clarity on where IoT and AIoT actually create business value.

“If you’ve ever wondered what to build next — this book will show you where to begin, and how to go all the way.”

— Dr. Mazlan Abbas, Author
About the Author
Dr. Mazlan Abbas

Dr. Mazlan Abbas

Dr. Mazlan Abbas is the co-founder and CEO of FAVORIOT, a cloud-based IoT platform company with a partner network spanning Malaysia, Canada, Indonesia, the Philippines, and India. He previously served as CEO of REDtone IoT and Senior Director at MIMOS Berhad, with earlier experience at CELCOM Axiata.

He is Deputy Chairman of the Malaysia IoT Association (MIoTA) and a widely recognized voice in IoT and smart cities — a field guide written from inside the deployments, not from the sidelines.

Personal Voice Thought Leader Voice Travelog (Malay)
Limited Time · Free PDF

Stop waiting. Start building the system that turns data into decisions.

Download your free copy of Mastering IoT & AIoT with Favoriot today — no strings attached.

Get Your Free Copy Now
Questions

Before you download

Is the book really free?

Yes. It’s offered on a pay-what-you-want basis starting at $0 through Payhip — you can download it at no cost.

What format is the book in?

You’ll receive a PDF file you can read on any device, immediately after downloading.

Do I need a technical background?

No. The book is written in a clear, story-driven style for students, lecturers, system integrators, and business leaders alike — not just engineers.

What will I actually be able to do after reading it?

You’ll understand why most IoT projects stall, and you’ll have a practical method for moving from idea to a working system in four weeks — with a focus on decisions, not just dashboards.

What the Bee Gees Taught Me About Building FAVORIOT

Have you ever watched a documentary and found yourself thinking about your own life more than the story on screen?

That happened to me not long ago. I sat down one evening to watch a documentary about the Bee Gees, expecting to enjoy the music and the nostalgia. What I got instead was something I did not expect: a mirror.

The more I watched Barry, Robin, and Maurice Gibb tell their story, the more I kept seeing echoes of something closer to home. The restarts. The rejections. The moments where everything seemed to be working, then suddenly wasn’t. And through all of it, the stubborn refusal to stop.

I could not help thinking, this sounds a lot like FAVORIOT.

From Humble Beginnings

The Bee Gees did not begin as superstars. They started as three brothers performing in small venues in Australia, trying to be heard, trying to matter. There were years nobody paid much attention. There were record labels that said no. There were periods where they had to reinvent themselves completely just to survive.

I grew up listening to their music. Songs like How Deep Is Your Love, Stayin’ Alive, More Than a Woman. These weren’t just pop songs to me. They were part of a certain era, a soundtrack to a generation. But watching the documentary, I realised I had only ever seen the polished version. I had never truly appreciated the full journey that produced those songs.

FAVORIOT started in 2017. We were not backed by venture capital with deep pockets. We did not launch with fanfare or make headlines. We were a small team with a clear conviction: that IoT in Malaysia needed a proper platform, built locally, understood locally, and committed to for the long term. We believed in it even when the market was not ready to believe with us.

The Reinvention No One Talks About

One of the most striking parts of the Bee Gees story is how many times they had to change direction. They began as a pop group in the 1960s, found some success, then faded. By the early 1970s, they were largely forgotten. Then came disco. The Saturday Night Fever soundtrack happened, and suddenly they were the biggest act in the world.

But here is the part people forget: they did not just get lucky. They studied the new sound, they adapted, and they worked harder than ever to master something different from what had made them famous before.

I think about this a lot when it comes to FAVORIOT. We started with one vision of how the market would grow. Reality had other plans. We shifted our focus, refined our offering, and rebuilt parts of our approach more than once. Each time, it felt uncomfortable. Each time, I had to resist the voice that said, maybe the original plan was wrong.

The Bee Gees teach me that reinvention is not a sign of failure. It is a sign that you are paying attention.

The Years Nobody Noticed

There is a gap in the Bee Gees story that most people skip over. Between their early years and the Saturday Night Fever explosion, there were quiet years. Years of uncertainty. Years where they kept working even without certainty that anyone was watching.

Those years were not wasted. They were the foundation for everything that came later.

FAVORIOT has had its own quiet years. Years where we were building, improving, pitching, and persisting, while the noise around us belonged to other companies and other narratives. It would have been easy to interpret that silence as irrelevance.

But I kept coming back to a simple question: are we building something real? If the answer was yes, then the noise would come eventually.

I still believe that.

Three Brothers and a Shared Dream

Something else struck me watching the documentary. The Bee Gees were brothers. That bond, even when it was tested by disagreements and very human tensions, was ultimately what held the group together through decades of change.

At FAVORIOT, we are not related by blood, but there is something similar in how we operate. The founding team carries a shared belief that goes beyond a business model. We genuinely believe that IoT can transform how organisations operate in Malaysia and across the region. That belief has held us together through the difficult periods, the same way the Gibb brothers held each other together through theirs.

Shared conviction, I have learned, is more durable than shared strategy.

One Day, Stayin’ Alive Becomes Thriving

The title of the documentary I watched was simply Brothers Gibb Bee Gees & Andy Gibb Story. There is something poetic in that title when you think about the startup journey. Because building something from nothing, in a market that is still finding itself, does break you a little. Not permanently. But enough to make you question everything more than once.

What kept the Bee Gees going was not certainty. It was love for what they did. Barry Gibb, speaking about his brothers who are no longer here, talks about the music as something bigger than any of them. The work outlasts the struggle.

I think about FAVORIOT in those terms sometimes. Not as a product, not as a revenue line, but as something we are trying to leave behind. A platform that proves a Malaysian IoT company can compete, contribute, and endure.

We have not reached stardom. We are not at Saturday Night Fever yet. But I do not think the Bee Gees knew it was coming either, right up until it arrived.

What I Am Still Learning from Them

The Bee Gees stayed in harmony, even when harmony was hard. They adapted without abandoning their core. They trusted that the work would eventually speak for itself.

These are not music lessons. These are founder lessons.

FAVORIOT’s documentary is still being filmed. The ending is not written. But if the Bee Gees story teaches me anything, it is that longevity is built in the quiet years, not just the spotlight moments.

And somewhere, in an office in Malaysia, a small team is still showing up every day to build something they believe in.

Maybe that is how every great story begins.

If you are working on an IoT project and want to talk to a team that has stayed in the game long enough to understand what staying actually means, reach out to us at FAVORIOT. We would love to be part of your story.

I wrote a deeper technical take on this over at IoT World (http://iotworld.co)

What My PhD Actually Taught Me (And It Was Never Just About the Research)

People assume a PhD is about becoming an expert in a narrow field. You pick a topic, spend four years buried in it, defend your thesis, and walk away with a title in front of your name. That was how I thought about it when I started mine at Universiti Teknologi Malaysia back in 1989.

I was wrong. The research was almost the least important part.

What the PhD actually gave me, I only fully understood decades later, when I found myself building FAVORIOT from scratch. No corporate safety net. No budget approval processes. No team of fifty people to delegate to. Just a problem to solve, a market to convince, and a very steep learning curve. And somewhere in that pressure, I realised that every skill I was relying on, I had built it during those three years of doctoral work.

You Learn to Think, Not Just to Know

The biggest myth about a PhD is that it fills your head with knowledge. It does, but that is not the point. What it really trains is how you think. How to slow down when a problem looks unsolvable. How to question your own assumptions before anyone else does. How to look at a complex situation and break it into parts that can actually be examined.

Running a startup constantly throws you into situations where there is no clear answer. The market changes. A technology assumption turns out to be wrong. A partnership you counted on falls through. Most people freeze or react. The PhD habit of structured thinking means I almost always go back to basics: what do I actually know, what am I assuming, and what do I need to find out?

That thinking discipline has saved me more times than any specific technical knowledge I carry.

Working Alone Without Falling Apart

A PhD is a deeply solitary journey. Your supervisor guides you, but the work is yours. The thinking is yours. The doubt is yours. Nobody is going to sit with you at two in the morning when you cannot make sense of your own data.

Entrepreneurship feels exactly the same way in the early years. You make decisions that nobody else fully understands. You carry uncertainty that you cannot always share with your team because you are supposed to be the steady one. You have to be comfortable with ambiguity without becoming paralysed by it.

The PhD taught me how to keep working when I had no external validation. It taught me that the absence of certainty is not a reason to stop. You form a hypothesis, you test it, you adjust, and you keep going. That is the startup loop. That is also the research loop.

Finding Knowledge Instead of Waiting for It

Before the PhD, I consumed knowledge the way most students do: someone put it in front of me, and I absorbed it. The PhD changed that completely. You quickly discover that nobody is going to hand you what you need. You have to hunt for it. You learn to search literature strategically, to identify which sources actually matter, to read critically instead of passively.

At FAVORIOT, we operate in a field that moves fast. IoT, AIoT, edge computing, platform architecture, developer ecosystems. The landscape shifts every eighteen months. If I waited for someone to teach me what I needed to know, I would always be behind. The PhD habit of self-directed learning means I am always reading, always synthesising, always asking what the current evidence actually says rather than what the conventional wisdom assumes.

Making the Complicated Simple

The viva examination is the moment every doctoral candidate dreads. You stand in front of a panel of experts and defend work that you have spent years on. They will probe every weakness. They will ask you to justify every assumption. And they will not accept jargon as a substitute for understanding.

To survive a viva, you have to be able to explain your work clearly. Not just to people who already know the field, but to people who are testing whether you truly understand it, or whether you are hiding behind technical language.

That skill matters enormously in a startup context. I cannot afford to lose a potential customer, partner, or investor because I explained our platform in terms only an IoT engineer would recognise. I have to be able to take a genuinely complex system and present it in a way that is meaningful to a city mayor, a business owner, or a university faculty head. The PhD forced me to develop that translation ability.

Defending What You Believe Without Being Defensive

There is a particular kind of confidence that the PhD builds. Not arrogance, which is brittle. A well-grounded, evidence-based confidence that allows you to say: I believe this is right, and here is why. And then to genuinely listen to the counterargument rather than dismissing it.

In business, this matters in negotiation, in pitching, in product decisions, and in those moments when someone more powerful than you tells you that your idea will not work. The PhD trains you to distinguish between a challenge that reveals a real weakness and a challenge that is simply pressure. You learn to stand your ground when the evidence supports you, and to revise when it does not.

Evaluating Other People’s Work Without Ego

A less obvious skill the PhD builds is the ability to critically evaluate the work of others. Peer review, literature critique, comparative analysis of methodologies. You develop a framework for assessing quality, identifying gaps, and recognising when something looks impressive but is actually incomplete.

This translates directly into how I evaluate technology vendors, potential partners, and market claims. The IoT industry is full of noise. Announcements that overstate capability. Case studies that obscure the real cost. Research that is funded to reach a particular conclusion. The critical evaluation skills from doctoral training mean I read all of it with appropriate scepticism, and I draw my own conclusions.

The Scroll Was Never the Point

I do not display my PhD certificate in my office. Not because I am not proud of it, but because I stopped thinking of it as the output a long time ago. The output is how I think, how I work, how I handle uncertainty, and how I communicate. Those are the things the doctorate actually produced.

If you are a PhD holder wondering whether the years were worth it beyond the academic world, I would say this: you were trained for exactly the kind of work that startups and leadership roles demand. The certificate opened some doors, yes. But the habits it built have kept me going long after the doors were open.

So the real question is not whether your PhD is relevant to business. The question is whether you have recognised and applied everything it actually gave you.

The Moment I Realised Something Was Broken Why IoT Projects Fail to Scale, and What Nobody Wants to Admit

A few years ago, I walked into a facility that had spent close to a million ringgit on an IoT deployment. Sensors were installed. A dashboard was running. The operations manager proudly pulled up a screen showing hundreds of data points flowing in, live, in real time.

I asked him one question: “What decision did you make yesterday based on this data?”

He paused. He looked at the screen. He called a colleague over. A few minutes passed.

“Let me check the system,” he finally said.

That pause told me everything. The IoT project was not broken in the way most people imagine broken things to be. The sensors worked. The connectivity was stable. The platform was live. But something deeper had failed, and it had failed quietly, in a way that nobody in the room had named yet.

That was the moment I realised the industry had a serious problem. Not a technology problem. A thinking problem.

We Built the Infrastructure. We Forgot the Purpose.

When I look back at two decades of IoT work, across MIMOS, through my time at REDtone IoT, and now building FAVORIOT, the pattern I keep seeing is the same one. Organisations invest in sensors, platforms, and dashboards. They point to these things as proof of digital transformation. And then they wait for the results to come.

The results rarely come. Not because the technology failed, but because nobody asked the hard question before deployment: what decision are we trying to make faster?

The sensor was never the goal. The data was never the goal. The goal was always a better decision, made quicker, based on something real. But somehow, between the vendor pitch and the project sign-off and the go-live celebration, that goal got buried under the excitement of the technology itself.

I have seen this across manufacturing plants, utility companies, logistics operations, and smart city deployments. The pattern is consistent. The language around it is always optimistic. “We now have full visibility.” “We have a live dashboard.” “We are data-driven now.”

But ask the operations team what decision they made differently last Tuesday because of that dashboard, and the room goes quiet.

I Started Calling It Operational Blindness

Recently, I wrote a more technical definition of this condition for IoT World. I called it Operational Blindness. The full definition is this: it is the condition where an organisation invests in IoT infrastructure, collects operational data at scale, yet still cannot make confident, timely decisions because the data never closes the loop to action.

The organisation sees numbers. It does not see clearly.

This is not a criticism of the people involved. The engineers built what they were asked to build. The analysts produced their reports. The executives attended the strategy sessions. Everyone did their job. But the system, as a whole, was never designed to produce decisions. It was designed to produce data. And data without a decision is just noise dressed up in a dashboard.

When I started naming this condition clearly, something interesting happened. People began recognising it in their own organisations. System integrators told me they had seen this in nearly every project they had ever delivered. Operations managers said they had felt it for years but had no language for it. That recognition mattered to me, because you cannot fix what you refuse to name.

Why IoT Projects Stop Scaling

The question I get asked most often is: why do IoT pilots succeed but never scale?

The answer, in my experience, comes back to the same broken loop every time.

A pilot project works because it is small, focused, and closely watched. Someone with authority and curiosity is paying attention. Decisions get made. Results are visible. Everyone celebrates and writes a press release.

Then comes the scale-up. More sensors, more sites, more data, more dashboards. And suddenly the thing that made the pilot work, which was a human being with a clear question and the authority to act on the answer, gets diluted across a larger organisation with competing priorities, legacy processes, and departments that were never part of the original pilot conversation.

The data multiplies. The decision-making does not.

By the time the system is running at scale, there are alerts nobody reads, dashboards nobody opens, and reports that go straight from the inbox to the archive folder. The operations team, who were not involved in designing the IoT system, have learned to work around it rather than with it. They trust their own experience more than a dashboard they did not ask for.

This is not stubbornness. This is rational behaviour when you design a system without designing it around the people who are supposed to use it.

The Three Things That Actually Need to Change

After watching this pattern repeat itself across too many projects, I have settled on three things that genuinely move the needle.

The first is contextualisation. Raw data is not insight. A temperature reading means nothing unless it is translated into operational language. Not “82 degrees Celsius.” But “Motor 4B has been running above its safe operating threshold for 40 minutes and failure is likely within six hours.” Context converts measurement into meaning. Without it, the dashboard is just wallpaper.

The second is integration into workflow. The insight has to reach the right person through the channel they already use, at the moment they can act on it. Not a report that lands at 9am about something that happened at 2am. Not a dashboard on a screen in a control room that the relevant decision-maker never visits. The signal has to travel to where the decision actually gets made.

The third is closing the loop. The system needs to know whether action was taken, what action, and what the outcome was. Without that feedback loop, the organisation cannot learn from its data. It cannot improve. It cannot measure whether the IoT investment is working. The loop has to close: from sensor to decision to outcome and back.

These are not exotic ideas. But they are consistently absent in organisations that are spending heavily on IoT and wondering why the ROI never materialises.

What I Tell Every Organisation That Comes to Me

When organisations approach FAVORIOT, one of the first things I ask is: what decision do you want to make better, and who in your organisation makes that decision today?

If they cannot answer that question, the deployment is not ready. Not because the technology is not ready. The technology is almost always ready. But the organisation is not yet clear on what it is trying to do with what the technology reveals.

That clarity is everything. It is the difference between a sensor deployment that scales and one that stays a pilot forever. It is the difference between a dashboard that changes operations and one that gets opened once a month during the management review.

We built FAVORIOT precisely because we kept seeing this gap in the market. Not a platform gap. A gap between what the data says and what the organisation decides to do about it. That is the gap we are working to close.

The Real Failure Mode

The IoT industry has spent years convincing organisations that more sensors, more data, and more dashboards are the path to operational excellence. They are not. They are the beginning of the path. What lies between that beginning and actual operational excellence is the hard work of turning data into decisions, and decisions into habits, and habits into results.

Most IoT projects fail to scale not because the technology lets them down, but because nobody built a bridge between the technology and the way the organisation actually makes decisions. The bridge is not a software feature. It is an organisational design question. And it is one that the IoT industry has, for too long, left for somebody else to answer.

If you are running an IoT deployment right now and it is not producing the results you expected, I would encourage you to ask one question before you spend another ringgit on more sensors or a better platform. Ask: what decision am I trying to make, and is my current system designed to help me make it?

The answer to that question will tell you more than any dashboard ever will.

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