I re-read Creative Selection last week to recall learnings from Apple. How to really apply and not just read through the book in praise of Apple. How the judgment happens in real rooms, between people who are half-sure and short on time. All applicable and true things for us as well.
Ken Kocienda’s stories about the iPhone keyboard, Safari, and autocorrect are ordinary if you strip the Apple glow off them. A few engineers and designers built things, showed them, argued, and fixed them. Over and over. What stood out was the rhythm of build → demo → feedback → repeat. Every decision lived or died in that loop.
At work, nothing makes sense until you touch it. You can debate for hours about the right water-dispensing motion or button feedback, but the moment someone builds a crude prototype, the argument ends. We’ve printed nozzle caps overnight, 3D-scanned parts, taped LEDs to plastic sheets just to see how something feels. Half the time, the prototype doesn't work. But even a broken demo teaches faster than a perfect render or PRD document.
This book was a reminder that you can’t preserve taste but by forcing work to be seen early and often. Demos drive judgment.
Demo culture
A demo is proof. No matter how crude a demo is, there's no hiding behind a document or talk.
At Apple, every idea had to be shown. If you built something, you stood in front of people and made them use it. No slides, no disclaimers. The thing either worked or didn’t. Most teams confuse that with “sharing progress.” through review meetings, making decks with hypotheticals and screenshots. They hardly confront in a real demo where learning can be faster.
I’ve seen both. When we were testing a new lever tap for the purifier and how it'd go in the fascia, we spent days debating ergonomics and angles. Everyone had opinions until we print a crude 3D model and it shows that the tap could leak, isn't looking great, feels unfinished and suddenly, everyone immediately knew what to fix. The conversation flipped from “what if” to “try this.”
That was the rule Ken Kocienda kept repeating in Creative Selection. If you wanted an opinion, you built a demo. Talking didn’t count.
When he worked on Safari, he built a rough browser that could render one page. It lagged and looked like a high-school project. But it proved one thing: WebKit could work. That single demo changed the argument from should we? to how fast can we?
Same story with the iPhone keyboard. Dozens of prototypes with tiny tap targets, predictive layouts, sliding keys failed. Kocienda carried his laptop around, asking people to type nonsense sentences. Each time, he watched their faces, counted mistakes, and rebuilt the code. That loop created the final multitouch keyboard everyone now takes for granted. It was iteration.
He mentions another moment when the auto-correction system first appeared. In a demo, a tester typed “thw” and it flipped to “the.” Small thing, but everyone in the room felt it. That flicker of magic told them the system was alive.
Even the first cut-and-paste demo went wrong. Kocienda forgot to clear the clipboard, and random text pasted into the wrong place. Embarrassing but the bug revealed what needed fixing faster. The demo failed, but the failure saved weeks.
The real learning from the book is that a demo is the shortest path between confusion and truth.
How to give feedback during demos
Ken Kocienda’s world ran on brutal feedback. We have read stories, watched reels on how brutal Steve Jobs or others were. Anyway. In the book, feedback wasn’t a group activity. He’d show something to one or two trusted people first, not a full committee. You needed a few people whose taste you trusted enough to hear the truth from.
When he demoed the first version of the iPhone keyboard to Scott Forstall, the space bar didn’t register right. Forstall said, “It doesn’t feel right.” That was it. Three words. Ken knew exactly what to fix because the problem was experiential. That kind of feedback only works when everyone speaks the same unspoken language of quality. Forstall could say “doesn’t feel right” because both of them had typed on a hundred demos before that. Shared exposure builds shared taste.
Generally, feedback is usually democratic. Everyone comments on good, bad, ugly but nobody owns the decision. The more often people see good work, the better they judge.
Cascading taste in teams
Everyone at Apple built, demoed, and re-demoed until judgment became muscle memory. At Apple, new engineers watched senior people build demos, get shredded in reviews, fix things overnight, and come back the next day. That cycle created pattern recognition and judgement absorption.
One example: the keyboard team. Every engineer built their own typing prototype with different layouts, tap zones, algorithms. They competed through demos. The winning version was Ken’s “QWERTY” model with auto-correction. It was chosen because it 'worked' when tested in the hand. That process made every engineer internalise what “working” meant. After that, taste was data they had lived through in the demos.
Apple also had cascading reviews. Kocienda demoed to Forstall. Forstall demoed to Jobs. Each level compressed the judgment of the level below. When Jobs said “ship it,” it meant the collective filter had done its job. Everyone trusted that if an idea survived all that, it was good enough for the world.
That’s how taste scales: through repetition, reference, and ritual. You create conditions where every person sees enough great work, enough bad work, and learns the difference fast. Kocienda also writes about the hallway demos where people show work to whoever passed by. That informality mattered. Every interaction became a calibration point. Over time, the culture taught itself.
You got better because you saw better. Simple as that.
The risk of demo culture
Demo culture looks clean in hindsight. After all, we read it in a book on Apple's culture. In practice, it’s messy and political.
When every idea lives or dies in a demo, people start designing for the demo. It’s easy to chase reactions instead of truth. Ken admits that some engineers built flashy prototypes just to impress Jobs or Forstall. Demo culture can breed showmanship if you’re not careful.
Another risk (and a big one) is dependence on strong filters. Apple’s system worked because it had reviewers with great taste. Jobs, Forstall, a handful of others had worked hard towards building true taste. They could look at a screen and call out what felt off. But when judgment is centralised, it becomes a single point of failure. After Jobs left, that precision faded. When the right people left, so did the quality bar.
There’s also the mental cost. Ken calls out that demo days where a single “no” from Jobs erased months of work. No explanations, just point-blank rejection. It made the survivors sharper but burned others out. The loop that builds taste can also destroy morale if you don’t balance pressure with recovery.
The pre-requisites of a good demo culture are true trust, honesty, and shared taste standards.
Intuition vs. data-driven world
In the book, Ken Kocienda’s process ran on instinct first, validation second.
When he built the iPhone keyboard, there was no research deck proving people would accept tiny on-screen keys. Every logical argument said it wouldn’t work. People’s thumbs were too big; precision too hard. If Apple had run a traditional usability test early, the project would’ve been killed. But the team trusted what they could feel. They typed, watched, adjusted, and typed again until it started to “click.” The confidence came from their own hands, not survey scores. People who don't have instincts fallback on surveys.
Jobs protected that intuition deliberately. He refused to let focus groups lead. He’d say, “People don’t know what they want until you show it to them.” Brutal but true. In the book, Ken recalls times when Jobs overruled data entirely. Engineers would adjust the spring physics, flick the phone, and pass it around until it felt natural. Just shared instinct.
That kind of decision-making doesn’t scale easily. Intuition is hard to build. Probably, why we have just one Apple. So they hide behind validation frameworks like surveys, team votes, NPS, CTR, funnel drop-offs or anything that gives the illusion of certainty. The irony is that over-measurement kills the very muscle that creates good judgment. You stop noticing how things feel because you’re too busy proving they work. At Apple it was intuition and then metrics to confirm that the intuition wasn't delusional.
What this changed for me
This time when I picked up Creative Selection, I was certain that I wanted to take specific notes on how to apply them at work. And there are a lot of corrections I need to make and cascade in the team.
The biggest shift for me was in how I see process. Everyone seeing the same thing is important. Demo culture is that exposure. Everyone sees the same thing, feels the same texture, hears the same “not yet.” That’s how taste scales.
The other thing is consensus. Consensus is what happens when no one wants to own judgment. Apple’s teams worked because someone always did. Someone said “too slow,” “feels wrong,” “ship it” and took accountability.
Ken’s book also changed how I look at confidence. It's honestly scary when you're building hardware from the ground-up and are taking all sorts of non-reversible decisions. The kind that comes from seeing your idea fail fifty times and still walking back in. He called it “creative selection.” I think it’s just surviving long enough for your instincts to sharpen.
Maybe in India, we don't have a demo culture yet. We have presentation culture. We over explain, oversell, and under-deliver.
In tech and design here, “taste” is often mistaken for branding, or worse, for elitism. But at Apple, people were trained to care about the smallest details because those details would touch millions. That’s public taste. We don’t have enough of that. Most products here are built for “working” first, “feeling right” later. If something leaks but sells, it passes. If an app loads but looks ugly, it ships. The loop between building and judgment is broken because speed and survival win every argument.
Imagine if that changed. If every hardware company or design studio here treated demos as the highlight of the week. Everyone shows what they made. No slides. Just the thing. People touch it, feel it, comment, fix it, repeat. Over time, that rhythm would raise our collective eye for quality faster than any design school can.
That’s how countries develop design languages as well. The Japanese did it with craft. The Swedes did it with function. Apple did it with iteration. We’ll do it when builders here stop defending ideas and start showing them earlier.