NPR and Edison Research have been putting together The Smart Audio Report. The study, presented at CES in January, gives a good look into how quickly smart speakers like Alexa and Google Home are entering the home:
It’s growing fast: 16% of Americans have a smart speaker − 128% growth since January 2017
Usage is growing over time:84% use their speaker the same amount or more than the first month they owned it
They’re becoming embedded into people’s lives: 65% say that they would not like to go back to life without their smart speaker
The most interesting chart is a breakdown of the most frequently used activities by the time of day.
I haven’t done many of these things but I look forward to finding out more about them!
I was recently on an airplane with a hotel entrepreneur. His family had immigrated to the US about 20 years ago and they decided to enter the hotel industry. Being new entrants to hospitality, they started with lower quality airport motels (e.g., Econolodge) and gradually moved up to more premium hotels (e.g., Marriott).
I had always assumed that a hotel with a better brand made more money for the owner. I was surprised to learn that this wasn’t necessarily true. Premium hotels are priced higher but these higher prices are eaten up by higher costs in service, staffing and quality of amenities (e.g., beds).
However, it’s generally easier to run a premium hotel. For example, the guests are better behaved, despite their bad rap for being overbearing and demanding perfect levels of service. Guests at economy hotels bring bad behavior to a whole new level. My new friend told me about having to break up fights between guests or calming down a customer who was threatening one of his front office staff with racist remarks. People are much more likely to treat the hotel property poorly and even break things in an economy hotel. This leads to additional costs.
One of the worst problems in economy hotels was bedbugs — and not the way you’d think. Customers who already have bedbug problems at home would check into his hotel. Then they would smuggle in some of their bedbug-infested linens into the hotel room. Then they’d check out and wait a few days for the bedbugs to entrench themselves in the hotel room. Then they’d sue the hotel and say that their house became infested with bedbugs because of the hotel. So now the hotel has a room with bedbugs and a lawsuit to deal with.
But stuff like that doesn’t happen at a Mariott (at least I hope it doesn’t). Hotels with premium brands set expectations on the customer experience —price, quality and customer behavior. Put another way, the brand provides a level of trust to the traveler that they will have a good experience.
So what does this have to do with Airbnb? For years, staying at a hotel was the only way that a traveler could trust that they would get a good experience. So when Airbnb came along, most people rejected the idea. In fact, Airbnb was rejected for seed funding by the first seven investors that they approached. I remember hearing that Airbnb was a combination of the two worst ideas in Silicon Valley:
In short, there are commodity suppliers and integrated suppliers in the value chain. The integrated suppliers are the ones that make the big profits. In the original PC business, IBM was the integrated supplier, with its brand and its proprietary components, and everyone else was a commodity supplier. But it’s possible to change the game and commoditize others in the value chain take the profits for yourself. This is what Microsoft did to IBM. Who thought that the OS provider could commoditize the hardware provider — but they did.
Now let’s look at Airbnb. Travelers have the same needs that they’ve always had. They want a place to stay that’s comfortable and safe that’s somewhere close to the activities that they want to do. So how can a supplier deliver a great experience to the traveler? Before Airbnb, hotels needed to own the whole building (or have a franchisee own it). They would deliver a consistent experience by having a set of corporate standards that represented the brand. So a traveler knew exactly what to expect when they went to a Mariott Courtyard.
However, with Airbnb, the company can set expectations for the traveler during the booking and reservation process. Instead of focusing on broad standards like bed type, free breakfasts, and free Wi-Fi, Airbnb can focus on individual customer experiences for each room that’s rented out. This lets Airbnb commoditize (sometimes called modularizing) the experience of each individual room and still maintain a consistent Airbnb experience. It also let’s Airbnb source from much smaller and diverse suppliers who have extra rooms. So Airbnb becomes the most important player in the experience and therefore the most valuable component in the value chain.
I can’t speak for your mother-in-law, but I find this fascinating. Do the testing of problems actually slow down the system, much like as if I were changing a flat tire every week?
What A good question Marc! It’s a question that many people have but rarely ask. This type of testing does slow down the system a little, but the benefits outweigh the costs. It’s like asking “Doesn’t sleeping 8 hours a day make you less efficient? Wouldn’t you be more efficient if you worked the whole 24 hours?”
The key is that failure is baked into this model. Think about if you have 1000 wheels on the car instead of 4. Now each of these wheels is rated to be replaced every 3 years. So each day you can expect about one tire to go flat a day. But that’s on average.
One wheel breaking every day is a pretty easy thing to recover from. But if you have 1000 tires, some crazy things could happen that are very hard to predict ahead of time. What happens if multiple tires go out? What happens if three tires go out that are next to each other? What happens if the front right tire and the front left tire go out at the same time?
It’s much more complicated in Netflix’s case because you have many different types of systems that are interdependent. That’s why Netflix tests all these different contingencies. Yes, there’s a slight overhead in doing this but it allows you to ensure that the system is robust. Also, Netflix wants to make sure that if any single component fails, the system degrades gracefully. For example, if the recommendations system goes down, Netflix should display generic recommendations like new movies or fan favorites and everything else should work fine.
What we’re really talking about is humility in our ability to design a system perfectly up front. In order to run a system at 100% optimal efficiency, you’d need to be able to predict everything that could go wrong and also what may unexpectedly change in the future. For a long time, people have worked hard at making this planning process better. However, trying to make the planning process perfect starts to take more and more time and cuts into the efficiency of the project. Also, and this may be obvious, it’s impossible to plan perfectly for the future.
This is why most software development is moving from a traditional “waterfall” design to a more “agile” design. People used to think that you should build software like you build a building. This was called “waterfall” because you start at the top with your strategy and that design flows down all the way into execution. You make highly detailed plans and then take years to build it. However, we’ve realized over the years that we can solve most key business problems without building the whole software project — we just build the parts that matter. Also, people can start using the software before it’s done — which lets us revise the plans on a regular basis as we see how it’s used. We’re accepting that we don’t know the total plan. We have an idea of where we want to go in five years, but we only know what we’re building over the next few months.
But why does agile work? Isn’t it more efficient to do all the planning first and then build it? Yes. But not in a way you think. The waterfall method is more efficient for software; however, it’s not what’s best to get the job done. When people start a project, they don’t actually know everything that the product needs to do up front. They wish they could know 100% of the system in the beginning but they never actually do that. Think about trying to design a user interface five years ago. Would you even have considered building a voice interface like Amazon’s Alexa? Of course not. So if you built your 5-year-product roadmap, it wouldn’t have even considered a voice interface.
This idea of breaking projects down into small parts goes beyond software. Bent Flyvbjerg (researcher in project planning with a super awesome name) has found that larger projects are more likely to have cost overruns. However, it’s not necessarily about the size of the project itself, it’s much more related to the size of the segment of the project. Public works projects like building a bridge or a dam, which can only be built in one large chunk, are more likely to have cost overruns than a road, which can be built in small segments.
In this post, I’m trying to take something technical and make it (mostly) readable for my mother-in-law. Enjoy!
One big trend, especially for internet companies like Facebook, Google and Netflix, is not to have one massive computer anymore. This is an oversimplification but computers used to be one big expensive box. The faster the computer you needed, the more money you spent. But eventually, the computers became too expensive to possibly meet the needs of today’s internet companies. So Netflix (and others) started stitching together these large supercomputers out of many smaller and cheaper computers by connecting them in these clever ways.
The benefits of doing this are pretty amazing because they allow you to get this supercomputer that can do incredible things that are very low cost. The problem is with each of the smaller computers. Because they’re so cheap, they can fail at any time. This means that Netflix has computers failing constantly. But customers don’t see this happening. So how does Netflix get this to work?
Imagine getting a flat tire. Even if you have a spare tire in your trunk, do you know if it is inflated? Do you have the tools to change it? And, most importantly, do you remember how to do it right? One way to make sure you can deal with a flat tire on the freeway, in the rain, in the middle of the night is to poke a hole in your tire once a week in your driveway on a Sunday afternoon and go through the drill of replacing it. This is expensive and time-consuming in the real world, but can be (almost) free and automated in the cloud.
This was our philosophy when we built Chaos Monkey, a tool that randomly disables our production instances to make sure we can survive this common type of failure without any customer impact. The name comes from the idea of unleashing a wild monkey with a weapon in your data center (or cloud region) to randomly shoot down instances and chew through cables — all the while we continue serving our customers without interruption. By running Chaos Monkey in the middle of a business day, in a carefully monitored environment with engineers standing by to address any problems, we can still learn the lessons about the weaknesses of our system, and build automatic recovery mechanisms to deal with them. So next time an instance fails at 3 am on a Sunday, we won’t even notice.
In addition to Chaos Monkey, Netflix has a number of other members of the Simian Army. The Netflix descriptions of these fellows is a bit technical:
Latency Monkey induces artificial delays in our RESTful client-server communication layer to simulate service degradation and measures if upstream services respond appropriately. In addition, by making very large delays, we can simulate a node or even an entire service downtime (and test our ability to survive it) without physically bringing these instances down. This can be particularly useful when testing the fault-tolerance of a new service by simulating the failure of its dependencies, without making these dependencies unavailable to the rest of the system.
Chaos Gorilla is similar to Chaos Monkey, but simulates an outage of an entire Amazon availability zone. We want to verify that our services automatically re-balance to the functional availability zones without user-visible impact or manual intervention.