I’ve always found the idea that so many IoT startups and established companies do POCs or Proof of Concepts strange. I also find it unfortunate that many enterprises start off with POCs. Why do so many IoT vendors lead into sales opportunities with POCs with prospective customers and why do so many enterprise end users seemingly entrap these poor little startups in some hellish cycle of pre-sales POC giveaways? More often than not, when you speak to the founders of these IoT startup firms, they are frustrated by the difficulty of getting customers or prospects to pay up. So how did we into this unusual situation as a “industry”? Wasn’t IoT supposed to be easy to sell? Didn’t every business want it?  Evidently, the answer is not exactly yes. 

Why do we do POCs?

Let’s look at POCs in the context of product development and POCs in the context of the digital transformation program of an enterprise, because I think there is some confusion that I have observed that is contributing to the maligning of what is otherwise a pretty helpful exercise to an eternal purgatory. 

What are POCs? POCs are nothing new. We have see the approach of used in industry for decades to test new product and service concepts. It is commonly used in product  as well as software development to demonstrate functionality and to provide technical verification that an idea or solution is feasible and is something that can be developed. POCs can be used to test and validate different design options as well to determine which mode is better than another. 

In the context of enterprise transformation projects, POCs have been traditionally used to test vendor solutions for fit to the organizations needs and technology environments. From the perspective of the business folks who know little about the technical aspects of IoT or likely what IoT is, these POC activities are used commonly as a way to demonstrate shortlisted vendor solutions to an organization as well as verify that functional and nonfunctional requirements of the business that are important selection criteria for vendor selection. If an enterprise gets to the point where they are selecting a technology vendor, they are typically already bought into the IoT-enabled transformation initiative. Yet, more often than not I have hear an outsized proportion of IoT vendors who say that POCs are used to prove the business value of their IoT offerings. 

The confusion and the descent into POC purgatory or hell seems to happen when IoT vendor take a product or software development mindset forward in the way it engages with enterprise buyers. In other words, many IoT vendors approach the POC as an opportunity to “co-create” with the customer and effectively create a pilot implementation of their solution with the hope of selling a few modules, connections and providing analytics on a recurring revenue basis by putting skin in the game. In the end, the IoT vendor ends up giving up a sizable revenue opportunity in consulting and software development services. It’s little wonder so many vendors feel they are in this perpetual cycle of running POCs for prospects before they see a sale. I have yet to meet an enterprise that is not game for a bunch of free consulting, which is what many IoT vendors believe they have to offer to get their foot in the door with a prospective client. Ironically, consulting services are not the game many IoT vendors are in. They want to sell devices, software, middleware, platforms and connectivity because everything is becoming XaaS.

Why do IoT projects fail?

Given that this POC approach pushed by IoT vendors has been so prevalent, it is no wonder that enterprises have experienced a high percentage of IoT project failures. If we buy into the notion that most IoT initiatives don’t get past the POC phase, it appears that it is because the IoT vendor pushes the technology before the business problem to solve out of perceived necessity to secure business. In particular, those IoT vendors that are not positioned to deliver the full solution as it were, find themselves potentially convincing the prospective customer that this IoT stuff is for the birds through their seemingly altruistic efforts that highlight technical viability but fall short in demonstrating business value.

Projects of any sort require commitment and stakeholders who are serious about their investment in a charter for transformation and fully bought into the value that the solution is expected to deliver. The things that make “IoT projects” challenging are the following:

• They are not about IoT. Many of us still call them “IoT Projects”. This typically means little to a business stakeholder. We need to remind ourselves that IoT is just a blackhole of technologies and solution patterns that continues to suck in new technologies as they emerge from the early phases of the hype cycle. To business folks it has much to do about nothing other than the 101 that they get from an online course on digital. If you want to win hearts and minds of the board of a oil & gas major, try something like the super remote, zero touch well operation project. It has a much better ring to it.
• IoT Technology is Massive and Complex – IoT is difficult to get a handle on as a technology given the expansive scope and the high velocity of change in the technology and vendor landscapes. Unlike the world of ERP, there are few out-of-the-box, packaged IoT solutions. We are slowly moving in that direction, but the IoT technology universe is still very crowded and fragmented.
• IoT Talent Gap – Transformation projects that involve IoT require technical resources and expertise across a wide range of areas including  IT, OT and CT which are converging as well. Then you need the business experts and the industry experts who know enough about IoT to engage in a viable solutioning discussion. The talent pool of folks who can speak the different languages across these domains is small. The talent challenge is real. 
• The Developer’s Mindset – A transformation project is not a custom software development project. It is about integration. If you are developing your product with your customer, your stuff is not ready for market. Set your expectations with your customer because most business stakeholders don’t like being a subject of what they likely consider an experiment. 

Improving your odds of realizing IoT value

If these challenges and root causes of pre-sales and project angst resonate with you, I would like to share some recommendations that will hopefully improve the outcomes of your efforts and get you engaged in conversations of value with your prospects and customers without dwelling on the term “IoT”. 

For enterprise end users, here are my recommendations:

• Transformation is not just about organization change or technologies. Neither should not be the core of your IoT strategy. It’s all about the business solution. Organizational change is table stakes for any transformation program. If you don’t know this by now, hire a good program manager and change management consultant. Often times well-designed IoT solutions are transparent to the organization. They are just easy to use and may even factor out people from the processes and functions. IoT technologies are just enablers. Leave that topic to your IoT architect. Focus on sound solution designs that work functionally, technically and financially, but most importantly delivers against expectations set for by the strategy and the charter of the transformation program. Ultimately expectations at the business stakeholder level define the criteria for a successful project, so if you don’t know how to translate technology into the language of business, learn how. Most of us technology folks are good at abstraction, virtualization, so this shouldn’t be much of a stretch, right? 
• Get an IoT-savvy solution architect in your organization. They are apparently more rare than you would think but absolutely critical for success so look hard. And get the IoT-savvy technology solution architects and those savvy in your business together early on in your program to work with your business stakeholders in designing a solution for your organization that is technically and functionally viable and compelling. This seemingly rare breed of solution architect is great at keeping your system integrators and vendors honest. As I like to say IoT is not your father’s ERP. 
• Good help never comes free. Don’t short change IoT experts and consultants who can help you be successful. If your vendor has a few really smart folks who can help you, hire them by giving them a proper project so that they can focus on doing a great job rather than carrying the anxiety of the hours they are giving away for free. There really isn’t a worse IoT-enabled transformation strategy than one that is done for free.  Remember that 80 percent of the value of IoT can be realized by 20 percent of the technologies that are being pitched to you by your vendors and SIs. Don’t incentivize your IoT partners to make up the freebie they gave you up front by making up for it on the backend. You will probably end up having to redo your strategy work, or get an IoT solution that is much more expensive to implement and maintain than it should be, or your IoT project just goes into the failed bucket. 

For vendors, here are my recommendations:

• Understand your role in the context of your customer’s transformation program. How do your offerings map into the solution architecture that will support the customer’s transformation objectives? Remember, the folks with the purse strings don’t care about the technology and which protocols or connectivity technology you use. They just want business benefits and outcomes. Figure out how you can be part of that business value discussion whether you latch on to a more strategic theme such as security, cost reduction, efficiency, reliability/resiliency or all of the above and more. 
• Carefully contemplate who you partner with to give your offerings business relevance and meaning. Many IoT vendors partner with other vendors from a technical perspective, you also need to have downstream channel partners to get you in the transformation discussion. Find a strategic anchor for your go-to-market. If you don’t have consulting services to engage with enterprise customers at the business level, consider partnering with an SI and POC with them to prove that your offerings work and that they can trust working with you to deliver IoT-enabled business solutions to their customers.
• Stop giving away free management consulting gigs that you call POCs, especially if consulting is not your forte. These gratis gigs or pre-sales POCs are not POCs, they are a pilot phase of an implementation that you should be getting paid for. You might not be helping yourself or your business if you don’t capture value early.

Hopefully these insights and tips will help IoT vendors avoid the POC trap and improve the probability of success for IoT-enabled transformation initiatives for enterprise end users. Good hunting!