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:
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 quote1:
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 dates2 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 built3.
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 TV4. In the end5, Apple introduced both the Apple TV and the iPhone in what many consider to be Steve Jobs’ best keynote ever6.
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.7
Forbes features the quote in sharable form, but there are few sources of information about its author, Howard W. Newton. Newton, who lived from 1903 to 1951 (source), was an American advertising executive (go to page 60 in this PDF) credited with a number of quotes used in contemporary business culture (see the numerous search results for this one quote). Huge thanks to Ed Vielmetti for his help researching this question. Unfortunately, my attempt to start a Wikipedia stub about Newton was rejected. ↩︎
Watch and listen carefully to how people describe the date for a deadline or deliverable. Some name the first day of the month, others give it as the last day of the month. My experience is that those that name the first day of the month often mean “shortly after the first of the month, or some time in the month,” and those that give the end of the month often mean “some time this month, absolutely no later than the end of the month.” ↩︎
Some people call this “pretotyping”, but I really can’t bring myself to use that word except when held with tweezer quotes. Still the emphasis that there are multiple stages of prototypes is valuable:
The primary purpose of prototypes is to answer questions such as:
- Can we build it?
- Will it work as intended?
- How small/big/cheap/energy-efficient can we make it?
The primary purpose of pretotypes is to answer questions such as:
- Would I use it?
- Would other people buy it?
- If they buy it, would they actually use it (more than once or twice)?
Apple is hardly unique in its penchant for hedging bets. The Samsung Innovation Museum (tour) proudly tells the story of how Samsung long ago established parallel development tracks for many of its product lines so that they can work on both next generation solutions, and solutions that might affect products in generations after that. ↩︎
This story would be horribly incomplete if it didn’t also acknowledge the intense individual efforts of so many people to meet those deadlines. Steve Jobs drove Apple employees like none other, encouraging them both to achieve greatness they didn’t know themselves capable of, and to make compromises (deeper reading). During the development of the original Macintosh, Jobs bragged to the press that the team was working 90 hours a week. Years after the iPhone’s launch, stories of broken marriages emerged. How to build greatness while maintaining healthy work environments and work-life balance are questions that many companies are just now trying to figure out. ↩︎
Sadly, the video from the keynote is not in Apple’s event podcast feed or on Apple’s website. Some have posted it to YouTube, but edited to remove significant sections. Strangely, NBCUniversal/Comcast have made a copyright claim against a key moment in Jobs’ intro, which caused many videos to be taken down entirely. ↩︎
To be clear: there’s no shame in trying something that leads to a dead end. The shame is in not trying, and not moving on from dead ends. Keep trying until you get there…do a lot of work. And even after you think you know everything, keep building prototypes and testing ideas. ↩︎