“What if the biggest reason we stop growing is not because we do not know enough, but because we become too attached to what we already believe?”
The longer we work in an industry, the easier it becomes to confuse experience with certainty. Experience teaches us to recognise patterns, anticipate problems and make faster decisions, but it can also make us overly protective of ideas that once worked well. Over time, those ideas may become part of our identity, and questioning them can feel almost like questioning ourselves.
Some of my most meaningful breakthroughs did not happen when I discovered a new technology, attended another conference or read another business book. They happened when I finally admitted that one of my long-held beliefs no longer matched the reality in front of me. That admission was never comfortable, but it often opened the door to a clearer understanding of what customers needed, what the market valued and what my own role should become.
Changing my mind was not a sign that I had failed. It was a sign that reality had taught me something that experience alone could not.
I Once Believed the Best Technology Would Naturally Win
For many years, I believed that if we built a strong technology product, customers would eventually recognise its value. The reasoning appeared logical because good technology should solve problems, and a technically solid product should stand out in the market.
Coming from an engineering and technical background, I placed great importance on architecture, reliability, scalability, security and functionality. I believed that if we could build a platform that connected devices, stored data, supported multiple communication protocols, displayed dashboards and triggered alerts, customers would naturally understand why it mattered.
“Surely, people will see how much effort has gone into building this,” I thought to myself.
When we started Favoriot, much of our attention was placed on the IoT platform itself. We worked on device connectivity, data collection, dashboards, alerts, application programming interfaces and project management capabilities. These were necessary foundations, and without them, the platform could not function properly.
The mistake was not in building those capabilities. The mistake was assuming that the platform itself was what customers wanted to buy.
That belief slowly began to change through repeated conversations with customers, partners and system integrators. There was no single dramatic meeting where someone told me that I had misunderstood the market. Instead, reality revealed itself through small moments that appeared repeatedly.
A prospect would ask how quickly we could show a working use case. A partner would ask whether the platform could support a specific operational requirement. A customer would listen politely to a technical presentation and then ask a much simpler question.
“How will this help us detect the problem earlier?”
That question was more powerful than many technical presentations because it forced me to recognise the difference between what we had built and what the customer was trying to achieve.
Customers Rarely Wake Up Wanting an IoT Platform
A factory manager does not wake up in the morning hoping to purchase another platform. A building manager does not arrive at work thinking about MQTT connections, database architecture or cloud infrastructure. A city officer does not begin the day wishing for another dashboard to display inside a command centre.
They are thinking about problems that are already affecting their operations.
They may be worried about rising energy bills, recurring equipment failures, delayed maintenance, water leakage, public complaints, safety incidents or reports that are already overdue. Their attention is focused on the operational pressure in front of them, not on the technology category behind the solution.
This distinction may appear obvious when written down, but it took years of customer conversations for me to fully understand its importance. Customers do not usually purchase technology because they admire its architecture. They purchase it because they need a faster, clearer and more reliable way to solve a problem.
That realisation changed the way I began to see Favoriot. We were not simply offering a platform that could connect devices and display data. We were helping customers and partners shorten the distance between a problem occurring and someone taking action.
The technology remained necessary, but it could no longer be the centre of the conversation.
More Features Did Not Automatically Create More Value
Another belief I had to question was the assumption that more features would automatically make the product more valuable.
Like many technology companies, we often believed that expanding the feature list would make the platform more attractive. More functions appeared to mean more capabilities, more possible use cases and a wider market.
That logic was understandable, but customer value is not measured by the number of features shown in a brochure. It is measured by whether the product helps someone solve a problem with less confusion, delay and risk.
A platform may contain fifty features, but a customer may only need five of them to prevent a costly equipment failure. Those five features carry more practical value than the other forty-five combined.
Sometimes, adding too many features can make the conversation harder rather than easier. The presentation becomes longer, the customer becomes distracted and the real business problem disappears behind technical terminology.
It is similar to bringing an entire hardware shop to repair one leaking tap. The customer may be impressed by the number of tools, but the main concern remains very simple: when will the leak stop?
“Are we showing customers everything we have built, or are we helping them understand what they can solve?”
That question forced me to reconsider how we explained the platform and how we defined value.
Three Beliefs That Gradually Changed
Over time, my thinking shifted in three important ways.
- I moved from believing that strong technology would sell itself to understanding that technology must be tied to a clear operational problem. Customers may appreciate technical quality, but they usually make decisions based on outcomes, urgency and business impact.
- I moved from believing that more features would create more value to understanding that relevance matters more than quantity. A small number of capabilities that solve a painful problem can be more valuable than a long feature list that creates confusion.
- I moved from believing that the IoT platform was the final product to seeing it as the foundation of a much larger solution. The platform enables devices, applications, alerts and data flows, but the real outcome is better visibility, faster response and stronger decisions.
These changes did not happen overnight. They came from listening carefully to the questions customers kept asking and noticing which parts of our explanations truly mattered to them.
The Platform Was Not the Final Product
The biggest shift came when I began to understand that Favoriot was not merely the product. It was part of a larger system that helped people solve operational problems more quickly.
The platform connects devices, receives data, stores information, presents dashboards and triggers alerts. These capabilities matter because they provide the foundation on which an application or solution can be built.
Yet the customer does not judge success by whether data successfully reached the cloud. The customer judges success by what happened after the data arrived.
Did the maintenance team receive an early warning before equipment failed?
Did the building manager detect unusual energy consumption before the monthly bill arrived?
Did the farm operator know that soil conditions had changed before crops were affected?
Did the local council receive enough warning to respond to rising flood levels?
Did management understand why an incident occurred and what action should follow?
These questions reveal the true value of the solution because they connect technology directly to operational outcomes.
The real product was not connectivity. The real product was better visibility, earlier action and greater confidence in decision-making.
This change in thinking also changed how I saw my own role. I was no longer simply explaining how an IoT platform worked. I had to help customers identify what they could not currently see, why that blind spot mattered and how trusted operational data could help them act earlier.
That was a more difficult conversation, but it was also far more meaningful.
When Data Fails to Create Operational Clarity
This shift eventually led me to think more seriously about Operational Blindness.
Years ago, many IoT discussions focused heavily on connecting devices, collecting data and building dashboards. A project was often celebrated when sensors successfully transmitted data to a platform and colourful charts appeared on a screen.
From a technical perspective, the system was alive.
Yet a connected organisation is not always an informed organisation.
Imagine a factory with thousands of sensors reporting every minute. Temperature data is arriving, vibration levels are being recorded, energy consumption is visible and production machines are connected.
On paper, the project appears successful because devices are communicating and information is being collected continuously.
In practice, the maintenance team may still discover equipment failures too late. Managers may still depend on WhatsApp messages to understand what happened during the night shift. Different departments may still keep separate spreadsheets, while executives continue waiting for weekly reports before learning that a recurring problem has been growing for several days.
The project delivered data, but it did not deliver operational clarity.
That difference changed the way I evaluated technology projects. I began to see that data alone does not remove blindness. In some cases, more data can create the appearance of visibility while leaving the organisation just as uncertain as before.
A dashboard may show that everything is green, while someone on the factory floor already knows that a machine sounds unusual. The system says normal, but experience suggests that something is wrong. Nobody acts because the information is incomplete, delayed or disconnected from its operational context.
That is Operational Blindness.
I Began Asking a Different Question
For many years, one of the most common questions in IoT was simple.
“How do we connect more devices?”
That remains a useful technical question, especially when an organisation has many isolated assets. Yet I no longer believe it should be the first question asked.
A better starting point is:
“What decision is the organisation unable to make today because it cannot see the full picture?”
That single question changes the direction of the entire discussion.
Instead of beginning with sensors, we begin with a delayed decision. Instead of beginning with dashboards, we begin with a blind spot. Instead of asking how much data can be collected, we ask which information is needed, who needs it, when they need it and what action should follow.
Consider a cold-room operator. The real problem is not that the company lacks temperature data. The problem is that a temperature change may go unnoticed for long enough to damage stored goods.
The most useful question is not whether a sensor can be installed. The better question is how early the team must be warned to prevent a loss.
Once that answer becomes clear, the device, network, platform, alert rules and reporting process can be designed around the required decision. The technology begins to serve the operation instead of forcing the operation to adapt to the technology.
Experience Can Become a Comfortable Prison
There is a strange irony in experience. It helps us make better decisions because we have seen similar situations before, but it can also trap us when we assume that tomorrow will behave like yesterday.
The beliefs that once helped us succeed may later prevent us from seeing a new reality. This becomes especially dangerous in technology and business because markets change, customer expectations shift, competitors appear and new business models emerge.
We may continue presenting the answer to a question that customers stopped asking several years ago.
“Am I defending this idea because it is still correct, or because it has been part of my identity for too long?”
That is not an easy question to ask because changing our mind can feel like admitting that our earlier view was wrong. Yet there is a clear difference between being inconsistent and being willing to learn.
Inconsistency means changing direction without a sound reason. Learning means changing direction because new evidence has revealed a better path.
That distinction matters because leaders often feel pressured to appear certain. We may worry that changing our views will weaken our credibility, but refusing to change in the face of strong evidence can be far more damaging.
Unlearning Is Often Harder Than Learning
Learning something new usually feels rewarding. We gain knowledge, understand a new concept or add another skill to our toolkit.
Unlearning is more painful because it asks us to release something familiar. It may require us to admit that a strategy we defended was incomplete, simplify a product we spent years expanding or change the story we have been telling about our own business.
For Favoriot, this shift was never about abandoning the IoT platform. The platform remains the foundation of what we do.
What changed was my understanding of its true role.
The platform helps system integrators, product builders, universities and organisations move faster. It reduces the need to build every backend component from scratch and helps teams collect real-world data, create applications and respond to operational events.
The customer outcome is not simply the use of Favoriot. The customer outcome is fewer blind spots, earlier warnings, clearer operations and better decisions.
That may appear to be a small change in wording, but it influences product design, sales conversations, training programmes, partnerships and the way success is measured.
Success Can Sometimes Confirm the Wrong Lesson
Failure often forces us to reflect because something clearly did not work. Success can be more dangerous because it may convince us that every assumption we made was correct.
A project may succeed because of timing, persistence, relationships or a particular market condition. Yet we may conclude that our entire approach was perfect, repeat it in a different environment and then wonder why the same result does not appear.
That is why some of my most valuable lessons did not come from celebrating what worked. They came from examining what no longer worked and having the courage to change my mind.
I once believed that strong technology would naturally attract customers. I now believe that strong technology must be connected to a clear operational problem.
I once believed that more features would create more value. I now believe that value comes from helping people make better decisions with less confusion and delay.
I once believed that the IoT platform was the product. I now see it as the foundation that allows people to build, deploy and improve real solutions faster.
Each of these changes began when I stopped defending an old belief long enough to consider a better one.
Experience Becomes Wisdom Only After Reflection
Experience is valuable, but experience alone does not automatically become wisdom. A person can repeat the same year of experience twenty times without learning anything new.
Wisdom appears when we examine what happened, question the assumptions behind our decisions and allow reality to correct us.
Sometimes growth does not require another course, another certification or another book. Sometimes it begins with a quieter act of honesty, when we admit that something we once believed no longer serves us.
We stop protecting the old answer and begin asking a better question.
For me, one of those better questions became:
“What decision is the organisation unable to make because it cannot see the full picture?”
That question helped me move beyond devices, dashboards and features. It helped me recognise the deeper issue hidden inside many technology projects.
It also reminded me that my own thinking could suffer from the same blindness I was describing in organisations. I could accumulate years of experience and still fail to notice that the world had changed.
That may be the most humbling lesson of all.
Progress sometimes begins with learning something new, but some of our greatest progress begins when we become willing to unlearn something old.
What belief did you once hold strongly, only to discover later that reality had taught you a different lesson? I would love to hear your experience in the comments.
Discover more from Dr. Mazlan Abbas
Subscribe to get the latest posts sent to your email.
