Why We Need to Know Cybernetics // Part II — Resilient Product Design
Product Design & Automation Systems
In the first post of this series, we conducted a short survey of cybernetics, explaining the theory’s importance to understanding how systems shape everything around us, from personal health to disruptions of the global economy.
For this post, let’s look at how cybernetics relates to product design.
My focus on cybernetics is actually an extension to my recent writing on Calm Technology, which is among a higher level set of approaches to the practice. I’d express the hierarchy this way:
- Calm technology relates to our experience of a system, addressing questions of how we can make better processes that enable technology “pass through” and be a part of our lives, as opposed to an interference. (My book expands on a 1996 article by Xerox PARC researchers Mark Weiser and John Seely Brown.)
- Control theory is concerned with how to achieve the desired behavior of a system, given certain inputs and constraints. Crucial to the design of control systems for aircraft, robots, and other complex operations, control theory is about the decisions spaces people operate in, designing them around safety. That way, people don’t have to overthink when using a product and it still performs well.
- Cybernetics focuses on the whole overarching system, including policy, governance, logistics, and ecology, mapping out these pieces to design longer term, holistic systems that have desired outcomes. (Also a way to audit a large system so we can see its limits and opportunities.) It is often used to study and design complex systems employed over a wide range of companies and organizations such as Boston Dynamics, Siemens, and Deloitte.
With all that in mind, let’s look at how this connects with systems design, using the problems with PetNet we covered in Part 1 as a case study.
The Cybernetics of an Automated Pet Feeder
Briefly summarized, PetNet was a well-funded startup which promised to feed customers’ pets while they were away from home; it ran up against a cascade of problems when the third party server which hosted its feeding schedules went down. As a result, many pets were left starving, with no easy way for their traveling owners to care for them.
It was “a textbook case of overestimating or misestimating the entire field of automation (e.g. control theory / engineering),” as my colleague Michael Zargham put it to me recently. “In practice automation systems are multi-layer systems with automation of a day-to-day task on one end, and the ongoing upkeep and maintenance of the automation systems, including failure protocols!” (There’s even a whole hilarious comic about this.)
Mapping Out Failure States to Avoid Them in the Future
Without a mental map of the systems a product depends on, it’s difficult to design contingencies when these processes encounter problems. PetNet’s developers should have applied control systems theory, so that the dogs and cats in the product’s care could be cared for within points of foreseeable turbulence — with backup plans so that they’d still be fed.
Let’s map out how we might look at this from a failure state perspective, starting with the existing PetNet system and the ways in which it can fail:
Our overarching goal is to keep the app working even when it fails, by designing backup systems and removing or minimizing these failure states. Detailing all the particular nodes on this chart (app, feeder, electric grid, Internet connectivity, etc.) the creators of PetNet could have then crossed out the lines where service could be disrupted, and plan accordingly. For instance:
- Is there a local backup system, if power or Internet service is lost?
- Does the backup require batteries, and if so, does it come with a battery status indicator?
- If service is interrupted anywhere on this system, is there a process in place to text or email a warning notice to any affected PetNet owner ?
With PetNet’s control system mapped out in detail, the developers could have created a roadmap of features they would need to truly meet the core promise of their product — feed the owners’ pets when needed, no matter what.
They would have considered backup plans for when something went wrong, and then created a branching pathway to ensure functionality.
It can even be expressed in terms of a To Do list:
Remote Pet Feeder: A Cybernetics Checklist
- Customers should be able to use the system without the mobile app and set it up without the app at all.
- A more resilient model could work in two ways:
- Customers should know how many days the system can be offline and still dispense food, even if the power goes out.
- They should be able to get some sort of notification in an app on a separate server, alerting them whenever the service is down and how long it will take for the backup system to run:
- The service should also be able to work offline if possible and if it absolutely needs an online connection, the server should be multiply hosted by different services so it can route around any disruption.
- There should be backup servers that the app automatically switches to when things go wrong or an outage is detected. This system should be built in a resilient enough way to swap within minutes of an outage.
- If the customer is connected to the web, they should be able to use the system to see if their power is out:
- The app should never be necessary to operate the product.
- The product technology should be maintainable by a third party service. Since PetNet the company has since gone out of business, in this case, all of the feeders no longer work:
- At PetNet’s end of life, they asked customers to pay $4/mo to keep their feeders going.
- Finally, one more resilient way the product could work is to offer a 3rd party human backup system through their local pet store or chain, allowing a pre-authorized trusted party to enter their house and care for their pet if absolutely everything goes wrong.
Creating Cybernetically Harmonious Products
In search of harmoniously designed products, a few years ago I got to meet Jesper Kouthoofd, CEO of teenage engineering while on a trip to Sweden.
teenage engineering is an amazing Swedish company that creates portable synthesizers, drum machines, and other music equipment. They have a cult following because of their usability, innovative design methods, and their focus on portability and ease of use.
Kouthoofd told me that every updated device of theirs is designed to work just like every older model. When some of their first devices that came out — not all of the buttons did anything yet. They were reserved for future use.
teenage engineering totally understands multi-generational design.
A lot of audio systems understand this as well. From supporting MIDI to audio support, most old electronics can be used with new electronics. Devices don’t just stop working because they are a couple of years old. Musicians need to be able to use a device from any era, and musicians and device-makers know that. There is a lot we can learn from music software.
As for PetNet, the startup went out of business shortly after its systemic product failure. The founder is now running another pet-related startup. Hopefully they’ve learned important lessons from PetNet’s outage, but I can’t be certain. The new startup puts pet data on the blockchain (a topic we’ll get into in a later post)!
Products often fail not simply because their fail states weren’t mapped out in advance. Typically, that happens because they were created by a startup which didn’t have its own structural fail states mapped out either.
Let’s talk about that in Part 3.
