Skip to content 
Apple’s NEW Product Development Process Case Study
Many companies face internal problems because they can’t see the bigger picture.
I came face to face with this reality while working with Apple.
What Apple had was the right ideas. What they lacked was a concise way to take those ideas and make them into tangible products; they needed product management tools to scale their new product development to the next level.
There were two major issues in their new product development process:
The first problem was having to reinvent the wheel every time a new product was launched. The second problem was that each team was interdependent on the other. One product team’s quick decision could impact the work of the parallel team. This created a possible cycle of one team destroying the progress of another.
In short, the product development process was tribal. To scale they needed to change.
Further, teams were inefficient and the weight of this inefficiency landed on manager’s shoulders. The managers were weighed down with attempting to reinvent the wheel and putting out the day-to-day fires the other product teams (and product managers) were causing in the design process. Apple struggled to achieve their largest goal, scaling up.
After their fourth attempt at identifying the product development best practices, myself and my colleague Jeanne Bradford who worked in the Cupertino HQ (working for the manufacturing and global supply manager) were brought on to find the golden intersection between idea and creation.
We took a four step approach to transform Apple’s new product process, the TCGen consulting approach we use regularly with our clients. Note that Steve Jobs is not against process, he is just against too much process. He liked to combine innovation with very rapid iteration to create one of America’s most admired companies.
Step One: New Product Focused Assessment
Bradford and I took a general assessment and used its findings to pinpoint a small number of improvement levers including improvements for the design teams. These levers fixed issues like the product teams crashing each other’s latest innovations. Each lever had the possibility of making improvement to a certain degree. We started with the levers that would have the most effect and prioritized each one into a sequence.
Predictive Metrics
For each of these key improvement levers, we created a target metric. We wouldn’t move on to the next lever until the one prior was established. We would move on to the next priority only when we achieved our target metric.
It’s this general assessment and product development metrics that separated our efforts to improve the product development process from the earlier attempts.
Step Two: Set Boundary Conditions
The most important part of transforming the product process was to establish product management tools like boundary conditions and out-of-bounds processes. This was a key part of what became the Apple New Product Process (ANPP).
Boundary conditions are a contract between the teams and management. At the start of each project, the team and management negotiate a contract around approximately five dimensions of a project:
- Product Cost
- Features
- Schedule
- Quality
- Reliability
Each boundary condition identifies the big, bold aspiration the team has for its project. The team and management then agree on quantitative thresholds for each of the boundary conditions. For example, a target cost for the product at retail or a “no later than” date for delivery of a product being shown at a trade show.
The success of the boundary conditions process lies in defining a quantitative metric for each dimension.
As long as each team expects to remain within its pre-defined boundary conditions, upper management leaves the team alone. If the team predicts they are going to cross a boundary, called a boundary break, then they have an escalation process. This process is the out-of-bounds process.
There are two solutions for an out-of-bounds process.
Solution #1: The team sends an email to management proposing the solution to the boundary break. If management agrees to the team’s solution, a new quantitative metric is agreed upon and the team proceeds as it was.
Solution #2: If management doesn’t agree to the team’s solution, then a meeting is held where the management and the team come to an agreement and create a new quantitative metric as their target.
After the out-of-bounds review is complete, the team and management continue as they were. This approach ensures teams don’t get micromanaged and provides a clear escalation path if projects don’t go according to plan. This measure ensured that we did not run afoul of manufacturing practicalities, and the we followed rules of the road, supported the design team, the development team, Engineering Project Management (EPM), Global Supply Management (GSM), all the way to the final product.
Step Three: Overcoming the Cultural Hurdle
Convincing management to empower the teams was a major challenge. For example, when we asked managers to remove weekly status meetings, they refused. Despite knowing a team was working within boundary conditions, they still wanted weekly updates. This created a repetitive, time wasting system.
If a team was within their boundary conditions, set to meet their quantitative metrics for each dimension, there was no need to hold an hour long meeting to explain their progress to management. Management knew their progress already because they were within their boundary conditions.
We continued to find resistance in many culturally normal Apple practices, finding ourselves having to convince employees this process was going to make their jobs easier. Some of the biggest elements that we had to work within was their product design process (including industrial design and user experience design) as it was very important to preserve or even enhance it.
Apple’s design process and leading with great products is fundamental to who they are. Jony Ive was a true second voice that married great design with functionality. It sets Apple apart from other great companies like Amazon and Microsoft.
Step Four: Implement Apple’s Product Development Process
After we convinced employees that they would be happy with these changes, we implemented a test trial. We tested our product process with several teams and key executives. This was mainly a learning exercise to understand the specifics of implementation. With a full understanding of how our process worked in real time, we held a workshop to train all relevant stakeholders including several sessions with the executive team.
Teams working within boundary conditions consumed less of management’s time. When projects strayed from their initial goals, the out-of-bounds process kept the project’s momentum while we moved toward achieving our quantitative metrics. One of the most successful parts of our process was in the improved relationship between management and teams. Apple was no startup when we worked with them, so the team and management needed to work together – and they did.
Bradford and I successfully transformed Apple’s new product development environment. We felt real success when the head of product marketing claimed Apple was making decisions faster than ever before. This new process was a vital piece in enabling the company to meet its number one goal, scaling up and delivering a great (if not splashy) product launch with each new product.
The ability for companies to scale depends on achieving product development maturity. If your process is built on quantitative results with sideline processes established to fix unforeseen problems, you will be able to achieve Apple’s largest mission.
Apple has continued to scale for years. ANPP is now the guiding principle with iphone, ipad, ipod imac, and mac (Macintosh) business units.