Tag: Technology

Categories
Product Management Uncategorized

The Secret to Google’s Self Driving Cars — Google Street View

For decades the US military was trying to create self-driving cars with little success. Once the private sector got into the game, these cars improved at a breakneck speed. In 2004, when the first DARPA Grand Challenge took place, no car in the world was able to complete the 150 mile course through the Mojave desert.  By 2016, self driving cars had driven over a million miles in regular traffic. The secret was not better computers or better cameras. The secret was better maps.

Peter Norvig, Google’s head of research, told the New York Times that Google Street View is the secret sauce behind Google’s self driving cars. He said:

It’s a hard problem for computer vision and artificial intelligence to pick a traffic light out of a scene and determine if it is red, yellow or green. But it is trivially easy to recognize the color of a traffic light that you already know is there.

I remember hearing that and thinking how convenient it was that Google happened to have Street View and that they could apply it to self driving cars. This would have been a classic case of “unlocking the power of data.” But then I learned the rest of the story.

Sebastian Thrun is the creator of Google’s self driving car and the founder of Google’s “X” lab. Google didn’t just “happen” to have Street View data lying around. Street View was created by Thrun after he met Larry Page at the DARPA Grand Challenge — the self driving car race. Thrun tells the story on CNBC’s The Brave Ones:

Larry came to the race itself and … came disguised with, like, a hat and sunglasses so he wouldn’t be bothered by everybody. But … he had a keen interest in this. Larry has been a believer in this technology for much longer than I even knew. And so was Sergey (Brin). And they really want to understand what’s going on,” Thrun said.

A later iteration of the car had cameras attached to its roof, so the team could review its progress each day, leading almost by accident to the development of Google Street View.

“We realized the video’s actually amazing. And we went to Google and said ‘we’d love to help you build Street View.’ And we kind of ended up – felt like an acquisition of a little start-up company, kind of Stanford transitioning into Google where me and four of my grad students then became Street View enthusiasts.”

“And we built up Street View and with a singular vision to photograph every street in the world.”

Street View became the first project within the secret Google X. “We had a separate building that no one knew about. At least for a year and a half, no one in Google had a clue we existed,” Thrun said.

So what did we learn? Data was the secret sauce for getting self driving cars to progress as well as they have. But it wasn’t a matter of finding a data set and applying it. It was about creating the data set for that specific purpose. Street View wasn’t a useful data set that was applied to self driving cars. It was the output of the mapping exercise that made self driving cars work so well.

One final addendum: When talking about Google Street View I have to add a link to an early version of Street View from 1979 that was created at MIT. The Aspen Movie Map (movie) used laserdiscs to simulate driving through the town of Aspen.

Categories
Product Management

Smart Audio is Here to Stay: Some Takeaways from NPR’s Smart Audio Report

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!

Categories
Product Management

What Does a Hotel Brand Stand for? How Airbnb Changed the Game

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:

  1. Staying in the home of a stranger
  2. Renting out your spare room to a stranger

In his excellent site Stratechery, Ben Thompson talks about how Airbnb (and others) changed the game. It starts off with something called the Law of Conservation of Attractive Profits that Clayton Christianson wrote about in his book The Innovator’s Solution.

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.

Graphical Depiction of the Law of Conservation of Attractive Profits from Stratechery.com

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.

How Airbnb Altered the Hospitality Value Chain, Allowing It to Take Outsized Profits from Stratechery.com

To learn more about how this all works check out Ben Thompson’s writing on Aggregator Theory at Stratechery.com.

Categories
Product Management

Reader Question: Don’t Chaos Monkeys Slow Things Down?

Today’s reader question comes from Marc about my article on Chaos Monkeys and the Simian Army.

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?

— Marc 

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.

Categories
MIL Guide to Technology Product Management

The Mother-in-Law’s Guide to Chaos Engineering

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?

Netflix needs to make sure that of all its computers and systems are resilient. Using a car metaphor, Netflix is always able to swap out a spare tire if one gets a flat. On their blog, Netflix explains how they test this tire changing/computer failing problem:

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.