Smart Connected Product – Failed PoC? Next step..

A typical proof of concept usually covers technical feasibility of the concept within a context.  The definition of the PoC would be as trivial as the naivety of the proposer.

Rarely enough the definition of the PoC is comprehensive enough to include reliability, cost, scale, security, quality of data, etc. Some other times even the business value of IoT enablement is not well thought of.

While the PoC exercise achieves whatever was slated as the original plan, it sometimes fails to achieve the undefined that was perceived by various teams.   Some or all these points contribute to the misalignment of all the decision makers and as a result, the project is declared a failure.

Is this a failure?  Not really.

A set of assumptions about the final product that was put to test was proved.  So it’s actually quite a success.

The problem is, people don’t realize that a PoC is not really a Prototype.  While a POC is focused on one product aspect and gives a model around the same, a prototype is a more holistic working model of several aspects of the product.   So, when earlier in this article I mentioned the PoC definition is not comprehensive; it really doesn’t need to be.

One must be clear what he/she is up to and beware of changing goal post.  If you have started with an idea of IoT enable your existing product and demonstrate a few used cases; realize that you might not be in a position to answer few of the production and marketing team questions.  You might not have considered what would be delta to the production cost.  You might not have considered how to monetize and who is going to pay for the new features.

Once you are done with a PoC and you achieve what you originally slated, it’s time to analyze whether you have any more questions to answer or any other aspects to be modeled.  There are two paths to proceed –

• If you are still in a stage of convincing internal customers/self, build a prototype of your smart connected product. Build an end-to-end working model covering the aspects that you would like to validate. Include production grade hardware (sensors, boards, battery/power etc.), evaluate and select the right platform that is conducive to your scalability, availability and performance requirement and build the required interface to the business systems.
• Build an MVP (Minimum Viable Product) if you are sure about the features and would like to grab the market early. The purpose of building an MVP is to get the minimum version of the product to the market. This way you’ll get to know whether it has any value at all. And if it does, you can start making money right away from your first customers, the early adopters.