It’s not often one gets to work on a product with a billion anything. I’m extremely fortunate to have had the opportunity to design/invent/iterate in the earliest days of at least three products in that league, and I’ve learned from others who have had more.
Here, I’m going to focus on Google Earth, which has well over a billion users, thanks to Google’s scale. I’ll pick examples from my experience to help illustrate the lessons.
Before I get into the details, a small credit roll. If you look at the thousands of people who have worked at Keyhole and then Google Earth over the years, my contribution would equal less than 0.1% of the total human effort. And that’s not even including some key individual contributions from Chris Tanner, John Hanke, Brian McClendon, Michael Jones, David Kornmann, Dave Lorenzini, Phil Keslin, Mark Aubin, Chikai Ohazama and more. Without all of these people, the product would arguably not have existed or would have otherwise died.
That said, I should explain a little of what I did from 1999 to early 2001:
- as Keyhole’s co-founder and Director of Client, I crafted the consumer product from design to prototype, including the fun user experience we still see, the UI, and many aspects of how the earth is rendered, some that were only recently re-added.
- developed algorithms to efficiently manage all that content, so the 3D rendering was faster than anything people had seen thus far and it worked over a 56k modem. (note: Chris’ virtual texture management was the first key enabler here)
- added markup and prototyping, turning a basic 3D globe app into an open 3D web browser, where everyone could bring their own content (like the web itself).
Most of that was laid down in the first 12 months of the product’s life, and I think it had a lot to do with its near universal appeal. And yet there were a few things I notably failed at:
- revenue — my best idea was a spatial “adwords,” where companies would bid to have their names or logos show up sooner when zooming in. But we never built it.
- that original brown-gadget app skin wasn’t my design, but I could have fought harder to replace it (see “pick your battles,” below)
Well, it is what it is. And the point of this article is to discuss how anyone could and should do the same or better, given the opportunity. I hope this is useful to someone.
Lesson One: “Fail Fast” is Bullshit, but do Kill your Darlings.
“Fail Fast” is the idea that it’s better to quickly try and then kill ideas, so as to move on to the next and not waste time. It often goes along with the idea that “you learn more from failure than you do from success.”
The plain truth is that you may spend more time ruminating on your failures, trying to avoid future pain. But with failures, it’s hard to ask your customers questions because you don’t have any customers, and the few who give feedback must be highly motivated. If you get a reputation for failure, customers won’t even try your next ideas. “Fail fast” works best when the reasons for success can’t be predicted or known, where you want to explore a big problem space and aim for lucky, ala darts.
On the other hand, success teaches us more because we can actually build on it, experiment with it, tweak it, and ask questions to better understand it. In other words: Science.
The big downside of “fail fast” is that it often doesn’t give new ideas enough chance to find their value. The difference between “suck” and “holy, f*ck!” is often a small pivot, turning an apparent problem into a feature. And once you fail something, why would anyone try something that reminds them of that?
A practical design example is how Google Earth flies you from place to place in a nice ballistic arc. I must have tried 30 ideas in the space of a month. Zooming up and down as a function of altitude-squared seemed best, because it kept the information density about constant, but other parts of that algorithm were clumsy. Rotating the camera with quaternion interpolation seemed right because it felt like the way a missile would spin ballistically, but I had to figure out how to pace the rotation properly. Setting the centers of rotation relative to the earth and the viewer also took a lot of experimenting. These approaches all failed individually, but I kept the most successful aspects of each and recombined them instead of “failing fast” and moving on, or defaulting back to what everyone else did (e.g., springy trackball models, or lame screen-space X/Y pan).
On the other hand, for manual interaction I really wanted to stick to the principle that no matter where you put your mouse cursor on the globe, that same spot remained under the mouse until you let go. It’s as if the virtual globe was a physical model following your finger by touch. It feels “heavy” when you “throw” it into a spin, right?
I stuck to that rather skeuomorphic idea so much that I caused what I still consider to be a bug (that no one has fixed, check it out). When your view is oblique (tilted), dragging any point on the earth toward the visible horizon causes the earth to move exponentially faster. It’s mathematically correct according to the design principle, but bad user experience to spin the earth up to 45 degrees in 2 pixels of movement. It’s confusing, and it’s easy to fix if I’d been less dogmatic.
So I’d rather call this lesson “kill your darlings,” as they say in creative writing class. That is, have a good bullshit detector — especially for your own bullshit. But don’t be afraid of going down the wrong path for a little while, since that’s often the right path in disguise, or at least closer than you might think.
Lesson Two: Build for Iteration Speed
Given that great ideas take a lot of iteration and the odds are always stacked against you, increase your chances by using tools that accelerate your work. In the case of Google Earth, there was no 3D planet browser to use. So I wrote one. It was basically Netscape in 3D. We could put markup and buttons anywhere on the 3D globe, or in the 2D screen. We could edit the interaction by writing scripts linking pre-compiled objects.
I did that over the objection of my boss at the time, who was rightly concerned about delivering our first product faster to get investment closed sooner.
Here, I took a lesson from my time at Disney Imagineering, where they’d already built a Scheme-based scripting engine on top of a C++ real-time toolkit (also built on top of code from Michael Jones’ Performer team at SGI). It was awesome to prototype in. Many games use the same idea with LUA engines and the like.
It took about a month of valuable time, but doing this at Keyhole allowed me to iterate very quickly on the key interaction paradigms, trying out variables and methods like “sin(x) vs. log(x) falloff” for the interactions, changeable via pop-up UI widgets or script edits, until I got the UX to where I couldn’t improve it anymore.
Lesson Three: Test with Real People
I know plenty of developers who love to work alone. Just give them the requirements and they’ll come back with something interesting. But you have to check that impulse, if they don’t. Because the only right answer is based on what the customers think.
I learned this from trying to be a writer in my 20s. Writing is a bit like coding, except the software runs in other people’s brains. Yes, right now, this webpage is executing on your brain (and if I could make it also produce bitcoins, I’d be rich). It’s not what I meant to write that matters, but only how readers interpret it.
For example, one small mistake many companies make is in writing their product scenarios and use-cases using fictional users. “Joe Smith is a plumber from Diluth who loves Hash Key Regulator Service 2.0.” If you make up your customers, you have no way of knowing if your product sucks. Thankfully, we didn’t use any such methods at Keyhole. We knew we were in fairly blue sky (no pun) territory.
On the other hand, Henry Ford (never) said, “If you asked people what they wanted, they’d want faster horses.” For a revolutionary product, people often can’t imagine what they could be doing so radically differently than today. It’s not their job to do so. As a designer, it’s yours.
But on the third hand, if your customers can’t imagine why they’d want your product, how do you plan to sell it to them? So you’d better figure this out before you launch, one way or another!
The key is that you can test narrow enough pieces of a complex puzzle. Try to navigate from New York to Tokyo. How did you figure out what to do? How did you feel while you were doing it?
Watch them, even watch their eyes, their emotions. I did this first with my own leadership team and developers, then with any random people I could find.
There is no substitute for simply watching people try to do something that you designed and seeing them fail, knowing it’s your fault. Don’t ever make them feel stupid for it. They’re smart. You’re not. As a designer, you have to have enough empathy to see the world as they do. That’s all that matters in the end.
Honestly, I wish I’d learned this one a lot sooner.
Lesson Four: You Suck
Building on that idea, some of the best designers I’ve worked with are inherently humble. A few others have gotten it in into their heads that they’re geniuses, and as such are more right than everyone else. While there may be some evidence there historically, it’s a horrible way to do design, as it shuts out all of the key inputs you used to get back when you were an unappreciated genius. IOW, if you run around with an entourage, you never get to see the truth. The entourage’s job, like your own personality’s job, is to hide and protect itself — and you — from the more difficult truths.
One of the best things I learned about design (at Microsoft, no less!) was that the first part of design should be called “the stupid phase,” where we admit we know nothing and are open to everything.
But in reality, the stupid phase never ends. Because if we’re going to be successful, once we figure out one thing, we need to admit we’re stupid about the next harder problem. And there is always a next harder problem or we’re not trying hard enough.
Apparently, I can prove that we’re stupid, by induction.
Lesson Five: There is No Spoon
Thinking “outside the box” requires first thinking about the box. What if there is no box?
A good example of this at Keyhole was the way we labeled roads and features. All prior maps, as far as I know, even including contemporary 3D globes like Virtual Earth, baked text labels right into the imagery or were otherwise very slow to add them later. That was just how it was done, typically. The problem is that these baked labels were almost always the wrong size, resolution and rotation for a given 3D view. It looked terrible, especially when tilted or rotated.
I might have just been lucky. I came from a real-time vis-sim background and it never even occurred to me to bake the labels into the imagery. Instead, I came up with a way to render them in under 2 milliseconds every frame, well inside the limit needed to render at 60 frames per second. I made the labels follow the curve of roads, added basic kerning, and drop shadows for clarity. I made them fade in and out based on changing zoom levels, mostly because I hated how it looks when they always remain the same screen-size, and still do.
After I got that working, it occurred to me how to space the labels better to avoid overlaps and add some negative space to keep the text most readable.
Turns out, there’s a whole science devoted to doing this right for maps. If I knew more, I might have gotten a worse result.
There is a similar but more impressive story involving the guy who invented Kinect. I saw Ryan Geiss invent Kinect a second time when I was at Microsoft — while he nominally worked for me — right before Kinect’s launch. Before the birth of the program, I’m told, before anyone knew what was even possible, he was handed a depth sensor and simply told “go make it do something interesting.” He certainly did!
He had no formal computer vision experience, as far as I know, no experience with the “correct” way to do this. But he quickly came up with a novel way to do skeletal tracking without using too much time or CPU power, and most importantly with robustness. Amazing guy.
Lesson Six: Persistence
This is the main reason why “fail fast” is bullshit. Ryan didn’t give up on his first four (I’m guessing) attempts at solving skeletal tracking, and he worked his ass off to solve key problems before Kinect’s first public launch. Likewise, I didn’t stop when my boss said not to waste time on building what eventually turned into KML.
OTOH, there are other times in my career where I got overly frustrated and moved on. That’s one reason I got to do so many cool things. I’m lucky that in many of those places I left, I’d worked with other people who had more perseverance than me to stay and finish. I’m thankful for that.
If you look at the truly great innovators, artists, and even political figures, this is what they all have in common. They didn’t give up. Anyone else might have been smarter, but you never heard of them, because they gave up.
This is also why we’re often willing to forgive apparent psychopaths like Steve Jobs so easily. Because they made it all work out, despite the crazy. But please don’t be an asshole, even if you’re as driven as Jobs was. More often than not, you just piss off or scare off great people who could help you succeed.
Lesson Seven: Pick your Battles, and Know Yourself
While designing a product that winds up being used by a billion or more people is a product of luck, timing, great collaborators, iteration, persistence and a lot real-world customer testing, the easiest way to screw yourself is by digging into the wrong fight at the wrong time.
Each fight you undertake consumes approximately all of your energy and can leave you wasted, even when you win. So where are you going to put that energy? Are you going to frustrate others around you and ultimately lose the war, even if you win the battle? Does it even need to be a fight?
That’s the question to ask yourself every time you’re about to engage. What do I really need to solve next? Will this problem solve itself if I’m patient? And more importantly, what do the people around me need in order for all of us to win?
That’s something I wish I’d known how to do better back at Keyhole. It’s a lesson that doesn’t come easily.
One can always take a success and look backward to see how it became that. But can anyone take a green field and see the path forward to success?
If you have in you the capability to build such a product, vision or feature, first be honest with yourself about your strengths and weaknesses. Understand your own filters (i.e., personality traits: like narcissism, paranoia, depression, obsessive/compulsive behaviors) that color the world you see and often keep you stuck. Ask for help. Get perspective from others. Get training.
It’s too easy to protect your darlings (lession 1), build too much or too little infrastructure for iteration (2), ask too few or the wrong questions of customers, real or imagined (3), over-promote or flagellate yourself (4), get stuck in or around the wrong box (5), or simply give up (6).
The sad irony is that the people who may be most capable are often least confident, because they see the difficulties most clearly. And others, who may be statistically predestined to fail, often have an unrealistic level of confidence and perseverance that looks like either genius or madness, depending on the outcome.
In any event, none of the people who design successful products are supernatural, as far as I know. They all have flaws as big as (or bigger than) yours. They may even be [over]compensating for those flaws most of the time. But they did something generally beyond sheer luck, in that they saw an opening just big enough for them to squeeze through and they went for it and made it through to the other side, at least once.