Creative Selection describes Apple’s product development process during the creation of Safari, Mail, iPhone and iPad. It was an approach that was characterised by prototype demos and feedback.
Reading Creative Selection, Ken Kocienda, maddens me. First, there were no product managers at Apple. As a product manager, realising that the most vigorous and innovative phase of Apple, during the iPhone development, no product managers were involved; is a reason for me reflect on my career choice. Second, there were no distinct sprint cycles. As a person who experiences sprint cycles like the sunrise and sunset, or ins and outs of tides, it is surreal. Instead, they used non-periodic demo showcases and convergence. Third, there were no usability tests or user interviews; iPhone was developed in secret. So it really challenged me on a some meta level about my role as a product manager.
No Product Managers Needed. Teams, consisting of dev and design team members, in Apple took a feature, i.e. iPhone keyboard, from r&d to deployment. No product managers were needed to write tickets, prioritise the backlog, prepare wireframes. I do not believe that my product management work is non-essential, so let me show you how I think the function of a product manager is delegated. First, a developer is made Directly Responsible Individual of a feature. This means he defines, prototypes, pitches, refines and debugs that feature. Prioritisation and manpower allocation logic, i.e. what and who to build, is defined at Scott Forstall, SVP of Engineering, and Steve Jobs level. In this sense, the work of a product manager is taken up by other existing roles.
Why This Works & Why Not? This works because the responsibility and deliverable is very well defined. Ken takes on a singular focus as a keyboard developer for over two years. This works because it allows the person to bring an idea from conception to execution. And this constitutes the sincerest form of self-expression and I would argue this is probably the most motivation form of work.
Why this does not work? Most management teams do not have this runway. Most managers would not have the long term grit to see an uncertain project like this through. (Remember that Newton failed because its typing interface was widely criticised for its difficulty). Most managers cannot focus on doing so few things. Staff rarely stay that long. Most staff will not be sufficiently competent.
No Sprint Cycles. There were no sprints. No fortnightly increments. No sprint planning. No tickets. What there was in it’s place were demos. Demo showcases to team mates, managers, then Steve Jobs. And, later, a bug list. On some level, sprints are just there to serve as a cleaner way to assuage management that work is done. So I can see that if problem spaces are well defined (i.e. iPad keyboard), then management oversight can be reduced to reviews and demos, which would be a serve as an approximation of deliverables similar to a ‘done’ increment.
Why This Works & Why Not? It works because that is how real design is done. Craft takes time, refinement and grit. In fact, the false urgency of arbitrary two week sprint cycles is the antithesis of this. Since it encourages slicing up features, rushing out bodges and jumping on problems with short term solutions. Iterations and tangible demos to colleagues with good tastes expedite the process of improving a feature, at the cost of better documented deliverables. For Apple, when it comes to the hard shipping dates, then it would transit to convergence, at which point the team focuses on optimisations and reducing bugs to close to zero.
This does not work if management gets spooked by lack of ‘visible’ progress. This does not work for staff who fear open-ended problems.
No Usability Testing. To me this is fine. I believe that our colleagues make good approximation of users and our intuition can be trained to work out design problems effectively. Here’s a quote:
“Without a person at the helm who thoroughly understands the principles and elements of Design, a company eventually runs out of reasons for design decisions… Without conviction, doubt creeps in. Instincts fail… When a company is filled with engineers, it turns to engineering to solve problems. Reduce each decision to a simple logic problem. Remove all subjectivity and just look at the data. Data in your favour, okay launch it. Data shows negative effects? Back to the drawing board. And that data eventually becomes a crutch for every decision…
Yes it is true that Google couldn’t decide between two blues and so they tested 41 shades between each blue to see which one performs better.”
-Douglas Bowman
Integrating the ideas in the book in my life was difficult and occasionally existential. The book was non-formulaic/prescriptive in saying what works. But yet, it was enlightening as it showed a glimpse into how things could really work well (remember that the Apple today is different from his snapshot of Apple).
I’ll close with his ending quote:
“Get busy. Decide what it means to do great work, and then try to make it happen.”
-Ken Kocienda