The IoT doesn't need PoCs
I have heard complaints from several Internet of Things (IoT) sales and business leaders about how proofs-of-concept (PoCs) are slowing them down. In some cases, they are just frustrated with how often they are told, “We need to do a PoC,” by a development team in response to a request to begin a new product or offering development. In other cases, they are frustrated with how the tools used for PoCs – development kits or Maker-ware devices like Arduino and Raspberry Pi – prevent them and their customers from deploying scalable solutions once the concept is proven.
Here’s the thing: The IoT doesn’t need PoCs.
I made this statement the other day in a product development team meeting and received looks of shock and disbelief. The company with whom I was working has customers asking for help solving a specific problem and we had a multidisciplinary team reviewing the architecture for a solution. The looks I got said, “How can we begin a product development without a PoC?” The answer is easy when you consider the definition of a PoC.
"Proof of concept is a realization of a certain method or idea to demonstrate its feasibility, or a demonstration in principle, whose purpose is to verify that some concept or theory has the potential of being used. A proof of concept is usually small and may or may not be complete." – Wikipedia
“Feasibility” is the key word here. Feasibility is the role of technology in the Innovation Venn diagram (Figure 1). Is the product technically feasible? Can we even make the innovation function? For the most part, after nearly 15 cycles of Moore’s Law and two generations of the Internet, this means, does the product violate the laws of physics? Today, particularly in the IoT ecosystem, anything is feasible. Further, one could argue that if the product is a pure software or Internet play, it is by definition feasible.
The harder questions for new products today are the other two parts of the Innovation Venn: Is the product desirable? If so, at what price? Is the business viable? These are the tough questions facing new offerings today.
[Figure 1 | The Innovation Venn Diagram]
There’s the rub. A PoC does nothing to address user desirability or business viability. A PoC only addresses technology.
“You’ve just renamed the PoC as a prototype,” you say. But there’s a big difference between the two.
In a PoC the developer is not constrained by manufacturing, costs, or user acceptance. The issue is simple: Can I make this offering work? Maker tools are excellent for this. This is one of the reasons, by the way, that when one looks for Maker products, most of the suppliers are targeting educational organizations. Education is about one example, one proof that something works, one PoC
A prototype, however, is the first iteration of the new product. A prototype is built to a product requirements document (PRD) and that PRD has manufacturing supply chain constraints, certification constraints, user experience needs, and cost expectations. One-off tools like Arduino or Raspberry Pi were not designed for these constraints. So when a product development is started with a PoC and uses Maker tools, the development process comes to halt after the proof. There is no certification path, no manufacturing supply chain, and no ability to meet user experience constraints – particularly where form factor is critical.
The IoT has put a slightly different spin on the product development process because of the addition of an ongoing, user-supported experience. Business models depend upon ongoing revenue, so innovators have to address this need during development. This is the role of the pilot. The pilot puts the product, in a sales-ready format, into the hands of enough users, in context, to measure their adoption of, sustained use of, and willingness to pay for the product. Figure 2 outlines the roles of PoCs, prototypes, and pilots in the product development process. The fastest progression for product development for the IoT is PoC → Prototype(s) → Pilot → Product.
[Figure 2 | The roles of PoCs, prototypes, and pilots in the product development product]
The good news is that good suppliers of the IoT technology stack know that their offerings have to work in production, have to scale, and have to pass rigorous testing. They also know that they have to help product development teams move through prototyping to pilots quickly. The prototypes can get early user feedback and allow forecasts of costs, but the sweet spot of innovation is where users want the new product and are willing to pay a price that sustains the business. In the IoT, sustaining the business is complicated by recurring expense and revenue. This is where the pilot comes in. The pilot validates the product and the business model.
PoCs are not bad, but they are not often necessary in business today. Perhaps the best example this is a place where PoCs are the lifeblood of the company: Google X. Their mission is to make moon shots, learn from failure, and solve grand problems with approaches no one else is willing to try. If your mission is similar, then PoCs are great. If you are under pressure to grow and generate new forms of revenue using digital technology, beware the PoC.Sometimes small changes make a big difference. Switching your organization’s thinking from proof-of-concept to proof-of-innovation (Figure 3) is one of those changes.
[Figure 3 | Proof-of-innovation]
Three ways to tell you are wasting time with a PoC
- Examples of the offering exist in either the lab or with competitors. Note that the example can be in other applications or markets. For example, self-driving cars moved immediately to prototypes because auto-piloted airplanes and drones provided the proof that the technology works for autonomous vehicle operations.
- No new hardware is needed. If your new offering depends upon the integration or is a software application of data, then you are not doing a PoC. Your technology is feasible, it just may not be desirable or viable.
- None of the questions to be answered by the PoC effort involve the laws of physics.
Three things that make a good pilot
- You have a sales-ready user experience. An IoT pilot has to not only measure user adoption, it also has to measure churn. Too much churn will defeat the business. To measure these characteristics with confidence, across a statistically significant number of users, the product must have a sales-ready user experience.
- The product is pre-certification tested. Since the pilot product is not in fact sold, it does not have to be marked, e.g. UL, CE, FCC, etc. But it better be ready to mark. As soon as the pilot validates adoption, churn, and price, the sales team is going want to see products shipping so you can’t go back and do another spin. Be ready.
- The supply chain is solid and meets cost expectations. The pilot will measure user adoption at price so if it is successful production will begin. Production will have to deliver on that price so the supply chain must be solid.