A proof of concept can be the pathway from idea to product. A POC can help a designer (and manager or investor) know if an idea is profitable. For example, when developing IoT smart devices and wireless technologies, a design engineer will have technical or mechanical assumptions to vet as part of determining a product’s viability. To do that, engineers create a prototype that looks and feels like the final product.
With a level-one POC, a designer might focus on new features and test these extensively before implementing them with a prototype. This pre-prototype might look ugly, but if it works, then the designer can create sketches of the model and build a prototype. Level two is a prototype, and a design engineer might obtain commercial-off-the-shelf components and subcomponents to test that the prototype works. The prototype looks and feels like a finished product, and even behaves like the product, but the prototype is built in a lab. The third level is a finished product that’s capable of being put into the field.
In some cases, a client may come to a product designer with a problem. The designer formulates an idea for solving the client’s challenge. And the designer then needs to prove the idea is a good one and build a prototype of the product.
POCs in Practice
Recently, a manufacturer asked Grid Connect to turn its consumer sump pump into a smart device. We brainstormed ideas with the client, including ways to incorporate features in which users could remotely monitor the product’s status to prevent basement flooding. The approach involved reading the product’s consumption of electrical current to detect machine health and status. While the idea showed promise, the idea needed to work in the field.
As a preliminary step, assumptions were evaluated with COTS technology; the prototype in no way looked like the final product. But it was proved that tracking the consumption of electrical current was a way to monitor the product’s status, determine when maintenance was due and even predict failure. A mobile app was developed to display the product’s operating history and activity and track the environmental conditions surrounding the product.
The POC helped designers gain insight about building the smart version of the pump. After applying for a patent to protect the work, additional prototypes were built to gain certification from organizations like UL. The POC was the linchpin for proving the ability to detect motor status (or failure) by reading consumption of electric current.
With a POC, designers should aim for gathering an abundance of data in the field. This helps an engineer discover ways to use the data. With the smart pump POC, lab testing showed the average running time of the pump under specific conditions. But with the POC in the field, variations were revealed. For example, in the lab the POC pump ran continuously, but the same pump in the field ran only a few times a day, for 20-30 sec. per interval.
In another Grid Connect project, the POC examines communications between Bluetooth and Wi-Fi. The finished product will have a chip set on a printed circuit board (PCB). Before designing the PCB and building a prototype, which would be a significant cost, development boards sold by makers of the chip sets were obtained—one for Wi-Fi and another for the Bluetooth chip set. The aim was to see if the communications worked and there was enough code space and memory.
Once the working models were validated, the PCB was designed and the model built with the help of a rapid-prototyping house. Farming out prototyping to a third party saved weeks of development. After building the prototype, a contract manufacturer then built more than the 20 or so units the prototype house constructed for us.
Unless you’re building a product on a specific standard, undertake a proof of concept. A POC doesn’t have to fully construct a product. A designer can mockup the product’s enclosure for its mechanical parts with an inexpensive 3D printer to test some assumptions. If the product includes electronics, the engineer can take evaluation boards and see if there’s compatibility between different modules.
With IoT products, a POC offers ways to cut costs for developing software, firmware and related cloud applications. And while a POC adds to the cost of development, the work saves design engineers, managers and investors from making bad investments.
When justifying a proof of concept, Grid Connect encountered two kinds of customers. The first will focus on the final product. The price of developing a product with a POC (along with any related tooling) isn’t an issue for them. Their aim is selling a quality—but low-cost per unit—product in which they recover development costs through volume of sales. The other type of customer knows their product isn’t a high-volume order. So, if the designer requests a proof of concept, then the customer wants to negotiate the cost and embed the expenditure into the final product’s sale price.
If we build a product, then we embed the cost of the prototype into development of the product. If we build a product for someone else, then our contract includes a clause stating the client agrees to pay for a POC and prototypes.
Sometimes, clients balk at the cost and time to build a prototype and test it. In some cases, we undertake (and pay for) that work ourselves if we’re convinced the idea will turn into something profitable. There are times when it’s not possible to convince a customer to undertake a POC. In those cases, there are two options: eat the cost, or don’t accept the business.
Adam Justice is CEO of Grid Connect, Inc. and co-host of The Smart Home Show podcast. Cristian Codreanu is vice president of Engineering for Grid Connect, Inc. He holds two patents for smart electrical devices and a Master of Science degree from the Academia Tehnica Militara in Bucharest, Romania.