I finished Creative Selection a couple weeks ago on a flight. When I started it, I was coming off the highs of finishing Who Is Michael Ovitz and Not for the Faint of Heart -- both incredibly personal, profound, and captivating accounts of high-trajectory careers in entertainment and diplomacy.
Those are the types of books you finish quietly, hoping to remember everything you just experienced, but knowing you probably won’t. I’m so grateful for books like that. They deepen my hunger for more tell-alls of gripping negotiations, creative deals, business building, masterful accomplishments, and tragic failures.
Parts of the internet spoke highly of Ken Kocienda’s book, and I figured it was in the same neighborhood, although perhaps on a different street, as the other books. So I jumped in. These are some things that stuck with me.
The best products work so well they just fade into the background
The book started out slow for me. Steve Jobs cameos aside, I dreaded a couple hundred pages about...keyboards. (Others felt similarly, too.) Especially something as ordinary as an iPad and iPhone keyboard. Right? Those are givens. They’ve always been there and, plus, aren’t they just obvious and derivative of the regular keyboard? It’s QWERTY, our old friend.
But I kept going, picked my head up a couple hours later, and realized: it’s not obvious. It’s not a given. How stupid of me — one of the products I use the most had faded so significantly into the background, I never thought of it. It just worked. And the reason it worked is because a human thought enough about how it should work, what the user would expect, what would allow it to really fade to the background. That was always the goal.
Ken even writes that he worried the keyboard would get in the way of the human user focusing on just typing. That’s ultimately what led him and others to simplify the keyboard, even eliminating the auto-suggestions bar on top of the keyboard (it’s now back in iOS).
En-vogue startup/corporate ethos dictates customer — and thus, human — centricity, but this is a good reminder of what it really looks like in practice. Kocienda explains Apple’s practice of “the intersection” of liberal arts and technology by quoting Jobs:
“The reason that Apple is able to create products like the iPad is because we’ve always tried to be at the intersection of technology and liberal arts, to be able to get the best of both, to make extremely advanced products from a technology point of view, but also have them be intuitive, easy to use, fun to use, so that they really fit the users. The users don’t have to come to them, they come to the user.”
This reminds me of David Foster Wallace’s take on liberal arts thinking in This is Water (more on that in a later post), but it really comes down to choosing what is meaningful (users) and how to think about it (demos). For Apple, the devil’s in the details and in the rigor of the process. All the demos that Apple engineers do throughout the development process, with the constant emphasis on usability, are what are meaningful.
The feedback that comes out of those demos was pumped directly back into the product, often excruciatingly so. But it was, because the alternative wasn’t an option. As Kocienda writes: “[g]reat products make people happy almost all the time and do the opposite rarely, if at all.”
Think about that the next time you churn out a text or an email on your iPhone.
It’s all about momentum
Kocienda recalls his (failed) initial efforts to build an Apple web browser and how quickly he and his partner were blown away by a newcomer to the problem. Something he had tried for months to get working took someone with fresh eyes and an unencumbered brain just a couple days. It wasn’t a final product, but it was a big step.
Startups are all about momentum and speed (duh), but this is front and center in Kocienda’s early Apple narrative. Without this newly-created momentum, his first project at Apple might’ve failed, potentially spoiling his future at the company. Similarly, without an extremely rough, but functioning early product, a startup is toast.
What helps build momentum? Constraints. Kocienda explains:
“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.”
The biggest constraints here were time, available open-source software, and humans. Slightly abstracted, we all have these constraints: time, human resources, and material resources. How you perceive those constraints and use them is up to you, but this was my favorite part: Ken and his team used them to push towards demonstrable progress.
At a previous company, as a product manager, I often thought about how to create momentum, especially on a team of seven engineers who chafed at the idea of seemingly arbitrary deadlines (a whole other topic). We agreed on a system of, wait for it, mutually agreed-upon arbitrary deadlines, with varying levels of probability, toward demonstrable progress.
We used a whiteboard and put up each initiative we were working on, the picture(s) of the engineer(s) working on it (5x7), and the date the engineer(s) thought the initiative (or its sub part) would be complete (i.e., fully tested and deployed to production). We displayed the whiteboard to the rest of the office, where anyone walking by could see it, and incorporated it into our sprint meetings, executive discussions, demos, and retrospectives.
Among other things we did as a team, sprint after sprint, we started nailing our deadlines and shipping more higher-quality, customer-facing product, leading to happier customers.
There’s simply nothing like visible progress to build momentum.
Instinct leads to greater returns over testing
This one makes intuitive sense, but with a lot of the hub-bub around A/B testing, it can get lost in the shuffle. Kocienda uses the famous Google “blue button” A/B test to point out the incrementality in a testing-first approach and lamenting the “opportunity cost of running all the trials…[leading to] less time available for everyone on the development team to dream up a design that people might like two, or three, or ten times more.”
Listen to Keith Rabois and you’ll hear this echoed further. Product instincts have a higher likelihood to lead to 10x+ improvements than testing because instinct isn’t locally constrained like an A/B test inherently is. If there are 41 shades of blue in the test there are only 41 shades of blue to choose from. While instinct can be biased and fickle, for sure, it’s not as artificially constrained.
(This isn’t an argument against product testing as a concept, just A/B testing that avoids a decision that can be made. Product testing can be ridiculously effective.)
Overall, pleasantly surprised with the book. While some business books should be reduced to a blog post, I think the nuance Ken walks the reader through is helpful in understanding (and respecting) the decisions made, trade offs considered, and craftsmanship in building what hundreds of millions of us use every single day.