Creative Selection is a recently published book by one of the developers involved in the original iPhone program offers good insight into how Apple was able to bring to market a game-changing device. This is all from the vantage point of one the developers, not an executive. This view offers some unique insight into how a large scale product development effort can work – and in this case, work exceptionally successfully. I was particularly interested in the ways the process at Apple mirrored some of the best research-backed advice about how to manage product development. Going thru a large scale Agile transformation now, I found the parallels to advice in frameworks such as LeSS comforting.

“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.”

A commitment to learning is so rare in most companies in my experience; the idea that a developer takes on a role that he has no knowledge of and “figures it out” with the help of other talented folks. The company trusts him to learn and adapt – and with an iterative process, this allows for check-ins to course correct. The developer must also be open to suggestions – even with deep feelings about the work done. The point is the product – move the product forward.

This is so obvious on one level and yet so incredibly difficult to implement in practice. The work of leading a group of people in this fashion is much more difficult than the standard big business management approach of making up deadlines and metrics and acting as if the management is separate from the process. Leaders are great at fooling themselves that it’s their genius that got them to the position they hold – one has to continually be on guard for this internal monologue and beat it back. Sadly, few leaders seem to be on active guard against this.

“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.”

The default direction in most large enterprises is to either increase team size to add every little specialist’s role or split up work into smaller and smaller specialties (or both). The more I’m exposed to the issues of dealing with large teams and specialists groups the more the advice to target small teams of cross-functional people makes so much sense. In short, always move to simplify the organization. Added complexity will trick you into thinking you’ve solved a problem when in reality you are setting the stage for additional problems. Apple understood this, tellingly even in a project like the iPhone where it would have been the default step to create very large specialists teams.

“There are innumerable ways creative selection can become bogged down, since this working method must be applied consistently over some time to yield results. Consequently, our success was as much about what we didn’t do as what we did. Mostly we avoided falling into any of the typical product development traps common in Silicon Valley and that, I expect, occur often other kinds of creative organizations and businesses. “

Among the things that they didn’t do are long discussions about products devoid of concrete examples that force a grounding in reality. They avoided using artifacts that were separate from the actual work – things like requirements or paper mockups.

Perhaps most importantly they didn’t have senior managers involved in decisions which weren’t personally engaged in the work.  This is the root problem of management in some ways. The idea that they can be disconnected from he work and yet dictate, in the most disruptive way possible how the work is done. Continuously changing direction and causing confusions – but never changing the made-up deadlines they believe will push people to perform. It’s so perverse you’d think it was designed on purpose to hinder performance.

They didn’t set-up special research departments separate from the teams doing the work.  Most companies have such little faith in their front line technical people. For some reason, there is this belief in hiring “special people” to do the interesting work. Think for a second about this. The same people who best understand how your systems work, best understand your customers are getting the shaft because you’re saying that they are incompetent to do the interesting work building the future. Set aside the fact that often when a company creates these special groups, they’re staffed with people who are better at selling themselves than doing work.


“At Apple, we built out 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.”

Similar to a Sprint Review in Scrum – an opportunity for the team to show the work and gather valuable feedback that will inform the priority of the Product Owner and also what the team focuses on in future sprints. No matter the organizational model, a company, uses, this quick feedback is so critical and yet so rare.

“Scott took the chair at the long wooden table in Between, a Wallaby prototype tethered to a Mac lying on the desk. Scott picked up the Wallaby, and as he started each demo on offer in the switcher app, the programmer who created the demo stepped forward to describe how it functioned. These how-to instructions could be complicated. Some involved blue-sky interaction models, like one collogues’s complex multiple-tap scheme built around a few super-big Kays he could type on without looking. Others called for various orchestrations of multitouch input s to type letters, enter punctuation, and capitalize words. Scot was game to try everyone, and as always, he was upbeat and encouraging. 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.” 

Perhaps the most exciting point in the book for me is here you have a prototypical technology leader – not someone who’s apt to be a pushover, and yet in this context, he was sure not to crush the morale of the developers. Even in the case of a keyboard, a do or die aspect of the phone, he was still careful to provide praise where he could and not fly off the handle that the team hadn’t solved this critical problem.

Creative Selection is an engaging, quick read. Highly recommended for anyone who’s interested in how the most successful consumer product in decades came to be. There are great lessons here for anyone dealing in a complex environment. Apple wasn’t perfect in any sense, but it sure does seem like they got some things right about complex development. Things that many if not most companies get entirely wrong.