Tag: Favoriot

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

Why IoT Pilots Don’t Scale And Who’s Really to Blame

Everyone celebrates a successful IoT pilot. Nobody talks about what happens six months later. Here is an honest look at why IoT pilots fail to scale, and what both vendors and organisations need to do differently.

Everyone celebrates a successful IoT pilot. Nobody talks about what happens six months later.

I have been in this industry long enough to see the pattern repeat itself more times than I care to count. The pilot runs well. The demo impresses the right people. The case study gets written. And then, quietly, the project stalls. The vendor stops getting replies. The internal champion gets moved to another role. The budget for the next phase never quite materialises. Eventually, everyone agrees to revisit it next year, and next year never comes.

This is not a rare failure. It is, in many ways, the default outcome for IoT pilots. And I think it is worth being honest about why.

Pilots Are Designed to Win, Not to Grow

When a vendor runs an IoT pilot, the primary goal is to prove the technology works. Can the sensors communicate reliably? Can the data reach the cloud? Can the dashboard tell a compelling story? These are the questions that get asked, and they are the questions that pilots are built to answer.

What almost never gets asked at the pilot stage is this: what will it actually take to run this at ten times the scale, across three different departments, with an operations team that had no involvement in the original project?

That question feels premature when everyone is still excited about the demo. But it is the question that determines whether a pilot ever becomes infrastructure.

I went through this at FAVORIOT in our earlier years. We were focused on showing what the technology could do, and we were good at it. The pilots looked great. The clients were satisfied. And then the scaling conversation would arrive, and suddenly the gaps that were invisible at pilot scale became very visible. We had not asked the hard questions early enough, and neither had our clients.

The Organisation That Was Not Ready

I want to be fair here, because this is not only a vendor problem.

Many organisations that commission IoT pilots are not genuinely ready to scale the outcome, even when the pilot succeeds technically. They have not decided who will own the system once it moves from pilot to operations. They have not resolved the internal politics between the IT department, the operational team, and the business unit that originated the idea. They have not secured a realistic budget for scaling, only for testing.

Scaling IoT is not primarily a technology challenge. It is an organisational one. It requires data governance policies that most organisations have not written. It requires integration with legacy systems that were never designed to communicate with modern IoT platforms. It requires someone inside the organisation who understands the technology well enough to advocate for it internally, troubleshoot it practically, and keep it alive through the natural turbulence of business priorities shifting.

That person, the internal champion who bridges technology and organisational reality, is often absent at the start. And no pilot result, however impressive, can substitute for what that person provides.

Looking back at the IoT deployments I have seen actually scale, that champion is almost always present. They pushed for budget when enthusiasm faded. They translated technical requirements into business language. They trained colleagues who were sceptical or confused. Without that internal force, a successful pilot becomes a beautiful proof-of-concept that everyone agrees was interesting but no one quite knows how to build on.

The Vendor’s Honest Share

I am a vendor. I run an IoT platform company. So I say this knowing it applies to me.

The commercial pressure on IoT vendors is to win the pilot. The incentives are structured around closing deals, not around ensuring clients succeed eighteen months after the handover. Sales teams make promises during the pitch that reflect best-case conditions. The pilot is then designed around those best-case conditions. When the client tries to scale into their actual messy environment, with their legacy systems, their budget constraints, and their internal disagreements, the gap between what was promised and what is possible becomes apparent.

Beyond the sales process, there is a deeper structural problem. Many IoT vendors invest heavily in customer acquisition and very little in customer success. Helping a client scale is slower, more complex, and less commercially visible than winning the next pilot. The skills required are different too. You need to understand the client’s internal culture, their risk tolerance, their pace of decision-making. Most vendor organisations are not built for that kind of long-term partnership.

What Scaling Actually Needs

If you have just completed a successful IoT pilot and you are serious about scaling it, here is where I would start.

Ask the governance questions before the growth questions. Who owns this system? Who has access to the data, and under what conditions? Who is responsible for maintaining it when the original project team moves on? These conversations feel administrative, but they are what determine whether the investment survives contact with the organisation over time.

Make sure the technology was chosen with operations in mind, not just with the demo in mind. A highly customised pilot solution that runs beautifully in a controlled environment can become extremely difficult to hand over to an operations team that was not involved in building it. Standardisation, supportability, and documentation matter far more at scale than they do at proof-of-concept.

Build internal capability alongside vendor engagement. The organisations that scale IoT well treat adoption as a learning process, not just a procurement process. They develop expertise inside the team. They make sure the knowledge does not leave when the vendor’s project engagement ends.

And if you are a vendor reading this, I would gently suggest reexamining what success actually means for your business. If your client’s pilot succeeds but their deployment never scales, did you really deliver value? The answer is uncomfortable, but it is worth sitting with.

The Blame Is Shared, and So Is the Solution

The reason IoT pilots fail to scale is rarely a single failure. It is usually a combination of technology choices made under pressure, organisational readiness that was overstated, vendor promises that outran execution capacity, and a structural mismatch between how pilots are designed and what scaling genuinely demands.

That is both a frustrating and a hopeful conclusion. Frustrating because there is no single villain to point at. Hopeful because it means there are multiple places where both sides can make better decisions.

I have seen IoT deployments that started small and grew into something that genuinely changed how an organisation operates. Those projects did not succeed because the technology was exceptional. They succeeded because both sides were honest about the challenges, patient with the timeline, and committed to the outcome long after the first demo had faded from memory.

So here is the question I want to leave with you: if you have been through an IoT pilot that succeeded technically but never scaled, what was the one thing you wish both sides had discussed more honestly at the very beginning?

If you’re working through this challenge right now, I’d also point you to what we’ve been building at Favoriot — specifically around helping organisations move from pilot to operational deployment without rebuilding from scratch.

Why Seeing Your Brand Once Is Never Enough: The Science Behind the B2B Buying Decision

In B2B technology marketing, posting once and hoping for conversion is one of the most common and costly mistakes. The Rule of 7 is just the starting point. For IoT platforms, AIoT training, and smart city solutions, the real buying journey demands 12 to 20 meaningful touchpoints before serious action begins.

How many times does a potential customer need to encounter your brand before they are ready to act?

Most marketers have heard of the Rule of 7, the long-standing principle that a buyer needs at least seven brand exposures before taking action. The University of Maryland traces this back to early advertising research, and while the number has been cited across decades of marketing literature, the principle itself has never been more relevant than it is today. In fact, for B2B technology companies selling complex solutions such as IoT platforms, AIoT training, smart city systems, or system integrator services, seven may not even be close to enough.

The Rule of 7 Is a Starting Point, Not a Ceiling

The original Rule of 7 was conceived in a world where buyers had far fewer choices and far fewer distractions. Today, a prospective customer is bombarded with hundreds of brand messages daily across social media, email, search, video, and messaging apps. Cutting through that noise requires more than a single touchpoint or even a handful.

A more practical and realistic framework looks like this. For low-cost, low-risk consumer products where the customer already understands the need, three to five exposures may be sufficient. For B2B software, IoT platforms, training programs, and consulting services where trust must be established before any commitment is made, seven to twelve exposures is a more reasonable expectation. For high-value, technical, government, enterprise, or long sales-cycle decisions, the number often climbs beyond fifteen.

The buyer in a B2B context is rarely a single person making a spontaneous decision. There are budget holders, technical evaluators, procurement officers, and end users, each requiring their own reassurance at their own pace.

The Buying Journey Is No Longer a Straight Line

Google’s research into the modern customer journey confirms what many sales teams already suspect: the path from first awareness to final purchase is not linear. Buyers today move fluidly between searching, scrolling, streaming, and comparing. They might encounter a LinkedIn post on a Monday, watch a product demonstration video on a Wednesday, read a case study on a Friday, and then not think about it again for three weeks, until a colleague mentions the same solution.

This fragmented, non-linear journey means that brand presence must be consistent, varied, and sustained. A company that posts once and then goes quiet is invisible in the decision-making process.

The real question to ask is not simply how many times a buyer must see the brand. The more important question is whether they are seeing the right message at the right stage of their journey.

Mapping Exposures to the Buyer’s State of Mind

For a company like Favoriot, which operates in the IoT and AIoT space and targets enterprise clients, government agencies, and system integrators, the exposure journey can be mapped across three distinct stages.

At the awareness stage, five to seven exposures serve to establish name recognition. The buyer begins to register that Favoriot exists and that it is active in the space they care about. They are not yet evaluating, but they are noticing.

At the trust-building stage, eight to twelve exposures shift the conversation from recognition to understanding. The buyer starts to grasp what Favoriot actually does, why it matters, and how it differs from alternatives. This is where thought leadership content, technical deep-dives, and customer stories begin to do their heaviest lifting.

At the purchase confidence stage, twelve to twenty meaningful exposures bring the buyer to a point where they are ready to initiate contact, request pricing, attend a training session, or discuss a potential project. This is not a passive audience anymore. They have been quietly building a case internally, and now they are ready to move.

Repetition with Variation Is the Real Strategy

The mistake many technology companies make is treating content as a one-time announcement rather than an ongoing conversation. They publish a product update, send one email campaign, and then wait for the pipeline to fill. When nothing happens, the conclusion is often that the market is not ready, when the real issue is that the message has not been delivered enough times or in enough forms.

The approach that works is repetition with variation. The core message stays consistent, but the angle changes with each touchpoint. One week it is a problem statement framed around a real challenge facing a city or an enterprise. The next week it is a customer story showing how a specific outcome was achieved. Then comes a webinar invitation, followed by a demonstration video, a data sheet, a LinkedIn article, a referral from a trusted partner, and eventually a direct proposal.

Each of these formats reaches a different segment of the buyer’s brain at a different moment in the journey. The cumulative effect is what transforms a vague sense of familiarity into a genuine willingness to engage.

Building a Brand That Earns the Right to Be Remembered

For any B2B technology company competing in a space where contracts take months and stakeholders number in the double digits, the discipline of sustained, multi-channel presence is not optional. It is the entire game.

The practical target for companies in this space is a minimum of seven meaningful touchpoints, with a realistic planning horizon of twelve to twenty before serious buying conversations begin. That means building a content calendar that spans LinkedIn posts, email sequences, webinar series, case study libraries, video demonstrations, partner referrals, and direct outreach, all carrying the same core message from a different direction.

The goal is to move the buyer from “I think I have seen that name before” all the way to “I think we should set up a meeting with them.”

How many touchpoints has your company planned for this quarter, and are they designed to move buyers forward or simply to fill a content calendar?

This article draws on principles from Favoriot’s market strategy for IoT and AIoT adoption in B2B and enterprise environments. Favoriot provides IoT platforms, AIoT training, and smart city solutions for system integrators, enterprises, and government agencies across Southeast Asia.

Why I Want More Malaysian Students to Brag About Their Projects

Malaysian students build impressive projects but rarely share them publicly. Here is why that needs to change, and what students, lecturers, and institutions can do about it.

Have you ever built something and then kept it to yourself?

I have seen this happen too many times, and it bothers me more than I probably let on. A student spends weeks getting an IoT sensor to talk to a cloud platform, wires everything up, writes the code, stays up late debugging, and then… nothing. They submit the assignment, get their marks, and move on. Nobody outside that classroom ever knows the project existed.

That project deserved better. And honestly, so did the student.

The Culture of Hiding Our Work

I think we have a cultural habit in Malaysia of downplaying what we build. We are taught, from a young age, that showing off is rude. That humility means staying quiet. That if your work is good, people will somehow find out on their own.

But in the world we are living in today, that thinking is holding our students back.

I recently wrote about how some students in Malaysia are still learning IoT using Blynk, ThingSpeak or Favoriot, platforms that have genuinely served the community well over the years. My concern was not with the tools themselves, it was with the possibility that some students might complete their programmes without being exposed to more current, industry-relevant environments. The response to that piece was warm and it opened a much bigger conversation I want to continue here.

Because there is a second problem, and it sits right next to the tools issue. Even when students build something impressive, they rarely tell the world about it.

What “Bragging” Really Means

I want to be careful with my word choice here, because when I say I want Malaysian students to brag, I do not mean arrogance. I mean documentation. I mean visibility. I mean the courage to say, “I built this, and here is how I did it.”

In the global tech community, sharing your work is not showing off. It is how you contribute. It is how you invite feedback, attract collaborators, and build a reputation before you even graduate. Every time a developer writes a blog post about what they learned building a project, every time a student posts a short video demo on LinkedIn or YouTube, every time someone publishes their code on GitHub with a clear README, they are adding value to the community.

They are also building something that a CV alone cannot carry: a visible portfolio of thinking.

I Have Seen What Happens When Students Share

When students do step forward and share their work, remarkable things happen. I have seen students connect with mentors because someone stumbled across their blog. I have seen project ideas get picked up by companies that were looking for exactly that kind of solution. I have seen young engineers get job offers because a hiring manager found their GitHub repository.

And I have seen something perhaps more important: the student’s own confidence change. When you write about your project publicly, you are forced to explain it clearly. You start to understand what you actually built. You start to see what worked and, more importantly, what did not. That reflection is part of the learning that never shows up in an exam.

The Platforms Are Already There

There is no shortage of places where Malaysian students can share their work. LinkedIn is the obvious starting point, and yet I still see so many profiles with nothing more than a degree listing and a generic summary. Imagine if every final year IoT project at a Malaysian university had a proper LinkedIn post, with photos, a short explanation of the problem it solved, and the tech stack used.

GitHub is equally powerful. A well-documented repository says more about an engineer’s capability than almost anything else. Medium or WordPress and personal blogs remain excellent homes for longer technical write-ups. YouTube or TikTok are perfect for demo videos. Even short-form platforms have an audience hungry for genuine student work.

The tools to publish are free. The audiences are there. What is missing is the habit and the encouragement.

What Lecturers and Institutions Can Do

I want to be fair here: this is not entirely on the students. If we want a culture shift, we need to start from inside the institutions.

Imagine if project documentation and public sharing were built into assessment rubrics. Imagine if a student was graded not only on whether the sensor collected data correctly but also on whether they could explain the project clearly to a non-technical audience. Imagine if universities celebrated student projects the way they celebrate sports achievements.

Some institutions are already doing this, and I applaud them. But it needs to be more systematic. Students should graduate not just with technical skills but with the confidence and habit of communicating those skills to the world.

A Personal Challenge

If you are a student reading this, I want you to do one thing this week. Pick a project you are working on or have completed. Write about it somewhere public. It does not have to be perfect. It does not have to be long. Just write honestly about what you were trying to solve, what you used to solve it, and what you learned in the process.

That one post could be the start of something you cannot predict yet.

If you are a lecturer or a programme coordinator, think about how you can make sharing a formal part of the learning journey. Not as a burden, but as a skill that students will use for the rest of their careers.

Malaysia has genuinely talented engineering students. I have met many of them, worked alongside some of them, and been impressed by what they can build when given the space to do it. My concern is that too much of that talent is invisible to the industry because no one taught them that visibility is part of the job.

So tell me, if you could make one change to how Malaysian engineering education celebrates student work, what would it be?

Which IoT Platform Is Best for Students?

Every semester, I meet students who proudly show me their IoT projects. Some build smart dustbins. Some build flood monitoring prototypes. Some build temperature monitoring systems for cold-chain delivery. Some build smart parking models using cardboard, wires, sensors, and a lot of hope.

I always enjoy those moments because they remind me of why technology education is so powerful. There is something special about watching a student connect a sensor, upload data to the cloud, and suddenly realise, “Eh, I can actually build something useful.”

But there is one question I always ask.

“What IoT platform are you using?”

Most of the time, the answers are almost the same.

Blynk.

ThingSpeak.

Sometimes Firebase.

Sometimes a custom dashboard built in a hurry the night before presentation day.

I smile. Not because those platforms are wrong. They are not. In fact, they have helped many students start their IoT projects. But I also feel a small discomfort because the question is bigger than the platform name.

Is the student learning IoT as a complete system, or only learning how to make a project look alive for demo day?

That is where the real conversation begins.

For universities, choosing the right IoT platform is not only about which platform is free, popular, or easy to connect with Arduino. It is about what kind of graduates we want to produce. Do we want students who can display sensor readings on a graph, or do we want students who understand how real IoT systems collect data, manage devices, trigger alerts, support decisions, and grow beyond the classroom?

That is why the question “Which IoT platform is best for students?” deserves a practical answer.

Easy Is Good, But Too Easy Can Become a Trap

Let me say this carefully. Easy platforms are helpful, especially for beginners. When students are just starting, they need confidence. They need to see results quickly. If the first IoT experience becomes too painful, they may give up before they even understand the power of connected devices.

No lecturer wants to spend three weeks helping students debug Wi-Fi passwords, missing libraries, wrong ports, incorrect tokens, and mysterious error messages that seem to appear only at 2 a.m.

So yes, an easy learning curve matters.

But I also believe that if the platform only teaches the easiest path, students may never understand the deeper structure of IoT. They may know how to connect a sensor, but they may not know what happens after the data arrives in the cloud.

A proper IoT learning experience should expose students to the full flow of an IoT system:

  1. Device connectivity
  2. Data upload
  3. Data storage
  4. Dashboard design
  5. Alerts and rules
  6. APIs
  7. User access
  8. Security awareness
  9. Analytics
  10. Real-world use cases

When I look at student projects, I do not only look at whether the sensor works. I look at whether the student understands the purpose of the data.

What will you do with this data?

Who needs to see it?

When should the system alert someone?

Can this project survive outside the lab?

That is where many student projects become weak. They are good prototypes, but they are not always ready to become useful solutions.

“Students should not learn IoT only to pass a subject. They should learn IoT to solve problems they can see, touch, and understand.”
Dr. Mazlan Abbas

The Five Things Universities Should Look For

If a university wants to choose an IoT platform for students, I suggest looking at five practical areas. These are not complicated criteria, but they can make a big difference in how students learn and how lecturers teach.

1. Learning Curve

Students need a platform that does not frighten them on the first day. A student-friendly IoT platform must allow them to connect common devices such as ESP32, ESP8266, Arduino, Raspberry Pi, or industrial gateways without needing months of technical preparation.

The learning curve should be gentle at the beginning, but it should not remain too shallow forever. Students should be able to start with basic data upload, then gradually move into dashboards, APIs, alerts, analytics, and deployment thinking.

This is one reason platforms like Blynk and ThingSpeak became popular. They are easy to start. Tutorials are everywhere. Many students can follow YouTube videos and get something working within a few hours.

That is useful, especially for first exposure.

But universities should ask a second question.

After students learn the basics, where do they go next?

If the platform becomes too limited after the first prototype, students may hit a ceiling. They may know how to make a nice demo, but they may not learn how to design a proper IoT system.

For universities, the best platform should support both beginner learning and advanced learning. It should help students start simple, then grow deeper.

2. Project Readiness

A final year project should not feel like a toy. I know that sounds a bit harsh, but I have seen many projects where the idea is strong, yet the platform choice makes the project look small.

Imagine a student builds a flood monitoring system. The sensors work. The dashboard shows water levels. The graph looks nice. Then I ask a few practical questions.

Can the system alert the local council?

Can it support multiple locations?

Can it store historical data?

Can another user log in and monitor only one area?

Can the system be expanded into a city-level monitoring system?

Usually, the student pauses.

That pause tells me something. The student was taught how to connect devices, but not always how to think about real deployment.

A good IoT platform for students must help them move from prototype to project readiness. It should support features that resemble real-world IoT systems, not just simple charts.

These include:

  1. Multiple devices
  2. Multiple data streams
  3. User access control
  4. Event-based alerts
  5. API connectivity
  6. Data history
  7. Dashboard sharing
  8. Application-level use cases

This is where I see strong value in FAVORIOT for universities. FAVORIOT is not only a place for students to test sensors. It can help them build use cases that look closer to industry needs.

A student building a smart agriculture project should not stop at soil moisture graphs. The project should show irrigation alerts, crop condition trends, farm dashboards, and possible decisions.

A student building a smart building project should not stop at temperature and humidity readings. The project should show comfort levels, abnormal readings, equipment behaviour, and suggested actions.

That is real learning.

3. Local Support

This is the part many universities forget.

When a platform is based overseas, the tutorials may be good, but the support is usually generic. If a student faces a problem, they search forums, Reddit, YouTube, GitHub, or old blog posts. Sometimes they find the answer. Sometimes they get trapped in a maze of outdated libraries, broken links, and comments from 2017.

I have seen students spend days trying to fix small issues that could have been solved quickly with proper local guidance.

This is where local support becomes a serious advantage.

For Malaysian universities, having access to a local IoT platform means lecturers and students can ask questions, request training, discuss use cases, and get guidance in a context they understand.

Malaysia has its own education environment. We have our own final year project culture, our own industry needs, our own smart city challenges, and our own local problems that students can solve.

An IoT platform for Malaysian students should not only teach global examples. It should also expose them to local problems such as:

  1. Flood monitoring
  2. Cold-chain logistics
  3. Campus energy monitoring
  4. Smart agriculture
  5. Vehicle tracking
  6. Water quality monitoring
  7. Smart city dashboards
  8. Industrial machine monitoring

These are not imaginary textbook problems. These are problems students can see around them.

When support is local, the conversation becomes easier. A lecturer can say, “I want my students to build a smart campus project.” A student can ask, “How do I send ESP32 data to the platform?” A university can plan, “Can we train 50 students in one workshop?”

That kind of closeness matters.

“A local platform is not just about geography. It is about understanding the problems our students are trying to solve.”
Dr. Mazlan Abbas

4. Tutorials and Teaching Materials

Students love tutorials. Lecturers love tutorials even more because nobody wants to rebuild the same lesson from scratch every semester.

A good IoT platform for universities must have step-by-step materials that students can follow. The documentation should not only be written for professional developers. It should also guide beginners from zero to a working project.

Useful teaching materials should include:

  1. Device setup
  2. Coding examples
  3. Platform account setup
  4. Data upload steps
  5. Dashboard creation
  6. Alert configuration
  7. Common errors
  8. Sample use cases
  9. Project ideas
  10. Extension tasks for advanced students

The best tutorials do not only show students what to click. They explain why each step matters.

This is important because IoT is not only a technical subject. It is a systems-thinking subject. When students learn IoT properly, they begin to understand the relationship between physical devices, networks, cloud platforms, data, people, and decisions.

A tutorial should not only say, “Copy this code.”

It should make students think.

Why do we collect this data?

How often should the device send data?

What happens if the network fails?

Who owns the data?

How secure is the device?

These questions are becoming more important, especially when IoT devices are connected to buildings, cities, factories, farms, and public infrastructure. Students should learn this early, not after they graduate.

5. Showcase Value

Universities need platforms that help students showcase their work clearly and professionally. This may sound like a small thing, but it is not.

A student project with a messy dashboard can make a good idea look weak. A student project with a clean dashboard, proper data flow, alerts, use-case explanation, and a working demo can impress panels, industry partners, and potential employers.

The platform should help students explain their project in a way that makes sense.

Not only:

“This is my sensor.”

But also:

  1. This is the problem.
  2. This is the data I collect.
  3. This is how the platform receives it.
  4. This is the dashboard.
  5. This is the alert.
  6. This is the decision that can be made.
  7. This is how it can be expanded.

That is the difference between a lab experiment and an industry-ready concept.

For universities, showcase value is important because good student projects can become competition entries, research prototypes, industry collaboration demos, grant proposal examples, teaching lab assets, open-day exhibits, or even startup ideas.

A good IoT platform should help students tell the story behind the data.

Comparing Common IoT Platforms for Students

Let us look at the platforms students often use and where each one fits.

Blynk

Blynk is popular because it is beginner-friendly. Students can create mobile dashboards quickly and connect devices without too much difficulty. For early learning, it works well.

Its strength is simplicity.

Its weakness is that students may become too focused on app display rather than full IoT architecture. It is good for quick prototypes, but universities may need something broader when teaching project readiness, multi-user systems, local industry use cases, and longer-term data thinking.

ThingSpeak

ThingSpeak is also popular in universities. It is useful for basic sensor data logging and graphing. Many students use it because tutorials are easy to find.

Its strength is simple data visualisation.

Its weakness is that students may treat IoT as “sensor plus graph.” That is only one piece of the puzzle. For deeper learning, students need more exposure to alerts, roles, APIs, dashboards, application context, and deployment design.

Firebase

Firebase is powerful for app developers. Students who build mobile apps may find it useful for storing and syncing data.

Its strength is app development support.

Its weakness is that it is not an IoT-specific platform by default. Students may need to build many IoT-related features themselves. This can be useful for advanced software students, but challenging for beginners who are still learning sensors, networks, and data formats.

ThingsBoard

ThingsBoard is a strong open-source IoT platform with many features. It can be useful for advanced students and lecturers who want control and flexibility.

Its strength is depth.

Its weakness is setup and maintenance. Universities need technical confidence to install, configure, teach, and support it. For some classes, that may be too heavy. For postgraduate or advanced labs, it can be a good option.

FAVORIOT

FAVORIOT sits in a practical position for Malaysian universities. It gives students a platform that can be used for learning, prototyping, dashboards, alerts, APIs, and real use-case development. It is also local, which means the support, training, examples, and industry context can be closer to what Malaysian students and lecturers need.

Its strength is the balance between learning and project readiness.

Students can start with basic data uploads, then grow into stronger projects that reflect real use cases. Lecturers can use it for teaching. Universities can use it for labs, workshops, competitions, and industry collaboration.

For students, the platform becomes more than a place to display data. It becomes a place to understand the flow from device to decision.

That is the real lesson.

Why FAVORIOT Makes Sense for Universities

I do not believe universities should choose an IoT platform only because it is local. That is not a strong enough reason. A platform must earn its place in the classroom by being useful, practical, teachable, and relevant.

This is where I believe FAVORIOT can contribute.

1. It Helps Students Learn the Full IoT Flow

Students can understand how devices send data to the cloud, how data is stored, how dashboards are created, and how alerts can be triggered.

This teaches IoT as a complete system, not as a loose collection of sensors.

2. It Supports Real Project Ideas

FAVORIOT can support many student project themes, including:

  1. Smart agriculture
  2. Smart campus
  3. Smart building
  4. Smart city
  5. Flood monitoring
  6. Cold-chain monitoring
  7. Vehicle monitoring
  8. Environmental monitoring
  9. Energy monitoring
  10. Industrial machine monitoring

This gives lecturers flexibility across engineering, computing, data science, agriculture, and business faculties.

3. It Gives Local Relevance

Students can build projects that solve problems they see in Malaysia. That makes learning more meaningful.

A student in Kelantan can build a flood alert project. A student in Johor can build a smart factory monitoring project. A student in Selangor can build a campus energy dashboard. A student in Sabah can build a remote environmental monitoring system.

The platform becomes a bridge between classroom learning and local problem-solving.

4. It Can Support Training and Workshops

Universities often need structured learning sessions. FAVORIOT can support this through training, tutorials, and guided project development. This is helpful for lecturers who want their students to move faster without spending too much time solving repeated technical issues.

When students receive proper guidance, they can focus on the project idea, data logic, and outcome.

Of course, wiring errors will still happen. Somewhere in every IoT lab, one jumper wire is always guilty. That is part of the learning experience.

5. It Helps Students Think Like Problem-Solvers

This is the most important part.

IoT is not about gadgets. IoT is about solving problems using connected data.

When students use a platform that supports dashboards, alerts, analytics, and real use cases, they begin to ask better questions.

Not only, “Can my sensor work?”

But, “What decision can this data support?”

That is the shift universities should encourage.

“The best student project is not the one with the most sensors. It is the one that helps someone make a better decision.”
Dr. Mazlan Abbas

So, Which IoT Platform Is Best for Students?

The honest answer is that it depends on the learning goal.

If the goal is to introduce very basic IoT in one lab session, Blynk or ThingSpeak may be enough. If the goal is app development with some connected data, Firebase may be suitable. If the goal is advanced open-source platform control, ThingsBoard can be useful.

But if the goal is to help students build IoT projects that are easier to teach, locally supported, project-ready, and closer to real-world use cases, then FAVORIOT deserves serious attention from Malaysian universities.

Not because it is local only, but because it helps students move from “my sensor sends data” to “my project can support decisions.”

That is the difference.

Universities Should Stop Teaching IoT as a Demo-Only Subject

This is my concern. Too many students treat IoT as a final year project checkbox.

Buy sensor.

Connect microcontroller.

Send data.

Show graph.

Present.

Graduate.

Then what?

The world does not need more abandoned prototypes sitting inside lab cupboards. The world needs graduates who can design connected systems that work outside the classroom.

Universities have a huge role to play here. They can choose platforms that stretch students a little further. Not too much until they drown, but enough to make them stronger.

A good IoT platform should teach students how to think about reliability, security, data quality, user needs, deployment, maintenance, alerts, decisions, business value, and social impact.

That is how we prepare students for the real world.

My Final Thought

When a student builds an IoT project, I do not want them to say only, “My dashboard can show temperature.”

I want them to say, “My system can help a cold-chain operator detect temperature problems before goods are damaged.”

I want them to say, “My system can help a campus reduce energy waste.”

I want them to say, “My system can help farmers monitor soil conditions.”

I want them to say, “My system can help local councils respond faster to floods.”

That is when IoT becomes meaningful. That is when a student project becomes a story of impact.

So, which IoT platform is best for students?

The best platform is the one that helps them learn fast, build properly, get support, showcase confidently, and think beyond the demo.

For many universities in Malaysia, I believe FAVORIOT can be that platform. It gives students a practical path from classroom learning to real-world IoT thinking.

And maybe the next great smart city, smart agriculture, or smart campus idea will not come from a giant corporation. Maybe it will come from a student who started with one sensor, one platform, one dashboard, and one simple question.

What if this small project can solve a real problem?

That is the kind of question worth building for.

What do you think? Should universities continue using the usual IoT platforms, or is it time to introduce students to more locally relevant and project-ready platforms like FAVORIOT? I would love to hear your thoughts in the comments.

Life on Stage: The Journey of a Speaker Who Never Asked to Become One

Mazlan Abbas  ·  Founder Reflections  ·  2025

Life on Stage: The Journey of a Speaker Who Never Asked to Become One

From a single university talk to hundreds of stages across four continents

If someone asks me, “Mazlan, how many times have you given a presentation?” I’ll just smile. Not out of arrogance. But because I honestly can’t remember. What I do remember is that it didn’t start because I wanted to be a speaker. It started because I had something worth sharing, and people began to listen.

This isn’t a post about achievements. It isn’t a resume list. This is a story about what happened between all those numbers. What I felt standing in front of a room. What I carried back to the hotel. What changed in me, one presentation at a time.

Every time I stepped onto a stage, I asked myself the same question: am I here to teach, or am I here to learn?

The answer was always both.

The expert in anything was once a beginner who refused to stop showing up.
Helen Hayes
2013 – 2015  ·  Seeds Planted

In the early days, I was talking about something most people hadn’t fully grasped yet. IoT. Internet of Things. Back then, when people heard “IoT” their faces went blank. I remember giving a talk at UTHM with barely any questions at the end… but I knew the seeds had to be planted early. Someone needed to walk away thinking, “Huh, that’s actually interesting.”

When I delivered the keynote at the International Conference on Soft Computing in Data Science 2015 at Pullman Putrajaya, I could feel the shift. People were beginning to take it seriously. “Internet of Things and Big Data: The Perfect Marriage” was the title I chose myself. Not for the glamour, but because I genuinely believed these two things were made for each other.

2016 – 2017  ·  The Stage Gets Bigger

These years were relentless. Singapore. Sydney. Jakarta. Kuwait. I was standing in front of people from different countries, talking about smart cities, IoT ecosystems, how technology could reshape the way we live. At the Smart Cities Expo World Forum in Sydney 2016, my message was about citizen engagement. Not just infrastructure. Not just data. People.

That’s what everyone always misses. Technology can be brilliant. But if citizens don’t engage, a smart city is just a smart facade.

Kuwait, Singapore, Sydney, Jakarta… not to collect passport stamps. But to bring back perspectives that no office or lab could ever give you.

2017 was also the year I realized something important: I was no longer just an academic or an industry guy. I had become a bridge. Universities invited me. Industries listened. Government agencies started calling. And with that position came a responsibility I didn’t take lightly.

2018 – 2019  ·  Local to Global

There is one moment I will never forget. Keynote at the Smart Cities Global Technologies and Investment Summit in Algiers, Algeria, June 2018. A single Malaysian standing before an audience from North Africa, talking about the IoT innovation ecosystem. There was a flutter of nerves. But far more than that, there was exhilaration.

Because what I brought to that room wasn’t just theory. It came from the real, lived experience of building Favoriot. From every failure and every struggle that no one in the audience could see behind the clean, polished slides.

2019 was even more intense. IIUM. UTeM. UCSI. Polytechnics. Borneo. Istanbul. Sarawak. Topics widened too, from IoT for the Construction Industry, to IR 4.0 for MINDEF. I had stopped talking about IoT in a narrow box. I was talking about transformation. About the future. About how human beings need to adapt or be left behind.

We cannot solve our problems with the same thinking we used when we created them.
Albert Einstein
2020 – 2021  ·  The World Changes, So Does the Stage

COVID arrived. Everything moved online. Webinars became everyone’s new language. And I, someone who had grown used to feeling the live energy of a room, had to adapt. Talking to a camera. Q&A via chat box. A different kind of connection, but the same message.

What I valued most during that period was that people still wanted to listen. MaGIC, UTHM, UiTM, USIM, ADTEC, Politeknik Mersing, UKM… the 2021 webinar list was endless. That told me something: curiosity about technology doesn’t stop, even when the world is falling apart.

I gave a talk on “Jobs That Don’t Exist Yet.” Halfway through, it hit me: several of the things I do today didn’t exist ten years ago either.

The talk at MMU on “The Entrepreneurship Journey of Pre and Post Covid-19” was when I felt closest to my audience. Not because the slides were great. But because the story was real. Favoriot faced the same tsunami. We survived, but we carry the scars.

2022 – 2023  ·  Deeper and More Specific

By 2022, the nature of invitations had shifted. People no longer called to hear a general talk about IoT. They wanted specifics. ESG. Manufacturing. Financial services. TVET. Smart cities. The energy sector.

That is a sign of maturity, both in the industry and in myself. Penang, Smart Factory Conference, October 2023: ESG in Manufacturing. That same month, ICSIMA at Tamu Hotel: Smart Measurement with IoT. Then WCIT 2023: 10 Ways IoT Can Drive ESG Compliance.

Some weeks had two or three events. The body was exhausted. But the mind couldn’t stop.

And then there was the keynote I gave with the most heart: ICoICT 2023, August that year. “Humanizing IoT: Placing People at the Centre of Technology.” That wasn’t just a title. That was my philosophy. After years of talking about devices, sensors, and connectivity, I needed to remind the room, and myself, that at the end of every data pipeline there is a human being. A mother who wants to know her child is safe. An elderly man who wants to live with dignity at home. A farmer who needs to know tomorrow’s weather.

2024 – 2025  ·  Rethinking Everything

The DSA 2024 talk on secured IoT communications marked my entry into the cybersecurity conversation in a more serious way. Smart applications demand secure communications. That is not optional. It is a requirement.

UTAR Talk, November 2024, “The Ultimate Things about IoT.” The audience was energetic students, full of questions. The best one: “Sir, in ten years, will IoT still be relevant?” I smiled. In ten years, IoT will be like electricity. You won’t see it, but you’ll need it everywhere.

And most recently, WCSC 2025. “From Smart to Regenerative: Rethinking Urban Transformation through IoT.” This represents a major shift in my thinking. Smart cities are no longer enough. We need cities that can heal themselves, adapt on their own, regenerate. Not just connected, but alive in a deeper sense.

Through all of it, I saw one common thread: I was never really talking about technology. I was talking about the people who use it, and the people who get left behind when they don’t.

At the National Address Conference, July 2025 at WTCKL, I carried a message about Technology and Data Sovereignty. This wasn’t purely a technical talk. It was about the future of a nation. Whoever holds the data holds the power. Malaysia must understand this.

200+Presentations
12+Countries
12Years on Stage
The purpose of life is not to be happy. It is to be useful, to be honorable, to be compassionate, to have it make some difference that you have lived and lived well.
Ralph Waldo Emerson

From 2013 to 2025. Hundreds of times standing on a stage. From UTHM to Algeria. From a small webinar to an international keynote. From speaking in front of 20 students to thousands of delegates.

What do I bring back every single time? Not the applause. Not my name in a programme book. Not a selfie with the organizer.

What I bring back are the questions people ask after the session. Simple questions, but deep ones. Questions that remind me why I started doing all of this in the first place.

This journey isn’t over. The next stage is already waiting. And I still have a great deal left to say.

Because technology keeps moving. And people need to move with it.

The Day a Small Malaysian Company Stood Shoulder to Shoulder with Microsoft, PwC and Mastercard

FAVORIOT has been named one of the Top 50 Thought Leading Companies on Innovation 2026 by Thinkers360, alongside Microsoft, PwC, Mastercard, and Tata Consultancy Services. As the only Malaysian company on this global list, here is what that recognition truly means.

When was the last time you sat quietly and let something truly sink in?

I had one of those moments recently. I was scrolling through the Thinkers360 announcement for their 2026 Top 50 Thought Leading Companies on Innovation, half-expecting to scan through the usual suspects and close the tab. Then I saw it. FAVORIOT. Right there in the list. Alphabetically sandwiched between the giants of the global technology and consulting world.

I had to read it twice.

Thinkers360 is not a popularity contest. It is not the kind of list you get onto by having a big marketing budget or by gaming social media algorithms. That is precisely what makes it different from most rankings out there. Their leaderboard is powered by a patented algorithm that evaluates companies based on authentic, personally authored thought leadership content, which includes articles, books, keynotes, media interviews, podcasts, whitepapers, and speaking engagements. You cannot buy your way in. You cannot inflate your score with fake followers or reshared third-party content. What counts is what your people genuinely know and are willing to share with the world.

So when FAVORIOT appeared alongside Microsoft, PwC, Mastercard, Tata Consultancy Services, HCLTech, and ServiceNow, I did not feel triumphant in the way you might after winning a business pitch. I felt something quieter and deeper than that. I felt grateful, and I felt a kind of responsibility.

Let me put this into context, because context matters enormously here.

FAVORIOT is a Malaysian company. We are not a billion-dollar multinational. We did not emerge from Silicon Valley or London or Singapore’s Orchard Road. We were built in Kuala Lumpur, by a team that believes deeply in the power of IoT to transform how cities are managed, how industries are monitored, and how businesses make decisions with real-time data. We have been doing this since 2017, quietly and consistently, publishing our thoughts, sharing our frameworks, speaking at conferences, writing when others are sleeping, and building a body of knowledge that goes far beyond what our company size might suggest.

And I think that is exactly the point.

Thought leadership has never been about size. It has always been about substance. It has always been about the courage to have a perspective, to write it down, to share it publicly, and to do so consistently even when the audience is small and the applause is quiet.

I remember the early days of FAVORIOT, when I would publish an article about IoT adoption in developing markets and wonder if anyone was reading. I remember speaking at regional conferences where I was one of the few voices pushing the narrative that Southeast Asia did not have to be a technology consumer, we could be a technology contributor. I believed that deeply, and I kept writing, kept speaking, kept building.

What Thinkers360 has done with this ranking is validate something I have always believed: that genuine expertise, consistently shared, eventually finds its audience. Their methodology deliberately looks beyond social media reach and evaluates the full body of work a company produces. The articles your team writes. The keynotes your leaders deliver. The books, the whitepapers, the podcasts, the depth of contribution to the global conversation. That is a hard score to fake, and I am proud that FAVORIOT earned it the hard way.

Being the only Malaysian company on this list carries a weight I do not take lightly. This is not just a FAVORIOT achievement. It is a moment for the Malaysian technology ecosystem to recognise that we belong in the global conversation, not as observers, but as contributors. Our ideas about IoT, smart cities, and enterprise connectivity are not local curiosities. They are relevant globally, and this recognition confirms it.

Standing in the same list as PwC, a firm with over 360,000 employees across 151 countries, or Microsoft, which shapes the technology infrastructure of virtually every organisation on earth, is not something I will pretend feels ordinary. It is extraordinary. But it also tells me something important: the criteria that matter, depth of thought, consistency of publishing, willingness to educate and elevate an industry, those criteria do not require a headcount of thousands. They require commitment.

I often tell my team that we are not just building an IoT platform. We are building a body of thought. We are documenting what works, sharing what does not, and contributing to a global understanding of how connected technologies can solve real problems for real people in real cities. Every article published, every keynote delivered, every insight shared on LinkedIn or our blog is a brick in that structure.

Today, Thinkers360 has told us that structure is visible. That it stands tall enough to be counted among the world’s most influential companies in innovation.

What comes next matters more than the recognition itself. We will continue writing. We will continue speaking. We will continue challenging assumptions about what IoT can do and who gets to lead that conversation. And we will continue carrying the Malaysian flag into rooms where, honestly, not many have taken it before.

If you are building something in this part of the world, something real, something you believe in, and you are doing the quiet, consistent work of sharing your knowledge with the world, I want you to know this: it accumulates. It compounds. And one day, it gets seen.

Are you investing in thought leadership the same way you invest in your product? Because in the end, the companies that shape industries are the ones that shape the conversation first.

Explore the full Thinkers360 50 Thought Leading Companies on Innovation 2026 list. If your organization is building something worth sharing, the global conversation is still wide open, and the world is still listening.

How AI Has Lightened My Load as Chief Everything Officer

Being a founder means being the Chief Everything Officer. Here is how AI has become the leverage that makes the load just a little lighter.

If there is one title that most accurately describes my life right now, it is not CEO. Not Founder. Not even the glamorous-sounding “Technopreneur.”

It is Chief Everything Officer.

And that is not something to be proud of. It is an exhausting reality.

The Monday Morning That Never Ends

Picture a Monday morning. Before 9am, my head is already full. A client proposal still half-done. A LinkedIn post I have not updated in three days. An email from an overseas partner waiting for a reply. A pitching deck for next week that is still blank. A financial report the accounts team has been asking for since yesterday.

All of it, simultaneously, inside the same head.

Back when I worked in large organisations, there were teams for all of this. Someone for marketing. Someone to handle social media. Someone to prepare slides. A PA to filter emails. My role was specific, focused, and contained. The moment I left to build my own company, I realised… all of that now falls on me.

That is the part nobody tells you about the startup world. They talk about freedom. About being your own boss. But nobody talks about those Sunday nights sitting alone in front of a laptop, trying to finish a company blog post, with a pounding headache from exhaustion.

Burnout Is Real

I have experienced burnout. Not once. More than once.

There were moments I would sit in front of the screen, hands on the keyboard, with nothing coming out. Not because I had no ideas, but because my mind was so overloaded it could no longer process anything. Like a browser with too many tabs open until the laptop freezes.

That is the most frightening feeling as a founder, because if you stop, everything stops.

I still remember one night, past midnight, trying to write a proposal for a major client. Hands tired. Eyes tired. But my brain could not stop because the deadline was the next morning. I asked myself at that moment, “How long can I keep doing this?”

The answer did not come in the form of rest. It came in the form of technology.

“Successful entrepreneurs are not those who work the hardest. They are those who are smartest about using every resource available to them.”

When AI Entered the Picture

The first thing AI helped me with was writing. Before this, a single article for the company blog could take half a day. Research, outline, draft, edit, proofread… hours of work. Now I sit down, have a conversation with AI, explain what I want to convey, and within a short time I have a working draft.

Not copy-paste verbatim. But a starting point. And that starting point is incredibly valuable when time is your most limited resource.

Then I started using AI for social media. Facebook, LinkedIn, TikTok, Instagram… each platform has its own tone. Before, even thinking of captions felt like a burden. Now I brief the AI on the message I want to deliver, the platform, the audience, and it helps me draft. I edit to match my voice. Fast. Efficient.

Presentation slides too. I outline what I want, AI helps me structure the flow, drafts content for each slide, and suggests what to keep and what to cut. I walk into meetings more confident, more prepared, calmer.

My 11pm Brainstorming Partner

This is what I love most. Before, when I wanted to think something through, I had to wait for a meeting, for other people in the room, for a discussion to happen. Now I can brainstorm with AI at 11pm after everyone is asleep.

I ask questions, push back, ask it to argue against me. It gives me perspectives I had not considered. There are times I come in with an idea I think is brilliant. The AI gives me a counter-argument that makes me think twice. That is not a bad thing. It is far better than proceeding with an idea that has holes in it.

AI also helps me prepare for meetings and pitching sessions. I describe the client I am about to meet, their industry, their likely problems, my product. I ask the AI to simulate the questions they might ask, the objections that might come up, the best way for me to respond. It is like a rehearsal. And it makes me walk into the room far more prepared.

Since using AI, I feel like I have an assistant who never sleeps, never takes leave, never asks for a raise, and is always ready when I need them.

“The best technology is not the most sophisticated. It is the one that saves the most of our time and energy for what truly matters.”

Honest Truth: AI Is Not the Answer to Everything

I want to be clear about this. AI is not a cure for every problem.

AI cannot replace human relationships. When I meet a client, what makes them trust me is not a beautiful slide deck or a well-written proposal. It is the way I speak, the way I listen, the way I show that I truly understand their problems. That comes from experience and empathy, not from a prompt.

AI also cannot make strategic decisions for me. It can provide data, perspectives, and options. But ultimately, I am the one who must decide. Those decisions come from gut instinct built over years of experience, mistakes, and lessons learned.

And AI cannot replace real networking. Coffee with an old friend, connecting with another founder who understands the same struggles, attending an event and having organic conversations… all of that still matters, and still has to be done personally.

So the way I see AI now is this: it is leverage. Not a replacement. When you have good leverage, you can lift heavier things with the same amount of energy. AI is leverage for my time and energy as a founder doing many things alone.

To Founders Who Are Still Skeptical

I see fellow founders who have not yet fully embraced AI. Some are skeptical, some afraid, some feel it is “cheating” or inauthentic. I understand that feeling. I felt the same way.

But when I watch them struggling with things I can now resolve much faster, I feel for them, because I know how exhausting life is without that leverage. The world has changed. The tools have changed. The way we work must change too.

I am not telling you to hand over all control to AI. I am simply saying: try it first. Use it for one small thing. See what happens. Give it a chance to prove its value.

“Do not fear new tools. Fear the unwillingness to learn, because that is what will leave us behind.”

Still Chief Everything Officer, But With a Reliable Partner

One day, perhaps AI will be able to do even more. Handle customer service, manage projects, negotiate with vendors. Maybe the role of Chief Everything Officer will truly be shared between me and AI in a more balanced way.

But for now, I am still the Chief Everything Officer. Only now, I have a reliable partner. One I can “wake up” at 2am when an idea suddenly strikes. One that never complains, never has bad days, and always tries to give me the best answer.

And that is enough to make a founder’s life just a little bit lighter. Just a little. But in the startup world, a little means everything.

What about you? Are you still doing everything alone, or have you found your own leverage? Share your thoughts in the comments below.