Competing approaches to deadlines and excellence

Some people see deadlines as guidelines to aim for, not absolute dates by which a deliverable is expected by

This view of deadlines as flexible guidelines can be seen throughout western culture, as exemplified by the ongoing, oft delayed Brexit negotiations. However, deadlines also compete against other factors in any project. Consider the three constraints in the project management triangle:

• Time
• Budget
• Scope

Those three constraints are part of a humorous phrase that almost everybody who’s worked on a project of any sort is familiar with: “pick two: good, fast, or cheap,” as illustrated with this diagram:

American business writers often emphasize the need for “good” over “fast.” Consider the following, oft-repeated quote¹:

People forget how fast you did a job-but they remember how well you did it.

That focus on quality over schedule is part of a larger trend that has been taking shape in many Western countries since at least the 1980s (see the slow food movement). But how do we know that time will result in quality? How do you manage a project without a deadline?

Others see the march of time as an inevitable, unchangeable constraint, and deadlines as inviolable milestones in the pursuit of excellence

In some organizations, missing a deadline can be a career ending failure, and even if it does not end a career, it brings great shame to the person, the team, and the organization. Because of this, deadlines are treated as do not exceed dates² that stand as the central constraint governing the activities and decisions of every project.

This does not mean that these organizations will accept poor quality work or that they can commit a larger budget/headcount to a project. Instead, it emphasizes the importance of regular deliverables and iterative improvement over dramatic-but-unpredictable deliverables.

This also does not mean that those organizations don’t make big bets on long-term technology projects. Instead, these organizations have developed practices to manage the risk of big, long-term projects.

How Apple delivers excellence on a deadline

Consider Apple, a company that has taken famously long bets on technology. Serious work on the iPod—the product that transformed Apple into the company we now know today and changed multiple industries—started with a six week contract:

Fadell brewed up three prototype designs for a potential Apple music player, each model crafted from foam core boards with rough interface graphics pasted on. Lead fishing weights gave each mock-up the approximate weight of a final device.

“It was all very, very rough,” recalls Fadell. “I only had six weeks and it was only me really doing all the work.”

Fadell was following in the footsteps of Doug Engelbart and his team, which prototyped the first computer mouse in wood (and it was just one of many, many prototypes of input devices Engelbart and the team built). Fadell’s goal at the time wasn’t to build a product, the goal was to explore what products could be built³.

The timeline from the start of Fadell’s contract to Steve Jobs’ introduction of the iPod was about nine months. But Apple didn’t only bet on Fadell. In parallel to Fadell’s contract, Phil Schiller, Apple’s Senior VP of Worldwide Product Marketing, had people on his team working on prototypes. The click wheel that became iconic to the iPod came from that work and was presented side-by-side with Fadell’s prototypes, and the final iPod used aspects of prototypes from both. Steve Jobs monitored progress closely along the way:

At the beginning of the project, Jobs held meetings about the iPod every two to three weeks, but when the first [working] iPod prototypes were built, Jobs became involved daily.

Exactly who set the holiday 2001 deadline for release is unclear. Macworld credits Fadell, but Apple’s digital hub strategy that led to the project had been in development for some time by the start of 2001, and Apple leadership had established a number of constraints and targets for the project before the first call to Fadell. Nonetheless, the iPod’s origin story captures a few critical details of how Apple manages risk on a project:

• Minimal prototypes to tangibly test and demonstrate ideas
• High frequency feedback loop with short cycles between project reviews
• Hedged bets with multiple teams

The story of the iPhone provides similarly interesting insights. The full stories at Cult of Mac and The Verge, as well as Rene Ritchie’s video are all worth your time (also: Wired adds context about what the iPhone changed). One story about the development of the iPhone offers a particular example of how even the best efforts to reduce risk have limits. Just weeks before the planned iPhone introduction at Macworld, Jobs met with the iPhone team leaders:

It was a late morning in the fall of 2006. Almost a year earlier, Steve Jobs had tasked about 200 of Apple’s top engineers with creating the iPhone. Yet here, in Apple’s boardroom, it was clear that the prototype was still a disaster. It wasn’t just buggy, it flat-out didn’t work. The phone dropped calls constantly, the battery stopped charging before it was full, data and applications routinely became corrupted and unusable. The list of problems seemed endless. At the end of the demo, Jobs fixed the dozen or so people in the room with a level stare and said, “We don’t have a product yet.”

With the iPod, Apple deftly assembled a number of commercially existing technologies—the OS, low-power CPU, 1.8 inch hard drive, and click wheel—into an outstanding product that brought the company the financial stability it needed to take on bigger, riskier projects like the iPhone. Both projects, however, progressed along a series of milestones, each one a deadline in itself.

Apple would have been brutalized in the press if they had nothing innovative to show at the January 2007 Macworld event. They’d already announced that the latest update to MacOS X would be delayed and there was no exciting new Mac hardware in the pipeline for 2007. The company that had delighted everybody with regular and consistent progress was at risk of missing a deadline. But, of course, Apple did have something else up its sleeve: Apple TV⁴. In the end⁵, Apple introduced both the Apple TV and the iPhone in what many consider to be Steve Jobs’ best keynote ever⁶.

For a company known for its intense focus, for “saying ’no’ to 1,000 things” it might appear to be a contradiction that Apple is hedging its bets with multiple product development pipelines, and pursuing multiple paths for each of those products. Apple’s focus is in knowing when to terminate a project or an approach to a product. Apple understands that the only way to truly evaluate something is to prototype it, and then iterate the prototypes that show promise and quickly terminate those that don’t.

In short: Build prototypes. Build them quickly. Iterate them fast, and work to perfect them, or you don’t have a product.⁷