Subscribe: Google Podcasts | Stitcher | TuneIn | RSS

Sleek and simple: How Apple’s product process mirrors the products it creates.

One of the things I enjoy doing is teaching product and innovation management university courses. My students often are in a leadership role in their organization and I’m helping them with product innovation. When we discuss examples of innovative organizations, Apple is a popular choice. It’s also a good choice. They provide many lessons, such as the power of trends, why focusing on fewer products is better than scattering your efforts, the advantages of controlling an ecosystem, and the benefits of the fast-follower strategy.

So, when I was at a product conference and met the person who helped orchestrate Apple’s original product process that is still used today, you can understand why I was excited. This was my opportunity to learn first-hand what Apple was struggling with and how the new adopted product process helped them.

That person is John Carter. In addition to Apple, he has been a valued advisor to Cisco, Dolby, HP, IBM, Xerox and others. In addition to innovation, he has a strong background in engineering and was the co-inventor of the BOSE Noise Cancelling Headphones.

I could share a lot more about John’s accomplishments, but the recommendations from employees and clients on his LinkedIn profile are more insightful. One shares…

“John Carter has one of fastest and best minds you will ever encounter. At the same time, he is careful to listen to and integrate the ideas and insights of others. He’s open-minded and ethical and knows what risks to take and when. If ‘cool-hand’ John Carter is in your corner, be prepared to win!”

In the little time I have known John, I agree — he is one to learn from, which is why I asked him to join us and discuss the creation of the Apple product process.

Summary of some concepts discussed for product managers

[3:12] What was the product development environment like at Apple when you started?

I worked very closely with two individuals: Jackie Streeter, who ran the central engineering organization, that delivered tools and process management across the company, and Bonnie Collier, who was a collaborator on the postmortem process. The situation was that the company had run out of gas in scaling. They were trying to quadruple the number of new products introduced each year and they were not able to scale. Everyone from program managers to executives was feeling the pressure and there was an urgency to make a change.

[6:35] What changes did you make at Apple?

What we put in place was very lean in the number of deliverables, in the decision making, in the number of phases, and in terms of how issues were escalated. It was successful because we trimmed out the extra weight. There were 3-4 phases and each had 1-2 deliverables, but there was an exception management process to catch things that did not fit into those phases or deliverables.

[8:52] What were the phases and deliverables in that process?

The process had four phases: investigation, concept, development, and validation. The investigation phase is free form and the only deliverable was a few pages describing the business case and the problem being solved for the customers. During the concept phase, the deliverable was a high-level design and delivery details. Next is the development phase, which ended with the go-to-market plan. Finally, there was a short validation phase. There wasn’t a lot of executive oversight and teams had a short path to resolution on conflicts that arose. Management reviews took place by a cross-functional team of executives who didn’t have to leave the room to make a decision. It was very clean, no second-guessing.

[13:58] How were products eliminated through this process?

They spend a lot of time in alternative concepts and they tend to kill things very early. It’s a heavy intersection between design and product development and features. Steve Jobs has been quoted as saying that product design is more important than product performance and I think that shows in Apple’s products.

[16:55] What is the post-project process?

The Project History Process combines fact-based project history data and interview data to create an event timeline. This includes planned and unplanned events. The team then determines what unplanned events had the most impact, what caused them, and what they can do to avoid them moving forward. With a lightweight process, it provides a guardrail for addressing systemic problems. It’s still used today at Apple and delivers real insight. It’s the opposite of a blame game that often occurs during postmortem sessions.

[20:43] Why metrics did you use and how did you measure acceptance?

Measuring performance and outcomes is a passion of mine and is something I brought to Apple from my work at Bose. We used two sets of metrics: static and predictive. Static metrics include slip rate, time to market, and percent of sales spent on marketing and R&D. These are great for benchmarking because they are pretty much universally collected. Predictive metrics provide a much faster readout that can help you forecast what the static metrics will be. They measure change by looking at changes in behavior. If people don’t behave differently, you’re not going to see results. For example, are people using the new terminology we trained them on? These metrics changed every week or two and were valuable for gaining buy-in throughout the process. Each metric had a target curve that we used to track adoption. A gap between the target curve and actual adoption led to doing root cause analysis and make sure the process was moving forward.

Useful Links

• John’s innovation company, TCGen
• Connect with John on LinkedIn
• Articles John recommended during the interview:
  • “New product development: a roadmap for business success in the ’90s” by Jackie Streeter
  • “A Defined Process For Project Postmortem Review” by  Bonnie Collier
  • “Apple’s Product Development Process – Inside the World’s Greatest Design Organization” by Adam Lashinsky
  • “The Secret of Apple Design” from MIT Technology Review

 

Innovation Quote

“Better implies different, not the other way around.”  – Dr. Bose

Thanks!

Thank you for being an Everyday Innovator and learning with me from the successes and failures of product innovators, managers, and developers. If you enjoyed the discussion, help out a fellow product manager by sharing it on social media.