Note: While reading a book whenever I come across something interesting, I highlight it on my Kindle. Later I turn those highlights into a blogpost. It is not a complete summary of the book. These are my notes which I intend to go back to later. Let’s start!

Creative Selection Process involves:

  • Inspiration: Thinking big ideas and imagining what might be possible
  • Collaboration: Working together well with other people and seeking to combine your complementary strengths
  • Craft: Applying skill to achieve high-quality results and always striving to do better
  • Diligence: Doing the necessary grunt work and never resorting to shortcuts or half measures
  • Decisiveness: Making tough choices and refusing to delay or procrastinate
  • Taste: Developing a refined sense of judgment and finding the balance that produces a pleasing and integrated whole
  • Empathy: Trying to see the world from other people’s perspectives and creating work that fits into their lives and adapts to their needs

Decisiveness

Decisiveness was crucial throughout the process. At the pre-Steve level, Scott was the executive editor. He was the “decider.” Every Apple demo review had a decider, the person with the sole authority to approve or not and the prerogative to declare what would happen next

As in Diplomacy, the whole software organization kept meetings and teams small to maintain efficiency and to reinforce the principle of doing the most with the least. Steve’s constant demand to see a succession of demos spawned numerous other demos, each with their own presenters and deciders. All these demos helped the entire software team stay focused on making great products.

In the same way, software demos need to be convincing enough to explore an idea, to communicate a step toward making a product, even though the demo is not the product itself. Like the movie, demos should be specifically choreographed, so it’s clear what must be included and what can be left out. Those things that aren’t the main focus of a demo, but are required to create the proper setting, must be realized at the correct level of detail so they contribute to the whole rather than detract from the vision.

Richard put this theory into practice. He chose the Konqueror open source browser as the basis of his work, one of the candidates we might use for the actual product, and he ensured he could load web pages, click links, and go back. Those aspects were essential. The font rendering was not to Apple standards—some characters were jaggy rather than smooth—but text was legible enough, so Richard expended no more effort on typography. He spent no time at all on irrelevant details, like keyboard shortcuts or a beautifully designed app icon. He chose this combination of important/passable/ignorable features carefully to maximize impact, minimize distractions, and fit the work schedule he’d set for himself.

Demos

When I make a demo, I think about the intended audience, and I make a specific decision about what features to include. I draw a conceptual ring around those key details, and I use a thick imaginary marker to do it. The demo points inside the ring are the focus, and like the lamppost in the movie scene, I depict them with the highest fidelity. I leave outside the ring other less important details that will eventually have to be addressed, but not immediately. I pay them as little attention as possible. Like the inside of the hat shop, I omit them from the demo if I can get away with it. I take extra care at the boundary. Some elements are right on the thick imaginary line, details that need some attention, since they help to set the scene and get my audience to suspend their disbelief

At Apple, we built our work on this basic fact. Demos made us react, and the reactions were essential. Direct feedback on one demo provided the impetus to transform it into the next. Demos were the catalyst for creative decisions, and we found that the sooner we started making creative decisions—whether we should have big keys with easy-to-tap targets or small keys coupled with software assistance—the more time there was to refine and improve those decisions, to backtrack if needed, to forge ahead if possible. Concrete and specific demos were the handholds and footholds that helped boost us up from the bottom of the conceptual valley so we could scale the heights of worthwhile work. Making a succession of demos was the core of the process of taking an idea from the intangible to the tangible.

Why do some products, like the iPhone, turn out as well as they do? I’m now ready to offer my complete answer.

It comes in three parts.

  • The first part is the demo-making creative selection process. Adding it to the concept of working at the intersection, I can enhance my description of how we created variations as we developed a product. When we got an idea, we cobbled together a first cut on the algorithms and heuristics we would need to illustrate it. Then we pulled together the supporting resources—code, graphics, animations, sounds, icons, and more—to produce a demo. After we showed the demo and shared some feedback with each other, we made decisions about changes that might be an improvement. Many times this came down to tuning some heuristic, or modifying how an algorithm and heuristic combined. Whatever it was, the concrete and specific modifications we chose to make led to the actions items that justified making the next demo. Repeat, then repeat again. Doing this over and over again set our projects on the slow path to accumulating positive change. This is how we started with an idea and finished with software for a product.

  • The second part of my answer goes back to the introduction, where I first mentioned the seven essential elements of the Apple development approach. By now I hope you can see how essential they were and how they provided us with the raw material for creative selection. Here’s the full list of the seven essential elements again, and this time, I’ve supplemented them with specific examples drawn from my stories:

Inspiration, which means thinking big ideas and imagining about what might be possible, as when Imran saw how smooth finger tracking would be the key to people connecting to iPhone experiences through touch

Collaboration, which means working together well with other people and seeking to combine your complementary strengths, as when Darin and Trey helped me make the insertion point move correctly in WebKit word processing

Craft, which means applying skill to achieve high-quality results and always striving to do better, as when the Safari team made the web browser faster and faster by running the Page Load Test, trying to understand what this test program told us about our software, and using these findings to optimizing our code

Diligence, which means doing the necessary grunt work and never resorting to shortcuts or half measures, as when we persisted through the tedium of fixing cross-references to get Safari to build in the lead-up to the Black Slab Encounter

Decisiveness, which means making tough choices and refusing to delay or procrastinate, as when Steve Jobs made me pick the better keyboard layout for the iPad on the spot while he waited rather than just offering the two different designs Bas and I developed

Taste, which means developing a refined sense of judgment and finding the balance that produces a pleasing and integrated whole, as when we made the choice to offer a QWERTY keyboard layout for the iPhone

Empathy, which means trying to see the world from other people’s perspectives and creating work that fits into their lives and adapts to their needs, as when Scott Herz made a game to find the best size for touch targets so it was comfortable to tap the iPhone display and accommodated people with varying levels of dexterity

There are many more examples. It was inspiring when Richard made his initial browser demo to show the potential of the Konqueror browser code, and pulling off this demo in a couple days demonstrated his expert-level craft. When Greg Christie said, “Aww . . . come on, Ken!” to urge me to put one letter on each key for the QWERTY keyboard, it was one of the most decisive moments in my career. Continued diligence was necessary to build the autocorrection dictionary for the iPhone, adding all the entries and adjusting all the usage frequency values to create a lexicon of many tens of thousands of words. The tuning decisions for countless heuristics were made with impeccable taste by designers like Bas and Imran and could be seen in every gesture and interaction on the original iPhone. Empathy informed the design of the slide-to-unlock control to make it intuitive even for children. Scott Forstall gave me a chance to join the Purple project even after I botched the opportunity to manage one of his software teams—a collaborative leap of faith in me—because he thought I had something to contribute, and I just needed the right role. There’s something important I want to mention about these examples, because you might be thinking it yourself. Some of the instances I cite are small, seemingly insignificant. How much empathy did Scott Herz feel when he made his tap-target game? How much decisiveness did it take for Greg Christie to declare that I should go back to single letters per key for the QWERTY keyboard? Such questions miss the point: We tried to be tasteful and collaborative and diligent and mindful of craft and the rest in all the things we did, all the time. Everything counts. No detail is too small.

  • This brings me to the third part of my answer. After creative selection and the seven essential elements, we needed one more intersection to make great work: a combination of people and commitment. Creative selection and the seven essential elements were our most important product development ingredients, but it took committed people to breathe life into these concepts and transform them into a culture. The culture we created is inseparable from the products we created. In my experience, this manner of culture formation works best when the groups and teams remain small, when the interpersonal interactions are habitual and rich rather than occasional and fleeting. The teams for the projects I’ve described in this book were small indeed. Ten people edited code on the Safari project before we made the initial beta announcement of the software, and twenty-five people are listed as inventors on the ’949 Patent for the iPhone. Although these two numbers measure different things, they get us in the right ballpark. These weren’t software teams of hundreds or thousands. There was a pragmatic management philosophy at play here, which started from Steve on down. Our leaders wanted high-quality results, and they set the constraint that they wanted to interact directly with the people doing the work, creating the demos, and so on. That placed limits on numbers. This had a follow-on effect as well, in that keeping our development groups small fostered feelings of personal empowerment and a sense of team cohesion. These factors are significant, especially since they’re often at the top of the list of dynamics that managers of too-big teams try to instill and promote. Efficient communication was yet one more oft-elusive characteristic our small teams organically engendered. The communication paths among our few team members became well traveled, and these tracks became like ruts in a road, easing the journey to our desired destinations. We always tried to reach those destinations as quickly as we could, with a minimum of dithering and delay