Last week I had the privilege of speaking at #IoTLondon being held at BCS (The Chartered Institute for IT). Sharing the stage with Phil Steel from Octopus Energy and Max Park from Central Saint Martins. The first IoT event of 2026 drew a full house of people from across IoT. From hardware to software to product and business development.
Drawing insights from across conversations over the last 12-24 months my talk focused on the most common reasons IoT Projects fail to realise their intended outcomes.
Avoiding The Pitfalls In IoT Projects
An article published by IoT for All in 2025 quoted ‘76% of all IoT projects fail to meet expectations [1]. Whilst this can sometimes come down to the core project management principles (Time, Resource, Budget), referred to as The Iron Triangle, there are a common set of pitfalls that trend across projects that have failed to meet expectations.
10 Reasons Why IoT Projects Fail To Meet Expectations
In no particular order, these are:
- Failure to validate end user needs, wants and value
- Too much focus on the technology not the outcome
- Ignoring total cost of ownership (TCO)
- Poor data strategy
- Making a Proof-of-Concept a Production Release
- Security and compliance treated as an afterthought
- No credible UAT and continuous feedback loop
- Weak ownership and governance
- Poor Hardware/Technology Choices
- Assumptions
While most people’s reaction to this list is one of sincere familiarity, it is often acknowledged that while these have been seen on previous projects they have been involved with, they still happen.
Failure to validate end user needs, wants and value
‘Failure to validate end user needs, wants and value’, it seems totally reasonable. You have to ensure what ever you’re building fixes a pain point of the user and/or delivers value to them. That said, so many times solutions miss the mark because project owners haven’t spent time truly understanding what this means’ mostly spoken to only a small selection of user personas or worst of all, assumed they know what the user wants without any engagement. Amazon Dash Buttons are a good example of this but they were also hit by a wave of moving trends at the same time.
Amazon Dash Buttons were small Wi-Fi connected physical buttons that customers could stick around their home (for example near a washing machine) and press to instantly reorder a specific product like detergent from Amazon. The idea was to make repeat purchases super quick without needing to open an app or visit the website.
However, it turned out that the majority of people didn’t want to install and manage physical buttons around their house. The concept also assumed repeat ordering was more impulsive than it really was. As a result, the product struggled to get traction and was eventually discontinued, with Amazon claiming that it was made unnecessary due to automatic reordering and product subscriptions. [2]
Too much focus on the technology not the outcome
Another common reason why IoT projects fail to reach expectations is because the wrong technology is chosen. Sometimes this is based on a companies desire to use a technology they are comfortable with, potentially already have hardware for or believe it to be the right technology without doing sufficient research or testing. There are many examples of this all over the IoT Space.
The early rollouts of Smart Electricity Meters in the UK are a prime example. These devices largely used 2G/3G with no long-term migration plan. Communication modules were embedded deep in meters and led to a massive retrofit bill. [3]
Ignoring total cost of ownership (TCO)
Whilst most people venturing into IoT projects have a defined budget to work towards, they often ignore the total cost of ownership leaving the project with not enough money to launch. In Project Management it is common to keep a 10-20% additional budget for unexpected costs and project overrun. However this is often not sufficient if a full cost analysis of the project has not been completed. For example, the ongoing operational/maintenance cost has not been included into the calculation.
A further trap is opting for low cost hardware, components or connectivity options. In IoT projects it is common to look at low-cost sim connectivity contracts without evaluating their total operational costs, which can lead to performance gaps and hidden charges.
Poor data strategy
IoT by its very nature captures a large amount of data. Data that typically represents what is being done at the edge. Be it taking temperature readings, user input or capturing a persons vital signs. That data is then used at the edge or in the cloud to deliver, insights, actions or recommendations. If the data is not captured and organised in a way that can be used to satisfy end user expectations it can quickly lead to project failure.
Originally a leader in the fitness tracker market, Jawbone struggled with data integration and ultimately ceased operations. Its wearables were meant to track health metrics, but the company faced issues with data reliability and user engagement. [4]
Making a Proof-of-Concept a Production Release
Building a proof-of-concept that gets well received by its test users is often exciting, a common trap however is to release the PoC as your first release with little or no changes. While it’s generally good to get a release to the market as soon as possible, it must be secure, reliable and scalable. Most PoC’s aren’t built with these three foundations, they are built to proof a concept. More often than not the learnings from a PoC should be put into a new build with the concepts of being well-architected in place.
After a promising PoC, a smart thermostat manufacturer rushed its thermostat to market with minimal changes. While it initially performed well, it struggled with scalability issues as user demands grew. Users faced software bugs and connectivity issues, which hampered customer satisfaction and forced the company to issue several updates.
Security and compliance treated as an afterthought
When developing an IoT Project, security and compliance are often treated as a second thought as they are often not seen as the aspects that will excite investors, stakeholders and early adopters. They often take an initial back seat, but they should be given the attention they deserve early on and continuously.
Retrofitting security and compliance can cost considerably more than if they are built into the solution from day one. Not understanding how these relate to your product can dramatically impact your success.
For example, the early version of Ring cameras suffered significant security compromises. While not fully Ring’s fault, due to the nature of default passwords at the time and the market not being overly security conscious of changing default passwords, not using the same credentials and sharing credentials etc, it did allow camera streams to be compromised.
Hackers exploited default and weak passwords, gaining access to users’ live video streams and communicating with them through the devices. This incident raised significant privacy concerns and criticisms of Ring’s security practices. [5]
Even when companies focus on security and compliance from day 1, things can still go wrong. They are both complex areas that evolve daily.
For example, going back to Amazon Dash Buttons. They were found in a German Court to have breached the country’s Consumer Protection Law as they don’t inform the user of the price prior to purchasing via them. [6]
No credible UAT and continuous feedback loop
It is so important to get user feedback and not just once, it has to be a continuous feedback loop with every single piece of feedback acknowledged and reviewed. AI is great for identifying trends in user feedback as you scale.
Kaspersky launched a smart home device but failed to gather adequate user feedback during its UAT. Many users found its functionalities less intuitive than anticipated, leading to poor adoption rates. The lack of ongoing feedback resulted in numerous issues that could have been resolved before market release. [7]
Weak ownership and governance
Ever heard the phrase, “If everyone owns it, nobody owns it.” This is nearly always the case, if you don’t assign individual owners and you assign groups or no one, the project will 100% drift.
San Diego’s initiative to install smart streetlights faced challenges due to slow decision-making processes among city officials. The lack of strong project governance resulted in project delays and criticism from stakeholders, with many questioning the city’s commitment to smart technologies. [8]
Poor Hardware/Technology Choices
It’s so important when making hardware/technology choices you consider three core groups of requirements:
- Does it meet all of the requirements as we know them today?
- Will it scale and how can it be updated/evolved?
- Based on what we know today, will it meet our future requirements? (e.g. feature roadmap, consumption targets etc)
In addition to this, test, test and test. Especially with higher than expected usage, usage in weak/no signal areas, broken power cycles etc.
An early version of the Nest smart thermostat suffered crashes during high-usage periods, caused by the heavy load on communication protocols, leading to a poor user experience. [9]
Assumptions
Last but very much just as important, potentially a catch all. Never make assumptions without validating them. It is so easy to assume you know something, or to speak to one or a few people and assume that is how something is done by everyone, or globally.
Often we don’t have all the pieces and we learn as we go along. Make assumptions if you must, but document and validate as a process.
General Electric’s (GE’s) Predix platform faced significant challenges because it assumed existing IT infrastructure could support its IoT applications. Many users found it difficult to integrate with their current systems, leading to slow adoption and project failures [10].
Summary
IoT projects often don’t fail because the technology is hard. They fail because the business case, governance, and operating model aren’t treated as first-class citizens.
If you’re working on an IoT initiative right now, which of these pitfalls feels most familiar?
Sources
- https://www.iotforall.com/why-76-percent-iot-projects-fail-how-to-achieve-success
- https://uk.pcmag.com/news/119886/amazon-kills-dash-buttons-because-no-one-uses-them
- https://publications.parliament.uk/pa/cm5803/cmselect/cmpubacc/1332/report.html
- https://www.smartwareadvisors.com/pages/case-study-the-rise-and-fall-of-jawbone
- https://conosco.com/industry-insights/blog/iot-security-breaches-4-real-world-examples
- https://www.reuters.com/article/us-amazon-com-germany-court/court-says-amazon-dash-buttons-violate-german-law-idUSKCN1P42HW
- https://www.forbes.com/councils/forbestechcouncil/2024/07/09/common-uat-mistakes-design-teams-make-and-how-to-avoid-them/
- https://www.embedthis.com/blog/stories/why-iot-projects-fail.html
- https://medium.com/@william.smith9953/top-5-real-world-iot-app-failures-and-how-developers-fixed-them-d5030d1f9f88
- https://www.embedthis.com/blog/stories/why-iot-projects-fail.html