Apple's Craig Federighi & Eddy Cue Open up About the Company's Failures

Companies rarely talk openly about their failures without sugarcoating things a bit and downplaying the aftermath of those shortcomings. So Fast Company‘s lengthy new interview with Apple SVPs Craig Federighi and Eddy Cue comes as a breath of fresh air and a welcome departure from the usual rhetoric of the seemingly infallible — at least in the eyes of Apple’s often cult-like fanbase — Cupertino tech giant. In sitting down with the American business publication, Federighi and Cue are unusually forthcoming about some of Apple’s stumbles over the years — Maps chief among them. Originally launched on iOS back in 2012, Apple’s proprietary web mapping service was derided from the very beginning as a far inferior alternative to Google Maps, and rightfully so — bugs, incorrect directions, and the lack of support for public transport rendered the app borderline useless upon its introduction four years ago. An eye-opening failure for Tim Cook and co., Maps has since progressed nicely and is nearly unrecognizable when compared to 2012’s original — a feat all the more impressive considering Apple was willing to put so much time, energy and manpower into a non-revenue-producing platform.

Below, Federighi and Cue open up on the self-described “huge learning moment” that was Apple Maps’ launch and shed light on how Apple seeks to right its past wrongs.

To check out the interview in its entirety, head on over to Fast Company‘s website.

Let’s start talking about Maps. How are you developing Maps, and how broadly might it apply as Apple looks ahead?
Eddy Cue, SVP of Internet software and services: The first thing to know about Maps is there’s no one developing maps in a significant way except us and Google. There’s Nokia, and then you’ve got TomTom, which is a relatively small company selling to cars. Even when you hear of a company like Uber doing that, everyone is doing it with a very narrow focus. We use maps in a very, very broad way, and so do our customers.

Another thing about Maps is that it just never ends. Every day, businesses are opening and closing, streets are changing, highways are being built. There are short-term things happening, like particular lanes closing, traffic, a bridge being closed. The whole thing is extremely dynamic, which makes it an interesting problem. Most maps that have been done today are almost old-fashioned. It’s all been drive the road, take photos, do satellite images. The only argument has been, how often do you do it?

The advantage of us coming to this later in the game is that, yeah, we have to do some of that, but in order to stay updated we’re trying to use the iPhone itself, and the data it’s giving us. Let me give you a good example: a golf course. How do we know when a new golf course opens up? We’re not exactly driving around looking for golf courses. But we know it’s there, because there are all these golf apps that get used at a golf course. If we see that all these golf apps are being used at a particular location, and we don’t show that as a golf course, we probably have a problem. You can discover that pretty quickly. It’s not as if you need a year, or anything like that.

Do you then have to drive by that golf course?
Cue: It depends. Some things you can do by just going on the Web and checking out whether a golf course exists at that location. You might look at satellite images to see if there had been construction there. In a worst-case scenario, you would have to drive by. You know, airports are the same thing. Runways get developed, but you don’t always really know because many are private. Roads closing, bridges closing—these are really all data problems, because the truth is we don’t really need anyone to tell us that the bridge is closing. The moment a bridge is actually closed, you can immediately see the effect.

Craig Federighi, SVP of software engineering: If all of a sudden the phones stop moving in that direction . . .

Cue: . . . and they start moving in a different direction . . .

Federighi: That’s the kind of thing we do now. So you draw a distinction between that and personal information. Your device may learn your commute patterns, it may learn when you go to the office and when you go home, so that locally on the phone it could tell you that you need to leave early because there’s a lot of traffic on your way home. Well, that’s something that is personal to you and provides value to you, but we don’t want Apple to know when you go to work. So we keep that intelligence on the device, but we can anonymously track things like traffic patterns.

Cue: Here’s another thing about Maps: It’s expensive. We have thousands of people working on Maps.

Doing things like making sure that golf course gets in there?
Cue: It’s that. It’s building the architectures, doing the automation, the intelligence, the amount of data we’re capturing. It’s very, very expensive, and it doesn’t have a direct revenue stream. So when I say it’s only Google and us who are developing it, well, that’s part of the reason why. You can’t be a company going out and developing maps to make money; at least no one’s figured that out.

In the long run, is the service, to me as an Apple customer, simply that I will have up-to-date Maps of my neighborhood and wherever I drive? Or does it get much bigger than that?
Federighi: I think it already is. To Eddy’s point, while Maps isn’t a revenue-producing product itself, it’s a platform. It’s certainly an important feature in terms of the convenience it provides you, but Maps is a platform on which so many of our developers build. If you think about mobility in general, Maps is a core organizing structure for the physical world in which you interact. So many, many third-party apps incorporate mapping, as an understanding of where you are in relation to others, as a way to do all sorts of things—put photos on a map to help you relive a trip, get a heads up about when you need to leave, or see which of your friends is in a certain area. Just as our operating system is a platform or a foundation, having a map of the physical world is a foundation for building all kinds of value on the platform. Our Maps app is just one client of that underlying platform that’s delivered there.

What does it do to the development team, and to your plans, when something like Maps gets introduced and it’s derided immediately. [Maps was introduced in September, 2012, to universal scorn.] Does that slow down what you were hoping to do?
Cue: Well, look, the first thing is that you’re embarrassed. Let’s just deal with that one fact of emotion. I mean, these things mean a lot to us. We work really hard, and so you’re embarrassed. In the case of Maps, what it causes you to do is ask: How important is this? Is this a place where we need to triple down or quadruple down, or did we make that mistake because it’s not that important to us? We had long discussions at the ET [executive team] level about the importance of Maps, where we thought Maps was going in the future, and could we treat it as a third-party app? I mean, we don’t do every app. We’re not trying to create a Facebook app. We think they do a great job. We always came back to the conclusion that Maps was not one of those. It’s an integral part to the whole platform. There were so many features that we wanted to build that are dependent on that technology, and we couldn’t see ourselves being in a position where that was something that we didn’t own.

Federighi: So it was a triple down, and it was a huge learning moment for Apple. Maps presented us with some relatively new challenges, where we needed to develop competencies that we initially didn’t appreciate, areas where we needed some depth, where we needed to take a new approach. We had great approaches for some of the other problems we’d been solving, but this one had some characteristics that meant we had to take some different approaches. So we had to ask: What do we have to learn?

Was the development process of Maps very much in line with the development process of things you’d done in the past?
Federighi: More than it should have been. Maps is a huge data integration and data-quality issue. Eddy talks about the amount of data you have. You’re getting data from a lot of providers, and some of that data is, or should be, changing every day.

Cue: It may not even be right.

Federighi: And much of it is inconsistent. You’ll get a feed from someone who provides information about restaurants, and they’ll refer to location in a different way, in terms of latitude and longitude, from your base map. There’s a huge data-quality issue there, and I don’t think we initially appreciated all the kinds of technology we would need to do that on an ongoing basis. Going through that lesson in a very public way gave us all the motivation we needed to say we’re going to do this really well.

Cue: And look, we made some significant changes to all of our development processes because of it. For example, the reason you as a customer are going to be able to test iOS is because of Maps. We were never able to take it out to a large number of users to get that feedback. So, to all of us living in Cupertino, Maps seemed pretty darn good. Right? The problems weren’t obvious to us. Now we do a lot more betas.