Pretty cool insight by an engineer into product development through demos at the hay days of Apple!
Focus on small details for the next step
Yet we never thought about such big numbers. We were too busy focusing on small details. Every day at Apple was like going to school, a design-focused, high-tech, product-creation university, an immersion program where the next exam was always around the corner.
Essential qualities
Embracing what we don’t know is possible by users
When we started developing our touchscreen operating system, we didn’t know if typing on a small touch-sensitive sheet of glass was technologically feasible or a fool’s errand.
Demos
Demos like this were the foundation of the Apple software development process, as you’ll see in the case of this iPad demo and as I’ll describe in many other demos throughout this book.
Question and answer
The demo was my question. Steve’s response was the answer.
Decisiveness for the next demo
He was always easy to understand. He would either approve a demo, or he would request to see something different next time. Nevertheless, some mystery remained. No matter how good your work was, or how smoothly it had sailed through the preliminary reviews leading up to him, you could never know how he would react.
Specific
Whenever Steve reviewed a demo, he would say, often with highly detailed specificity, what he wanted to happen next. “Add more space between these two elements,” or “Replace the green in this graphic with blue,” or “None of this is working. Show me more options next time.”
Tiny demos step by step
More generally, he was always trying to ensure the products were as intuitive and straightforward as possible, and he was willing to invest his own time, effort, and influence to see that they were. Through looking at demos, asking for specific changes, then reviewing the changed work again later on and giving a final approval before we could ship, Steve could make a product turn out like he wanted.
Demo room “Diplomacy”
Diplomacy was about thirty feet long and fifteen wide, drab and windowless. A couch in the middle of the room faced the door, roughly dividing the space into two squares. A pair of eight-foot-long tables were pushed against the walls in the half of the room closer to the door. This created an area for demo devices to be laid out, and this was where all the action took place… On the whole, Diplomacy was a study in indifference. It was an important room, often used for CEO demos, but it was never the center of attention itself.
Keep the demos concise
Sitting to Henri’s left on the couch was his boss, Scott Forstall, then the senior vice president of iOS software engineering. Scott reported directly to Steve, and he was the one giving me this chance to demo in Diplomacy. Scott expected me to keep it concise and on point when it was my turn to go.
Usefulness of the products
This was part of Steve’s mission for Apple, the most significant strand of Apple’s product development DNA: to meld technology and the liberal arts, to take the latest software and hardware advances, mix them with elements of design and culture, and produce features and products that people found useful and meaningful in their everyday lives.
Based on delivery and small iterations
They were always wary of showing Steve something he might like but that we might not be able to ship in a product. Scott didn’t run an ivory tower research and development department. Our demos to Steve carried the promise that we could deliver, and since showing work to Steve implied this willingness to commit, very few demos shown for the first time in these earlier meetings proceeded to him without further refinement.
Small tiny demo
Demos served as the primary means to turn ideas into software. The setup of these demo review meetings reveals how we went about making our software great.
Every tiny demo leading up to the product
The need to keep churning out demos that could eventually be shown to Steve meant our day-to-day software development work became a pyramid of demos, reviews, and decisions building up to the top and to Steve’s final judgment.
Avoiding bike shedding
For example, should the software remember that you used the bigger-keys keyboard in the Notes app and the more-keys keyboard in Mail, and should these keyboard choices be restored in some situations but not in others? These questions became moot, and that’s good, because they don’t necessarily have easy answers.
It is okay to throw away part of the demo
Bas never expressed any disappointment over his zoom animation getting deleted either. Seeing good work wind up on the cutting room floor was part of the job.
Staying focused
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.
Showing progress
Demos were fundamental to our work at Apple. We used them to highlight the potential, explore the concepts, show the progress, prompt the discussion, and drive the decisions for making our products.
A single product focus
Steve Jobs himself had decided how he would judge our browser as a product. The focus would be on one thing: speed. Steve wanted our browser to be fast, really fast at loading web pages from the internet, much faster than Microsoft Internet Explorer, the default browser on the Mac, the product we aimed to replace.
Fixing and performance hand in hand
When it came time to make a code change, everything was fine if the browser ran as fast with the new code in place as it did without it. Most code edits had no effect on performance, but some inevitably did, and as long as the change was in the faster direction, then all was well. We sometimes had happy accidents too—unforeseen speedups stemming from changes to remove lingering FIXMEs. Higher-quality code often performs faster.
Manager’s role reporting to Steve Jobs
Steve looked to him to deliver on the decisions that came out of these demo sessions, and Henri filled his role with his own brand of self-assurance coupled with a lack of self-importance.
Manager’s role as a buffer
In the years since, I’d seen him demonstrate his calmness again and again. In the lead-up to a Steve demo, he could be counted on to keep his composure and smile through the tension. Henri acted as a buffer between his team of programmers and the company’s hard-to-please leaders. He edited expletives out of the executives’ requests before passing them down to individual coders.
Manager’s empathy for a engineer
He seemed to know that applying pressure on me wouldn’t help me figure out the fix for the bug any faster but that I would drop whatever I was doing and get right on it. In his way, Henri filled a role created by the personality of our intense CEO.
Incorporating new technologies into new products
I expect Steve valued Scott’s ability to imagine how new technologies might be integrated into our software products. Scott excelled at making these connections.
Skills required
A flannel shirt–wearing, cigarette-smoking New Yorker, Greg had an encyclopedic knowledge of the history of computing, a tinkerer’s knowledge of analog and digital hardware, and a gut feeling for how to create software that made sense to people.
Time and personal involvement in the demos
making great software was a core corporate focus. What’s more, Steve wasn’t merely interested in paying lip service to this goal. He demanded action, and so the software team produced demos in a steady stream, and whenever there was interesting new work, Steve found the time to attend a demo review so he could see it. His involvement kept the progress and momentum going.
Decisiveness and decider
Decisiveness was crucial throughout. 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.
Just enough discussion at the demo
Even the discussion Steve used to arrive at his conclusion was spare and minimal. Note how Scott introduced my demo with just enough words to communicate to Steve what was next on the agenda…
Rinse and repeat
The meeting had been productive and decisive. It was a pattern to remember and replicate.
No separate R&D
Apple didn’t separate research and development from software implementation. We were responsible for coming up with the ideas for our web browser and writing the shipping code that went out to customers too.
Understanding your employees
By then Scott had heard that I was disappointed over the Safari management decision. He reached out to me. We met for a couple of hours, and he made it clear he didn’t want me to go. He urged me to put the management change behind me, and, to help me do that, he said he wanted to know more about what made me tick. After we talked for a while, he concluded, correctly, that I liked projects much more than politics.
A single person who is responsible
The closest term we had in the Apple lexicon was more management speak: directly responsible individual (we pronounced it as D-R-I in conversation), the person who has to do whatever is necessary to develop a piece of hardware or software, some technology, some critically needed thing—the DRI was the person with their butt on the line.
A manager’s day to day role
Mostly because I was unprepared for the change in my daily routine. I went from writing software every day to worrying about my team. My schedule was always full of meetings. I had to navigate cross-functional relationships with other teams related to sync, and that involved much more politicking than I was expecting or was used to.
Leadership and team work for scalability
The software we created at Apple was an accumulation of such small details. Steve looked to Scott not only to make these kinds of intuitive leaps himself but also to build and lead a team that could make them in volume.
Holding ourselves to higher standards
Try to sneak a slipshod demo past him? You’d get caught in the jaws of a sharp rejoinder, which Greg would likely deliver with a loud snap. He wasn’t the most popular man in the company. However, to those who shared his high standards and his abhorrence of lazy justifications, he was unceasingly loyal and supportive.
Asking questions
When Steve asked for my opinion, it was a test. After looking at my demo, he wanted to find out, right there, if I could help make the software better. If I hadn’t given a satisfactory answer, he would have turned to the other people in the room. They had earned their places by repeatedly passing similar tests and making much work better, as on every software detail of the iPhone.
A single metrics for measuring progress
After the PLT got to the end of its URL list, it would calculate the average time to load a web page. This was a distilled-down measure for how fast our browser was at that moment, and this single number became the key element to Don’s plan. He issued a managerial edict: No more code changes without running the PLT.
Team work even though one single person is doing the technical fixes
Once it was clear to Darin and Trey that their advice was leading to obvious improvements in my code, they appeared to like it. Even though the technical work to make the insertion point behave better was still my responsibility, they could share in the turnaround they helped bring about. My bug fixes were now something we could talk about in detail in hallway conversations and over lunch, and our collaboration gave them the technical grounding they needed to have opinions and make further suggestions.
People is more important than technology
This points to the more general lesson I took from my WebKit editing work: People matter more than programming. This may sound trite, but many coders find it easier to get along with computers than colleagues, and there’s a tendency in Silicon Valley to view every question as having a technological answer.
Cleaning up engineering work takes time
cleanUpBobsSh_tStormHeIsAF__kingTurdBlossom(); Fearing that such bad language might harm the appeal of its software once the source was opened up and anyone could see it, Netscape management issued a decree: All the programming profanity would have to go. Cleaning up the code was a big task.
Time taken cannot be further reduced in some cases
In his 1975 software engineering classic, The Mythical Man Month, Frederick P. Brooks Jr. says that they do. Sharing the lessons he learned while managing the OS/360 mainframe operating system project at IBM in the 1960s, Brooks offers this observation: “When a task cannot be partitioned because of sequential constraints, the application of more effort has no effect on the schedule. The bearing of a child takes nine months, no matter how many women are assigned.”
Willing to try another method when something is not working for a while
He began by quizzing us on the browser analysis we had done before his arrival, and after hearing it, he quickly discarded our effort with Mozilla as unlikely to bear fruit. By doing so, he demonstrated the self-confidence to skip any ingratiating display of deference to his new manager, a person who had years of experience in the technical field he was newly entering.
Making the first cut feasibility: closest approximation with least time and feature
In getting this code running on a Mac, he decided to make the closest possible approximation of a real browser that was feasible on his short schedule. He identified three features—loading web pages, clicking links, and going back to previous pages.
Choices of non-goals
then made his shortcuts, and these simplifying choices defined a set of nongoals: Perfect font rendering would be cast aside, as would full integration with the Mac’s native graphics system, same for using only the minimum source code from KDE. He reasoned that these shortcuts, while significant, would not substantially detract from the impact of seeing a browser surf web pages.
Just enough detail to move onto the next task
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.
Highest fidelity for the feature that is being built
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.
Creative an illusion of the entire product
but creating the illusion of an actual product is essential during the development process to maintain the vision of what we’re actually trying to achieve, and so my colleagues can begin responding and giving feedback as if the demo was the product.
Next tiny steps
Look for ways to make quick progress. Watch for project stalls that might indicate a lack of potential. Cut corners to skip unnecessary effort. Remove distractions to focus attention where it needs to be. Start approximating your end goal as soon as possible. Maximize the impact of your most difficult effort. Combine inspiration, decisiveness, and craft to make demos.
Indicating where to come back in the future
A couple months later, we would be very glad we had made this decision and that we had maintained the discipline to add these annotations whenever we had doubts about a piece of code while we were editing it. Each FIXME was another item on our programming to-do list.
Using a list of todos to track progress
This is where our idea of adding FIXMEs paid dividends. We wrote code to autogenerate a report as we attempted to load a web page. Every FIXME in our code added an entry to this report, which made it clear that, behind the scenes, in the depths of our software, our browser was doing a lot, even if it didn’t yet produce visible web pages.
Always progress, every day
We would never again endure a period where we went weeks without visible evidence of progress. Once we started to see web pages loading, we could also see our browser getting better, almost on a daily basis.
How good ideas come
Steven Johnson says in his book, Where Good Ideas Come From, “Folklore calls Edison the inventor of the lightbulb, but in truth the lightbulb came into being through a complex network of interaction between Edison and his rivals . . . Edison built on the designs of at least a half dozen other inventors who went before him, including Joseph Swan and William Sawyer.”
Trials after trials
I would like to turn the discussion back to how Edison himself described his approach for constructing the foundations for his innovative work, specifically, how he solved problems like finding the best filament material for his lightbulb: “None of my inventions came by accident. I see a worthwhile need to be met and I make trial after trial until it comes. What it boils down to is one per cent inspiration and ninety-nine per cent perspiration.”
The real work: mundane, drudgery, grunt work
We want to believe geniuses like Edison can conjure world-changing inventions out of thin air. Easy explanations are alluring, and Edison-like inspiration seems magical. Perspiration, we know, involves drudgery.
Systematic elimination
Instead, Edison searched specifically for the best kind of bamboo, and he was undaunted by the need to check a vast number of varieties. Each one he tested was an item crossed off and brought him closer to finding which one was the best.
Build up the content slowly
Three weeks or a month before the keynote itself, Steve would start rehearsing with portions of his slide deck in some venue at Apple, often in Town Hall, the auditorium on the Infinite Loop campus. Slowly, day by day, he would build the show by stepping through it as he wanted to present it at the keynote.
Practice a lot
This was one of Steve’s great secrets of success as a presenter. He practiced. A lot. He went over and over the material until he had the presentation honed, and he knew it cold.
On the way towards a product launch
There were a few more twists and turns on this keyboard project than was typical— the hallway pause, the all-hands redirection toward a single technology investigation, the dramatic demo derby —but the overall process that led up to this meeting with Scott was standard Apple.
Why demos are important
Exactly how we collaborated mattered, and for us on the Purple project, it reduced to a basic idea: We showed demos to each other. Every major feature on the iPhone started as a demo, and for a demo to be useful to us, it had to be concrete and specific.
Concrete and specific
The point is that concrete and specific examples make the difference between a discussion that is difficult, perhaps impossible, to have and one that feels like child’s play.
Importance of demo
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,
Succession of demos
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.
Vision
In any complex effort, communicating a well-articulated vision for what you’re trying to do is the starting point for figuring out how to do it. And though coming up with such a vision is difficult, it’s unquestionably more difficult to complete the entire circuit, to come up with an idea, a plan to realize the idea, and then actualize the plan at a high standard, all without getting bogged down, changing direction entirely, or failing outright.
Excellence
but a significant part of attaining excellence in any field is closing the gap between the accidental and intentional, to achieve not just a something or even an everything but a specific and well-chosen thing, to take words and turn them into a vision, and then use the vision to spur the actions that create the results.
An unchartered area
had to become an expert in all the nuances of word processors. There’s no programmer’s handbook on this topic, so I had to run experiments to discover the rules on my own. I needed to come to grips with the letter and spirit of all these rules, both simple and complicated. In my studies, I spent many hours poking and prodding different word processors, Microsoft Word, the Apple Mail composer, and BBEdit, the editor I used to write my programs—testing, tapping, typing, clicking.
Collect data, comparison metrics, use the scientific method
It represented an important technical insight: When software behavior is mysterious, get more organized. My insertion point code needed to be as businesslike as a baker looking at a properly filled out order form to determine the correct words to write on a cake.
100 seconds celebration
At Apple, there was never much time to savor success.
Just keep going…
Williams asked Steve where he “fit in the American family of thinkers and inventors.” At first, Steve attempted to brush off the question, but when Williams pressed him, Steve said: “I think if you do something and it turns out pretty good, then you should go do something else wonderful, not dwell on it for too long. Just figure out what’s next.”
Codename Purple
Then Henri told me. “Yeah, we’re making a cell phone. Its code name is Purple.” Just like that, I had joined the biggest super-secret project at the company, perhaps in Apple’s whole history. I felt a mixture of guilt and euphoria.
A tiny demos as a means to test feasibility for the early iPhone
Henri’s skunk works engineering team created demos for inertial scrolling and SpringBoard—the key user interface innovations Bas had shown me on the Wallaby—as well as an early demo of Safari, all running on a product you could carry in your pocket. With these demos, Scott made a compelling case that his software team could squeeze the software essentials of the Mac onto a smartphone. Steve agreed.
Steady flow
Even when demos went well, there was always a steady flow of feedback, suggestions for changes, impressions on how the software might behave differently. Everyone spoke up. Demos were an open forum for exchanging ideas about how an interaction might look or function better. When demos went poorly, as sometimes happened, there was the same stream of comments and constructive criticism. There was never any finger-pointing; however, there was an expectation that new demos would include a response to the feedback from previous demos. This was the one essential demo expectation: progress.
Closing the prototype-product gap
They repeatedly asked themselves the same basic questions during these periodic reviews: Does this demo close the prototype-to-product gap, even a little? Are we seeing enough positive change over last time? Is this technology or app on track?
Rare sessions of brainstorming
We didn’t do this on the Purple project. We rarely had brainstorming sessions. I recall only a few times in my entire Apple career when I stood around to rough out big plans at a whiteboard.
Whiteboard discussions are an illusion of work
If brainstorms run longer than an hour or so, or if there are more than a handful of people in attendance, or if they’re a common occurrence, they can devolve into a form of sneaky procrastination. Whiteboard discussions feel like work, but often they’re not, since it’s too difficult to talk productively about ideas in the abstract. Think of a cute puppy.
Show don’t tell
Yet that’s what innovation opportunities look like. The field was wide open, so, when any of us had a new concept for a keyboard, we made a demo to communicate what we were thinking. Literally, we had to demonstrate our idea. We couldn’t get away with telling. We were required to show. We combined some inspiration, craft, taste, and decisiveness, and we shared our results.
Balancing acts
Finding the answers became a balancing act among craft, taste, and empathy — developing touchscreen text entry technology that was efficient, likable, and intuitive. All along, I worried that my keyboard had product-killing potential.
Everyone works towards a single goal for a short period of time
Henri told us that Scott was pushing a big Purple pause button. He wanted everyone to start making keyboards right away. The recent “difficult” keyboard demo had raised concerns up and down the management chain. It was critical for us to have a software keyboard for our touchscreen smartphone, and the official word had now come down: Progress was too slow.
Full touch screen
Our Purple phone wouldn’t have a hardware keyboard. There were no prototypes in the Industrial Design studio that included anything like a BlackBerry-style keyboard. The Purple concept was built around a large touchscreen and a minimum number of fixed buttons. Apple had bet everything on a software keyboard. When it came to typing, plastic keys would give way to pixels.
A stream of demos for a single challenge
Henri looked at his software team assembled in the hallway and said, “Starting from now, you’re all keyboard engineers.” He concluded by saying we would get together for a demo derby once we had a collection of new software prototypes to show.
Try out everything in many demos
Some involved blue-sky interaction models, like one colleague’s complex multiple-tap scheme built around a few super-big keys he could type on without looking. Others called for various orchestrations of multitouch inputs to type letters, enter punctuation, and capitalize words. Scott was game to try everything, and as always, he was upbeat and encouraging.
Something in every keyboard, but still the answer is not there yet
He found something positive to say about each demo—good graphics, clever idea, interesting concept—but he was still having a difficult time. None of the keyboards offered quick and accurate typing.
Early prototypes are never WOW!
They were supportive, but they clearly didn’t think my keyboard was as “amazing” as Scott did. That’s how it often goes with early-stage prototypes.
New features vs usability
These problems illustrate a common product development quandary. People who love tech gadgets want new products that do cool new things. This creates the customer demand that gives product developers like me incentive to add new features. Yet none of us wants these products and features to be confusing, to lead us astray, to drive us down a software dead end and dump us there.
Hard focus on preventing negative experiences
Over time, I came to the conclusion that designing an excellent user experience was as much about preventing negative experiences as facilitating positive ones. It couldn’t be an even trade-off either. Great products make people happy almost all the time and do the opposite rarely, if at all.
Living on the product
On the Purple hallway, we were trying to make excellent products for people, and while we sometimes said “dogfooding” inside Apple, more often, and more officially, we began to say “living on” to describe the day-to-day routine of living on our in-progress software like it was a real product.
Everyone was using the product being developed
Since everyone on the Purple development team was living on my new QWERTY keyboard every day, the feedback came back to me loud and clear. It was too hard to build up typing speed.
Empathy
In the introduction to this book, I described empathy as trying to see the world from other people’s perspectives and creating work that fits into their lives and adapts to their needs. Empathy is a crucial part of making great products. The living-on experiences with the derby-winning keyboard showed several breakdowns in empathy, where the person felt at odds with software attempting to provide assistance.
Philosophical vs practicality
Yet when it comes to making products, philosophical discourse is the wrong tool for the job when practical decisions are needed. It would be similar to a carpenter pausing to ponder the finer points of materials science, quantum theory, and the origins of the universe—fingers pressed to forehead in a moment of deep reflection—before choosing the right hammer to drive nails.
Applied > Theory
A creative and technical practitioner, I couldn’t open myself to an infinite regress of ideas at every step of accomplishing a task. It’s important to keep making progress and to keep sight of priorities. That doesn’t give product designers the license to ignore philosophy. Rather, in my case, I recognized I’m not a philosopher myself; I’m closer to a carpenter. As a maker of products, I always turned less to the theoretical and more to the applied.
Analysis paralysis
A lack of specific thoughts isn’t a big deal when picking fruit to put on top of breakfast cereal, but such gaps are an issue in creative work. Persist too long in making choices without justifying them, and an entire creative effort might wander aimlessly. The results might be the sum of wishy-washy half decisions.
Knowing the past trends
Studying great work from the past provides the means of comparison and contrast and lets us tap into the collective creativity of previous generations. The past is a source of the timeless and enduring.
Functional beauty
His message is clear, and I agree with it. Shallow beauty in products doesn’t serve people. Product design should strive for a depth, for a beauty rooted in what a product does, not merely in how it looks and feels. Form should follow function, even though this might seem like a strange notion for pixels on a screen, but it’s not if you believe the appearance of a product should tell you what it is and how to use it.
Future tells the success
The intervening years have provided the answer. The autocorrecting QWERTY keyboard did not sink the iPhone as a product, as did the disappointing handwriting recognition on the Newton. The opposite happened. Two-thumb typing on a touchscreen is now normal. It’s the default for mobile devices.
The real output of a touchscreen keyboard
When the flight attendant announces over the intercom that everyone can turn their phones on, what do many people do next? They open a messaging app and type a short note to a companion, a friend, a loved one. They say, “Just landed,” or “On the ground. See you soon.” These countless trivial but touching human moments are enabled by technology and made possible, in some small part, by a QWERTY keyboard.
Convergence period
Convergence was the term we used to describe the final phase of making an Apple product, after the features had been locked down and the programming and design teams spent the last three or four months fixing bugs and polishing details. Entering a convergence period was the moment we had a clear picture in our minds about how we wanted our finished software to work. It also meant that the hardest part was over—we had been largely successful in navigating the course from idea to product.
Convergence phase
once we entered a convergence period, we started dealing with a persistent product development pressure generated by two opposing forces. One was the constant ticking away of time as we moved closer to an unmovable ship date; the other was the variable and ever-changing number of bug reports representing software problems that needed to be fixed.
Increasing the dictionary features
Over time, I decided many different data sets merited inclusion: sports team and stadium names, city names, product names, chat slang, abbreviations, and more. The autocorrection dictionary was less an academic linguistics exercise and more a catalog of contemporary life.
Things to consider
Determining comfort levels, pursuing smoothness, and reducing mental load are examples of the kinds of ergonomic, perceptual, and psychological effects we often aimed for, and in each case, honing and tuning technology to a high level became the means to achieve people-centered results.
Subjective heuristics
good heuristics don’t come in brilliant flashes, but only after patient searches, and it wasn’t always clear to us that we had found the right heuristic even when we had. We arrived at our final decisions only with judgment and time. Heuristics are like this. They’re subjective.
Small teams and 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.
Culture and people and product
The biggest lesson I learned as I wrote this book is how a group of people and the culture they create are one and the same.
Apple’s way of working: solid compartmentalization
Many of these struggles remained invisible to me, because I was so focused on my own difficult work and because of the compartmentalized security mandated by Steve. I know almost nothing about how we developed our phone hardware, the details of the industrial design process, or the negotiations with phone carriers.
First look of the integrated iPhone
She was holding a Purple phone. Untethered. No cable attached to a Mac. The real industrial design. An actual glass screen, not the plastic display of a Wallaby. I had never seen one of these before, and this wasn’t a mere model either. It was a working phone. The hardware was powered up and running with all our software loaded onto it.
Tracking the convergence line
We got good at reading this convergence line and taking the temperature of the project through it. We learned to understand convergence behaviors, like the upward spikes in the line after big demos, which weren’t as worrisome as they seemed—many demo bugs would be quick and easy to fix—and the stubborn flat lines over many days, which could indicate real trouble, since the number of incoming bugs was matching our fix rate, and that meant convergence might be stalled.
Google’s way of making a product
In this kind of test, commonly referred to in the high-tech industry as an A/B test, the choices are already laid out. In this Google pick-a-blue experiment, the result was always going to be one of those forty-one options. While the A/B test might be a good way to find the single most clickable shade of blue, the dynamic range between best and worst isn’t that much.
Taste and data
A/B tests might be useful in finding a color that will get people to click a link more often, but it can’t produce a product that feels like a pleasing and integrated whole. There aren’t any refined-like responses, and there’s no recognition of the need to balance out the choices. Google factored out taste from its design process.
Steady progress
Or did we? Well, yes and no. We always made quick choices about small details, but we were always willing to reconsider previous decisions. We took more time with bigger questions, but never too much. We were always mindful of making steady progress.
Process
As a whole, a succession of demos, feedback, and follow-up demos created a progression of variation and selection that shaped our products over time. It’s a Darwinian process, and not surprisingly, Charles Darwin himself was unequivocal about the potential and power of adding up incremental modifications down a line of generations.
Comparison with evolution and selection
the various breeds of sheep fitted either for cultivated land or mountain pasture, with the wool of one breed good for one purpose, and that of another breed for another purpose; when we compare the many breeds of dogs, each good for man in very different ways . . . we must, I think, look further than to mere variability. We cannot suppose that all the breeds were suddenly produced as perfect and as useful as we now see them; indeed, in several cases, we know that this has not been their history.
Nature + Man
The key is man’s power of accumulative selection: nature gives successive variations; man adds them up in certain directions useful to him . . . It is the magician’s wand, by means of which he may summon into life whatever form and mould he pleases.
Gist of Creative Selection
I’ve given a name to this continuing progression of demo -> feedback -> next demo: creative selection.
Focus on the very next step
We were always so focused on the next demo, the next review session, the next time we were scheduled to show progress to Steve. Our iterative working method was like the air—something all around us all the time, something we were always aware of on some level, something it didn’t make sense to question.
Simple words
Without looking up, still staring at the display of the iPad, he declared his opinion on the elastic effect: “This animation . . . this is Apple.”
No long discussions on what could be
For example, we didn’t take two-hour coffee breaks or hold daylong offsite confabs to talk about projects without examples to ground the discussion—we didn’t have lengthy discussions about whose imaginary puppy was cuter.
No printed specs and paper mock-ups
We didn’t shuffle around printed specifications or unchanging paper mock-ups for weeks on end, waiting for an epiphany that would jump us directly from an early-stage concept to a complete product design, hoping we could somehow flip the ratio of inspiration to perspiration Thomas Edison spoke about, the relationship between the time it takes to get an idea and the amount of hard work it takes to transform that idea into something real.
No R&D Departments
We didn’t establish large, cutting-edge software research departments sequestered from, and with a tenuous connection to, the designers and engineers responsible for creating and shipping the real products. Steve Jobs famously disbanded such an organization at Apple,
No next step decision
You could hold demo meetings and then adjourn them without deciding what to do next, a mistake that interrupts the chain of criticism that provides the logical connection from demo to demo.
Over sized teams with confusing lines of authority
You could assign oversized project teams to the tasks one or two people could handle, a fault that can lead to muddled communications and a dilution of each person’s ability to make a difference. You could have conflicting lines of authority and fail to ever reach universally recognized final decisions.
Cannot slap on the look and feel later on
The photo-swiping example, in particular, should explain why you can’t “engineer” a product in one phase and then slap on “look and feel” in another. It was often difficult to decide where an algorithm should end and a heuristic should take over. It usually took us many design and programming iterations to evaluate all the relevant options. The best solutions were an accumulation of small decisions carefully weighed against each other as we sought to tame the complexity of so many compounding and overlapping factors.
Long lead times between announcement and release
The long lead time between product announcement and its release was uncharacteristic for Apple, but there had been regulatory hurdles to clear before Apple could sell phones and getting an early start on the necessary public filings would have given away the secret about the product.
Not all features in V1
Even so, that first iPhone had some glaring software gaps that seem remarkable now, and among them was a lack of cut, copy, and paste. It’s hard to believe that the iPhone was out in the world for nearly two full years without a basic feature that had shipped with the first Mac in 1984. That’s how technology development goes.
Continuous progress
Either way, I have some advice: Get busy. Decide what it means to do great work, and then try to make it happen. Success is never assured, and the effort might not be easy, but if you love what you’re doing, it won’t seem so hard.