IOT CATEGORIES
MOST POPULAR TAGS

What IoT can learn from the 19th-century ice trade

What IoT can learn from the 19th-century ice trade

What IoT can learn from the 19th-century ice trade

By Daniel Price

There’s a Three Stooges comedy short filmed in the middle of the 1930s where the boys played ice deliverymen. They pulled up in their horse-drawn cart at an address and saw with dismay that the target house perched atop hundreds of stairs that meandered up a steep hill. Even as late as the 1930s, less prosperous people still received their daily ice in massive blocks — 25 or 50 or 100 pounds apiece — and the term “icebox” is still used by some older Americans to refer to the humming refrigerator in the kitchen. The Stooges hoisted the block ice on their backs with tongs, and marched up the stairs under the throbbing Los Angeles sun. This being a comedy, by the time they arrived at the top, the big blocks had melted into tiny ice cubes.

Much like the ice trade suddenly realizing that the product was not ice, but refrigeration, the IoT industry is realizing that the product development is no longer an aggregation of various separate design and engineering disciplines, but an overall solution that must integrate all facets of IoT design.

The ice trade itself melted just as fast, once the sun of electricity came out.

Ice started as an industry in 1806 (people had been harvesting and storing their own ice for a long, long time). In the 1830s and 40s, the industry supplied Europe, the American South, and the Caribbean. After the American Civil War, it enabled the growth of the Chicago meat-packing industry using ice-packed freight cars, and fresh vegetables from the Midwest now could find East Coast markets. Employing 90,000 people at its height, the industry crashed in the 1930s — just as The Three Stooges were delivering their last ice cubes up the baking hills of Los Angeles in front of the cameras.

We all know that electricity killed the ice trade, but what was the murder weapon?

Having to buy ice upfront by the chunk? Lack of convenience? Loss from melting? Sure. All of the above. In truth, it was the ability of domestic electric refrigeration to align the needs of the consumer with the product provided. The product provided was not ice. Therefore, the quality of the ice wasn’t enough to save it; nor was the frequency of its delivery, nor even the customer service of the company. The product was refrigeration. Suddenly, the ice consumer could pay only for the refrigeration that they needed, not for 100-pound blocks of ice toted up the stairs on the bent backs of workmen. The transition represents a movement away from pay-for-service to pay-for-value.

Now with the growing boom of IoT solutions, we are going to see many examples of new products that intelligently meld to customer’s needs to engender switches from “pay-for-service” to “pay-for-value” models.

However, in this article we are going to zoom into not the end IoT products, but a different space that has been resistant to this transition to “pay-for-value”; this is the development of the IoT products themselves.

Successful design and implementation of new IoT products requires a myriad of development disciplines – software, hardware, mechanical, cloud, mobile, security, etc. The problem here is that if traditional methods of product development are engaged, teams become too big, the upfront cost too high, and the timelines too long. Put simply, the traditional mechanisms for product development do not align with the needs of the IoT product owner to develop in lean manner, to test assumptions as early and as frequently as possible, and to create not a product but a valuable solution to a problem.

Much like the ice trade suddenly realizing that the product was not ice, but refrigeration, the IoT industry is realizing that the product development is no longer an aggregation of various separate design and engineering disciplines, but an overall solution that must integrate all facets of IoT design.

IoT product developers must align themselves with the product owners in the following ways:

  • Development needs to be lean. Large teams of single-discipline developers will lead to a cumbersome development process that is hard to manage. Seek agile, cross-disciplinary teams with a proven track record of success. Further, seek teams that don’t charge high upfront fees without a clear roadmap to productization.
  • Development must be fast. With vast opportunities at stake and the explosive growth of the competitive landscape, time-to-market is critical. Make sure your development team maps out a clear timeline that meets your product needs. Spend as little time in non-form factor prototyping as possible. Get to your first manufactured run, the EVT (Engineering Validation Test) fast. A good team can deliver concept to EVT in three months or less and can set up the supply chain for full production in another three months.
  • Development must have the long-term vision in mind. Importantly, development cannot be done in isolation from the long-term product vision. Make sure the development team understands not just how the product will look and feel, but how it provides value to the end customer as an IoT solution. This will help the development team to develop towards not just a product, but towards a solution.

One upshot of this is that — like electric refrigeration — there will be a transition to incremental “development-as-a-service” models for IoT development. These models will look familiar to us as they will resemble many of today’s SaaS models, but they will have the important effect of aligning IoT product developers, the manufacturers, and parts suppliers, so that as the customer wins, the full supply chain wins.

Grandad may have said “icebox” and meant refrigerator. Very soon, engineers will say “prototyping” and mean something entirely different — something much richer and more complete — than the breadboards we now associate with the term. Possibly 80% of design work will not follow the traditional prototyping route, it will be too slow and too inefficient, and that low-level detail will no longer be necessary.

How much ice are you prepared to pay for?

Daniel is the CEO of Breadware, a company whose mission is to reduce the time, cost, and risk of bringing IoT hardware to production.

Have an opinion? Join the discussion in our LinkedIn group

Many businesses entering the IoT space have not historically been hardware companies. What challenges do they face in product development?