Powering the Product Development Process At Apple
Note: If you are interested in an opportunity to discuss product development, join me in the LPPDE North America Conference on Oct 1 & 2! https://www.lppde.org/LPPDE-North-America-2018-Columbus-Ohio.
Even billion dollar companies aren’t perfect.
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.
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 were causing. 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 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, an approach I use regularly with my clients.
Step One: General Assessment
Bradford and I took a general assessment and used its findings to pinpoint a small number of improvement levers. 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.
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:
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.
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.
Step Four: Implement
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.
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.
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.
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.