Deconstruction: Breaking Down a Connected Strategy into a Set of Functions

Technologies do not have value per se; users derive value from the technology performing a specific function. We can think of a function as the purpose of the technology. The purpose of the technology answers the what question (what does the technology do?). In our example, Kayla does not care whether it is a smart door with face recognition and an automatic lock that lets her in or her mother who does it. In the same way, the cleanliness of the house is what matters, whether achieved through Roomba or a member of the household with a broom or vacuum cleaner.

Once we are clear about the what, we can turn our attention to the how (how does the technology work?). Functions are performed by devices, pieces of software, or people following a workflow. Sometimes the functions are performed by the customer themselves, as was the case when Bill did his own grocery shopping and virtually everything else in his scenario.

The first thing you should do when exposed to a set of technology buzzwords in the context of connected technology is to forget about the how and focus on the what. In any connected relationship, there are many whats, so we need to focus on something more specific. We focus by deconstructing the connected strategy into a set of required subfunctions. Deconstructing a problem means breaking it up into smaller, manageable subproblems and solving those first.

We find it helpful to deconstruct a connected strategy based on two dimensions. The first dimension captures all the functions that need to be carried out within the two building blocks of a connected strategy: the connected customer relationship and the connected delivery model. In this first dimension, as we saw in chapters 4 and 5, the connected customer relationship consists of four pieces:

Recognize concerns becoming aware of the need in the first place.

Request includes the search and decision-making process, the placement of the order, and the processing of the payment.

Respond captures those functions required so that the customer can receive the product or service, experience it, and be connected to any form of after-sales support.

Repeat encapsulates all the functions that allow the firm to learn continually from the repeated interactions it has with its customers.

Within the connected delivery model, as described in chapters 7 and 8, we need the following:

The functions required to establish and support the connection architecture, which means the connections among the firm and its suppliers and ecosystem. For example, this could be a link to a supplier for a connected retailer or a reputation scoring of an individual within a peer-to-peer network.

The functions required to establish and support the chosen revenue model. This could include measuring use time, assessing the performance of the product, or transmitting data to other ecosystem members.

The second dimension of deconstruction takes each function, such as identifying a person, making a payment, or shipping a good, and breaks it up further into four types of subfunctions: sensing, transmitting, analyzing, and reacting.

Why those four? To illustrate, let’s return to our connected home scenario, this time focusing on the thermostat. To avoid excessive air conditioning, which is both uncomfortable and wasteful, four functions need to be completed. The current temperature needs to be sensed, it needs to be transmitted from the sensor to a decision-making unit, that unit analyzes the information and makes a decision, and then somebody or some device needs to react by executing the decision. This creates a feedback loop common to all connected technologies: sense-transmit-analyze-react, with the acronym STAR.

We can now combine the two dimensions into a table, as is shown in table 9-1. The columns capture the different elements of the connected strategy: recognize, request, respond, and repeat, plus the connection architecture and revenue model. The rows capture the four dimensions of STAR: sense, transmit, analyze, and react. We can use the table to catalog the many subfunctions needed to create a connected strategy, as table 9-1 shows for Aruna’s coffee consumption.

Consider the first column, recognize. One subtask is to sense that Aruna has only twenty grams of coffee left. This quantity information then has to be transmitted to a cloud or edge computer (a computing device sitting close to the information source). There it must be analyzed to answer the question whether the amount left is less than the desired minimum quantity of fifty grams. Lastly, the system must react and start the request module (next column) to reorder the coffee.

Or consider the last column, revenue model. Assume the coffeemaker didn’t charge Aruna up front for the machine but charges her a daily fee that includes a guarantee that the machine will have an uptime of 100 percent. To implement this revenue model, it is imperative to sense the maintenance needs of the coffeemaker on a continuous basis. This status information must be transmitted to the coffee machine’s service provider. This information is then analyzed and a decision made about when to replace the machine. And lastly, the firm must react and ship a replacement machine once the old one shows signs of wear.

As we have shown in table 9-1, each function of a connected strategy can be broken down into further subfunctions using the STAR approach. At the end of this deconstruction, you have a set of very specific subfunctions. Each subfunction, in turn, corresponds to an engineering problem. In other words, you have a job to be done and now can look at available technologies to perform it effectively. (For another example of the STAR approach, see the sidebar.)

Functions Are Performed by a Technology Stack

Returning to Aruna’s connected home, let’s look at what needs to be in place for the door to open conveniently on her arrival. We need a camera at her door, transmission technology to send the video stream, and a computing device that takes the incoming data and sends a signal to a locking mechanism that opens the door or keeps it shut. We can identify people by capturing their biometrics (facial images, fingerprints, eye scans), by having them enter a user ID and password, or by sensing the proximity of a device such as a key or a phone. If we drill down on face recognition, options include 2-D and 3-D image processing. Within 3-D image processing, we can further distinguish methods of face recognition that rely on unsupervised deep learning methodologies using neural networks and other methods that work based on the predefined geometric patterns of faces.

Chances are that you are not that interested in the nuts and bolts of unsupervised deep learning methodologies using neural networks. You just want Aruna’s door to open when she arrives but remain closed to everyone else. To delineate the underlying technologies, their functioning, and the business services they perform, it is helpful to think of technologies in the form of a stack consisting of hierarchical layers.

TABLE 9-1
Two dimensions for deconstructing a connected strategy
		Recognize		Request						Respond						Repeat		Connection architecture		Revenue model
		Become aware of the need		Search and decide on option		Order		Pay		Receive		Experience		After sale		Learn and improve		Connect parties in ecosystem		Monetize customer relationship
Sense		Notice the amount of coffee left in the pantry		Receive information about current coffee prices from nearby retailers		Make sure the desired item is available		Check current cash balance in bank account		Notice arrival of delivery		Notice home owner approaching the front door		Measure change of heart rate and pupil dilation after first sip of coffee		Identify the user whenever she drinks coffee, regardless of location		Sense ordering needs of nearby homes		Check the functionality of the coffeemaker
Transmit		Send quantity information to computing system		Get those prices onto the central system		Send order to retailer		Combine account status with projected grocery orders		Send identity information to central system		Send arrival information from door to server		Send information to edge computing system		Send identity and preference information to central system		Pool neighborhood information to one server		Send status report about coffeemaker to service provider
Analyze		Compare with target quantities		Look at prices and volume discounts, potentially factoring in travel plans		If desired item is not available from preferred source, find best alternative		Look for potential account overruns and possible loyalty rewards		Make sure that delivery has been authorized		Identify the person in front of the door		Assess delight of user with coffee brand using physiological measurements		Analyze coffee preferences—e.g., depending on time of day		Evaluate eligibility for group discounts		Make decision when to send coffeemaker replacement
React		Decide it is time to start the request module for reordering		Activate order module		Place order for a particular item and provide shipping address		Execute payment		Provide access to pantry or coffee machine		Open the door and activate coffee brewing		Feed results into repeat module		Feed results into request module and help coffee roasters to improve their product		Negotiate special price with retailer		Send coffee machine replacement when necessary
Note: Each cell corresponds to a specific subfunction in the coffee-brewing scenario. The table is best read column by column.

The most technical layers are at the bottom of the stack. For instance, the lowest level might be about the physical transmission of bits from one device to another. At this layer, you are talking about volts or frequency and worry about signal strength or network topology. The next layer up in the stack takes these capabilities as given. You know that bits somehow will get from one device to the other, so you can turn your attention to creating connections, which might involve establishing and ending connections between two devices through a protocol. The next layer might be concerned with sending data packages through a network using sender and receiver addresses, and so on. At the top of the stack is the application layer, which is closest to the end user.

The beauty of any stack model is that the user can ignore the lower layers in the stack, just as you can drive a car without knowing how a combustion engine works. Stacks create clear interfaces and layers of abstraction. As somebody building connected strategies, you can decide for yourself how deep down into the stack you want or need to go.

The collaboration between Steve Jobs and Steve Wozniak illustrates how much you need to know about the lower layers of the technology stack (and how far you can advance in your career by excelling at the top layers). In the early days of Apple, Jobs was the visionary imagining user experiences. He was primarily concerned about the higher layers in the stack, while Wozniak was the engineer who made it happen, which required him to dive into all the technical details lower in the stack. The focus on the user experience and the willingness to abstract from engineering details at lower levels stayed with Jobs throughout his career, including through the development of iconic products such as the iPod, the iPhone, and the iPad. Don’t get us wrong: to make a connected strategy happen, somebody has to go deep down into the technology stack, but that somebody might not have to be you.

Functions Can Be Carried Out by Alternative Technologies

As you go down the stack, moving from user experience into technical details, you have design options. There almost always exists a set of alternatives to implement a function. Because this is not an engineering book, our focus is on the application level of the stack (“How can we recognize a person?”), though the logic applies to any level (“How can I transfer ten megabits per second over a distance of five meters?”).

Let’s look at a subfunction from table 9-1 and think about alternatives for implementing this function. Again, let’s pick the subfunction “identify a person” and systematically explore our design options. A great tool to advance that exploration is the classification tree in figure 9-1.

A classification tree takes the space of all possible solutions and breaks them up into different categories. When it comes to recognizing a person, we can, at the highest level, distinguish between human solutions (a doorman or Kayla’s mother) and automated solutions. Automated solutions can be further broken up into those that require user action and those that don’t. And so on …

The classification tree helps you be systematic in your exploration of technological options and your discussions with engineers.

To populate the classification tree, we find it helpful not only to generate alternatives internally but also to look at how a subfunction is performed by other firms, especially firms outside your own industry. Consider the following example: While writing this book, one of our friends had a BMW that required maintenance. When the maintenance was completed, she was called by the BMW dealership and notified that the car was ready for pickup. She took a cab to the dealership, checked in, and was informed that the car was indeed ready and an employee would retrieve it from the off-site parking lot. Fifteen minutes later, the car arrived.

FIGURE 9-1

Classification tree for the subfunction “identify a person”

What other alternatives exist to implement the subfunction we could call “product handoff”? Let’s look beyond car dealerships and contrast BMW’s implementation with how Wawa, a convenience store chain in the mid-Atlantic region known for great made-to-order food, performs basically the same subfunction. At Wawa, you can order a sandwich through an app and then pick it up at the store (a respond-to-desire customer relationship, as we discussed in chapter 4). Since you want your meal to be fresh when you pick it up, Wawa uses geo-fencing with the customer’s phone to sense proximity and have the food ready on arrival. Preparing it just in time creates a magical user experience. With this kind of service, a regional convenience store selling $5 sandwiches outperforms a global automaker selling $50,000 cars.

To further emphasize the power of this approach, recall our Disney example from the beginning of the book. Disney did not create the connected bracelet. Instead, Disney found this technology in hospital settings. The lesson is that, in almost all cases, companies already exist that have done a great job implementing a particular subfunction. Your job is to learn from the best, not to reinvent the wheel. This simple yet powerful observation also gets us back to Steve Jobs. He did not invent the graphical user interface when he and Wozniak launched the Mac. This function was created by Xerox PARC, which is where Jobs first saw it and, quickly scaling his mental classification tree, realized what could be done with it.

The output of the classification tree is a list of design alternatives. This list can be summarized in a selection table, as is shown in table 9-2. The selection table takes the design options as its rows and compares them along a set of dimensions—in our case, performance, cost, existing applications, and other comments. For illustration, we further divided performance into the subdimensions of user convenience and safety or reliability. Each option is then rated relative to the other options along each dimension.

TABLE 9-2
Selection of alternatives for “identify person” subfunction
Technology		Convenience		Safety/reliability		Cost		Applied in …		Comments
Human at door		++		++		– –		Hotels
Human remote		+		+		–		Building access
Key card		–		++		+		Hospitals
Enter pin code		–		–		++		Gym
Fingerprint		–		++		+		Phone
Eye scan		– –		++		–		Global border entry
Sense device proximity using near-field communication		++		+		+		Car keys
Sense device proximity using Bluetooth		++		+		+		Wawa
2-D face recognition		++		+		+		Hotels
3-D face recognition		++		++		+		High-end phone
Combination of step pattern and smell		++		?		– –		Security dog		Technically not yet feasible
Notes: ++ = very good; + = good; – = poor; – – = very poor; ? = unknown.

Bottom-Up Innovation by Moving up the Stack

It is interesting to see how a stack changes over time. Consider Amazon’s Alexa, which was helping Aruna prepare coffee. At the top of the stack, the level of the user experience, sits a function we could label voice recognition. Voice recognition is what voice recognition software does, but how it does this is a matter for the lower levels of the stack.

Looking only at the stack’s top layer, one might say, “Voice recognition has been around forever,” a valid statement since companies like Bell Labs and IBM experimented with it over a half century ago. For example, at the 1962 World’s Fair in Seattle, IBM revealed a device called the IBM Shoebox, a computer the size of (you guessed it) a shoebox that had a revolutionary capability. The device had ten small lamps and a microphone. If somebody said “seven,” then lamp number 7 would light up. If somebody said “four,” lamp number 4 would light up, and so on. Engineers envisioned that we could soon dial a telephone number through voice commands.

Voice recognition was further improved with advances in computing technology. In the 1980s, a new approach to voice recognition emerged using a method known as hidden Markov chains. This technology would not simply listen to the sound and then try to match the sound with a word from a library, it would also factor in the probability of the word occurring by analyzing the words preceding it. If the previous word was grand, it is more likely that the following word will be son rather than sun.

The first mass-market application of voice recognition came with the software Dragon Dictate, a product initially retailing for some $9,000 and requiring substantial training to acclimate to the voice of a user. Dragon’s software improved throughout the 1990s to require less training and sold at lower costs.

As computers gained increased processing power, voice recognition was built into more applications. You might be surprised to learn that both Microsoft Windows and Apple’s Mac OS had voice recognition built in by the early 2000s. If you had a computer back then, most likely you did not use that feature because it was practically useless—unreliable and slower than just moving your mouse. So, voice recognition remained a niche market, constrained by its limited accuracy.

The breakthrough came in 2010 when Google added voice search to Android phones and Siri appeared as an iOS app the same year. Enabled by the internet, Google and Apple captured the voices of millions of users who performed billions of queries, every one of them adding to their library of spoken words, making voice recognition what it is today.

The story of voice recognition demonstrates how improved functionality, greater accuracy, less training, and lower cost are a result of new technologies happening deep down in the stack. Hidden Markov chains, more processing power, and the internet—none of these technological advances was related to voice recognition. But as new technologies become available that impact layers deep down in the stack, they improve the execution of a function at the technical level. This improvement then bubbles up through the layers of the stack, enabling better functionality at lower costs in the application layer at the top of the stack. An example is the recent success of electric cars. Enabled by better battery technology deep down in the stack, electric cars now have become competitive with combustion engines. The driving does not change, but the user gets faster acceleration and a lower carbon footprint because of the advances in technology.

Technologies bubbling up in the stack and enabling new functionality at the application layer have an important consequence for the design and origin of your connected strategy. So far, we have described a top-down process: you create a vision for a connected strategy, you deconstruct it into subfunctions, and you look for technical solutions for each subfunction. A complementary way to create new connected strategies is from the bottom up. You spot a new technology and ask yourself, “Which application will be significantly improved if I introduce this technology to the stack?” In these innovation efforts, we start with the how, look for substantial advances in performance or cost reductions, and then ask the modified what question: “What new user experiences are enabled by this technological advance?” For two business-to-business examples, see the two sidebars on digital twins and drone delivery.

Innovative Business Models Don’t Necessarily Require New Technologies

The key lesson of this chapter is that you can create innovative connected strategies without being a technology expert. You start with the business vision and then work from there, including deconstructing the customer journey into a set of subfunctions and then broadly exploring alternatives for each of them using classification trees. Alternatively, you may notice that technological advances have occurred that enable you to solve subfunctions in a better or more cost-effective way, allowing you to create new connected strategies.

In the process of populating the classification trees, you want to look for best practices for a particular subfunction both inside and outside your industry. Just cherry-pick what works well: pick a “sensing person arrival” subfunction from the hotel industry; pick “3-D face recognition” from a phone security system; and pick “execute payment” from a peer-to-peer payment platform. Then combine those pieces as you envision your own connected strategy.

You might view this approach of primarily relying on existing technological solutions as lacking in vision—where’s the originality? It seems somewhat risk averse, shying away from technological breakthroughs. We propose that this approach is a strength, not a weakness. First, the originality is often in the use of the technology, not the technology itself. Ride-hailing companies did not develop GPS, cell phones, or Google Maps, but using these technologies allowed them to create a new connected strategy. Second, technology is improving so quickly that new solutions arise all the time. Thus, the best implementation of a particular subfunction is always a moving target. And third, relying on existing technologies can reduce risk. The history books on technology are full of failures. Many of them were costly, especially in those cases in which firms tried to deliver too much too soon.

Also, notice that our framework allows for more visionary thinking than might appear to be the case initially. When Amazon announced its potential usage of drones around 2016, the business world was in awe. As we show in the sidebar, delivery of consumer packages by drone might indeed be a novel way to implement the subfunction “rapid delivery.” It might seem original; however, the military has long relied on drone technology, and drones have been used to deliver medication replenishment in rural Africa. A novel solution can come from the application of existing technologies in new settings. It does not always require fundamentally new technologies.

Finally, if you desire a visionary connected relationship that relies on yet-to-be-invented technology, we advise you to check out your local library’s science fiction section. Sound crazy? Consider a detail in the history of the MagicBand we have not shared so far. We mentioned that Disney executives were inspired by hospitals where dementia patients were tracked using bracelets. But from where did the hospital executives get the idea?

The story of tracking people goes back to an old Spiderman comic strip from the 1960s in which Spiderman is forced by his evil enemy, Kingpin, to wear what is described as an “oversized ID bracelet in the form of an electronic radar device.” In 1983, Judge Jack Love of Albuquerque, New Mexico, initiated the first judicially sanctioned use of monitoring devices. Inspired by the comic strip, Love envisioned defendants under house arrest or on parole wearing an ankle monitor that would signal its location. The world of science fiction has a long and remarkable track record of envisioning new functions before even the first technical applications exist. So keep on reading those comics and don’t miss the next James Bond movie.