Ken Kocienda was a software engineer on Apple's Safari, UIKit, and iPhone keyboard teams between 2001 and 2017. This book is a demo-by-demo account of how Apple actually decided what to build — small teams, working prototypes, and Steve Jobs in the room as the taste function. Kocienda's central argument is that Apple's process was not top-down dictation but something he calls 'creative selection': the team would generate multiple approaches to a problem, demo them to Jobs (and each other), and he would pick the one that felt right. The book covers the development of the iPhone's autocorrect keyboard, Safari's browser engine, and the original iPhone software, and is the closest available account of Apple's internal product decision-making under Jobs.
The core concept Kocienda introduces — 'creative selection' — is the method Jobs used to make product decisions, and it is the single most useful idea in the book. It borrows its name from Darwinian natural selection but applies it to ideas: generate many variants, test them against reality, and let the best one survive. For founders, this reframes product design away from waiting for a single brilliant insight and toward creating a system that surfaces the right answer through iteration.
Kocienda also shows that Jobs's famous 'no' was not arbitrary: when he rejected a demo, he could articulate exactly why it was wrong, and the team could try again. Founders who struggle with saying no productively should read Kocienda's account of how Jobs communicated his taste — he did not just kill ideas, he gave direction. The book also makes clear that the demo was the unit of progress at Apple: nothing was real until someone put it in front of Jobs running on actual hardware. That constraint forced the team to ship working prototypes, not slideware.
A secondary lesson: Kocienda describes the 'epiphany' that led to the iPhone keyboard's autocorrect feature, and it did not come from a focus group or a competitive analysis. It came from a single insight about how the human brain processes typing errors, which Kocienda then implemented in a demo. Founders should take from this that deep domain expertise applied to a concrete problem is more valuable than broad market research, and that the best product insights often arrive as a surprise during implementation, not during planning.