Apple's demo-based feature development process
· 6 min read
In this post, I want to distill my biggest takeaway from Ken Kocienda's book Creative Selection: Inside Apple's Design Process During the Golden Age of Steve Jobs. This book is unique because it's not about Steve Jobs who apparently had very little involvement in the daily product development activities. Instead, it talks about the culture and people in the trenches who made Jobs’ vision a reality.
Apple's high quality bar was all about the ethos and processes that Jobs put in place and, even though the process was not the main emphasis of the book, it was the silver lining. And this is what I want to talk about.
The Process
Apple's feature development process is a form of rapid prototyping. It is focused on getting software to a semi-working demoable state as quickly as possible to approximate what the end result will look like.
Unlike rapid prototyping in design or rapid prototyping in software development, Apple's process covers design and software at the same time. The demo needs to both show the user experience and prove technical feasibility. After the demo is signed off, engineers turn it into a shippable feature, which the author calls incremental convergence to the vision.
0. Clarity of purpose
The vision and the purpose are paramount in this model because they provide product designers and engineers both guardrails and freedom to innovate. The team has to be crystal clear what they are building and why it is important. The customer problem is clearly defined but the user experience is not.
Ken talks about developing the first version of Safari for Mac and Jobs’ mandate to build the fastest browser. This was before Chrome and Firefox and, at the time, Macs were shipping with Microsoft Internet Explorer. The mandate was clear and strict enough to focus the team but it didn't dictate nuances of user experience, so the team had sufficient freedom to make decisions.
1. Come up with a working demo
When teams start working on a feature, the first step is to hack together something that approximates the end product even if it's barely working. However, this is not vaporware. The demo should actually work to prove that it's feasible and give a good sense of what the user experience will look like. Any premature optimization should be avoided at this step and Ken refers back to Donald Knuth's famous quote that “premature optimization is the root of all evil”.
Ken's team used the open source browser Conquerer to create the first Safari prototype in a matter of days. Conquerer wouldn't compile on MacOS, so they used a Linux emulator to run it. It was barely working and later it took months to make it work on MacOS but was good enough to show what the end result would look like.
1A. (Optional) Pull the Andon cord if you have to
Starting with demos and proving technical feasibility provides the management with an option to stop the project and cut funding before it's too late. In fact, the project can be abandoned before any production-grade code is even written.
The iPhone keyboard was such a difficult feature that Apple had to hit a pause on the entire iPhone project. Remember back in 2006, the only touch screens in existence used high-precision styluses whereas Apple wanted its users to tap with fingers. Fingers are fat and imprecise and keyboard prototypes just weren't good enough. Apple diverted everyone's focus on coming up with a working demo for a keyboard and the fate of the iPhone depended on the team's ability to pull it off. Read the book to find out how Ken solved the problem, it's my favorite part and I won't spoil it.
The point is that the iPhone leadership was brave enough to pull the Andon cord on the entire project until there was a working demo. Imagine if Apple coded up most of the software and later discovered they couldn't build the keyboard, an essential component of the iPhone user experience. That would have been costly.
2. Review, iterate, repeat
The next step is to get the demo reviewed by peers and managers. They provide feedback and engineers go back, do more work, review again, and so on until they start hitting diminishing returns. Candor and taste of reviewers as well as engineers’ ability to take feedback are critical at this stage. The best feedback is usually challenging and may be hard not to take personally but it's important to check the ego at the door and take all ideas in even if they turn your work upside down.
At some point, the work gets reviewed by higher-ups and possibly “the man himself”. This is the point where the demo becomes the spec for the feature and the design is pretty much locked in. However, it might still be held together by a software equivalent of duct tape.
3. Code it up
In this step, engineers work backwards from the demo and turn it into a solid product that works. This is where edge cases and scalability concerns come into play. Without spoiling it, I'll note that scaling the working demo of the iPhone keyboard's auto-correct was not easy. It had substantial challenges when it came to supporting the entire English vocabulary including colloquial language and intentional misspellings.
Ken describes the importance of purpose in this stage. When working on Safari, he created a testing program that ran speed tests on every commit and verified whether the change made the page load slower or faster. If the change made the browser slower, the test failed and the code had to be optimized further. In the quest to build the world's fastest browser, speed was a non-negotiable quality attribute and the page load test was the mechanism to keep the team committed to the purpose.
4. Converge & ship
The final step is to drive bugs down to near zero. In the age of cloud applications and automatic software updates, it's easy to release buggy software because you can always update it later. This approach has its merits but, if you work toward a specific launch date, e.g. driven by an event, it makes sense to minimize user frustration and embarrassment that bugs might cause.
Apple called this process the “convergence” and had a special bug tracking tool to facilitate it. Ship date and bugs are two opposing forces and, in the business Apple was in back in mid-2000s, it was important to get it right the first time. Remember, computers were shipped physically with software installed on them. Getting it right was a big deal and it still is for big bang launches and major software updates.
Conclusion
The Apple feature development process uses a triad of vision, design, and engineering to create great features customers love. It all starts with a north star vision, followed by a demo that is 90% design and 10% engineering, concluded by high quality software engineering to make the feature ready to ship. By following this process, teams can define end-to-end user experience and assess technical feasibility early in the development lifecycle.
PS — This post is not endorsed by the book's author in any way. I simply loved Creative Selection and can't recommend it highly enough. It's written in a genuine narrative form and is full of insight and interesting stories. The Audible narration is done by Ken Kocienda himself, which makes it even more engaging.
