5 Biggest Mistakes in IoT PoCs

Let me start by saying I love proof of concepts (PoCs), especially when Splunk is involved. PoCs allow me to validate the technical feasibility of our platform with customers and remove any doubts about implementing the technology.

While a PoC is an effective way for businesses to evaluate new technologies, you may encounter pitfalls if you’re not well prepared. If you want to give your PoC the best chance of success, it’s important to understand these common mistakes and how to avoid them.

  1. Outline exactly what the PoC will accomplish in the customer’s environment. — Without proper scoping, the PoC often ends up demonstrating  that the product only works in a controlled environment. I have witnessed countless efforts squashed by executives asking pointed questions during PoC reviews that revealed holes or gaps, and showed how the PoC wasn’t applicable to their environment. If possible, it is always best to do the PoC in the target environment.

  2. Define what a successful PoC looks like. — Many times teams will focus on the how and lose sight of the final goals. I am definitely guilty of this one. It is easy to get distracted by the “shiny” details and not focus on the end goal. Having a clear goal serves two purposes: it makes a checklist of things that need to be accomplished to prevent scope creep, and provides overall clarity for. You can’t close the deal if the PoC isn’t completed.

  3. Make sure all the correct parties are accounted for when scoping a PoC. — A common topic in the industrial IoT space is IT/OT convergence. With IT/OT convergence in mind, make sure all important parties from both the IT and OT worlds are present when the goals and checklists are created. This will help prevent the common mistakes noted above. For more information about overcoming IT/OT challenges, read our blog about the differences in priority and goals between the teams, and how to draw alignment.

  4. PoCs should be short and sweet. — They should reflect the product; high value, low effort. In today’s agile environments, PoCs shouldn’t take months to complete, but weeks. Things are moving faster and personnel resources for the customer are limited. Stating that it will take months to complete a PoC is going to inch you closer to the discard pile. Taking this into consideration, machine learning may not be an advisable PoC due to its need for large amounts of historic data.

  5. Lastly, don’t do all the work. — For a truly successful PoC, the customer should be in the driver’s seat or at least copilot like a rally car co-driver firing off instructions. While including the customer may not always be ideal and can’t always be accomplished, at least include them in the fun parts. The fun part is usually where the magic happens and where we differentiate certain products. If customers aren’t included, these key components could be perceived as smoke and mirrors. Using Splunk as an example, make sure they are involved in the dashboarding process or at least some key visuals defined in my first point. If all goes well, this moment in the process is when the most wonderful questions start to surface. “Can you …….?”

Accomplishing a successful PoC requires a partnership-like relationship with the customer. Understanding the needs of the customer is necessary, but it is nearly impossible without clear communication between the two parties. When no pitfalls occur, proof of concepts can be extremely satisfying and rewarding. 

Check out the "The Macroeconomic Perspective from Hannover Messe: Digital Changes the Balance of Power" guest blog post from Brian Berg, Director at Accenture Strategyto read more about POC work in IoT

Grey Dziuba

Posted by


Show All Tags
Show Less Tags