Apple’s NEW Product Development Process Case Study
Just as often, and potentially more, they 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 tangible products through product management tools to scale their new product development to the next level of Apple products.
There were two major issues in their new product development process:
The first problem was in each team 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 teams 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, a product development process was tribal and they knew to scale then needed to change.
Teams were inefficient and the weight of this inefficiency landed on manager’s shoulders. The managers were weighed down with attempting to invent 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) brought us 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.
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. Only when our target metric was made would we move on.
It’s this general assessment and product development metrics that separated our product process from the earlier systems.
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 ANPP (Apple New Product Process).
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
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 teams solution, a new quantitative metric is agreed upon and the team proceeds as was.
Solution #2: If management doesn’t agree to the team’s solution, then a meeting is held. Management and the team will 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 ensured that we did not run afoul of manufacturing practicalities, 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. This 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 in momentum while moving 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 – which 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.
To continue to scale for years to come. ANPP is now the guiding principle with iphone, ipad, ipod imac, and mac (Macintosh) business units.