Everyone admires the quality of products from industry leaders like Apple. While you may not be able to manufacture like Apple, I often hear from engineering and operations leaders who want excellent quality and field performance. Some leaders mistakenly think Apple products are so good because of their design -- as much as this former design engineer would like to take credit, it's not the case. Apple products feel so high quality and perform so well because of execution. Apple is excellent at manufacturing execution. The entire culture is built around execution for the benefit of the customer. Apple employs legions of people, can throw millions of dollars at any problem, doesn't blink at starting production at 50% yields, and works with top-tier suppliers in every category. But it's possible to build an execution engine to deliver high-quality products in any company where leadership is willing to lead the way.
If you're not Apple, you've got to get clever and scrappy.
Assess your team and unique advantages
What players do you have to put on the field? Many leaders are operating with leaner teams than they would like -- fewer PDEs, fewer dedicated quality engineers, and limited test engineering resourcing. Some leaders have shifted from a Contract Manufacturer (CM) model to a Joint Development Manufacturing (JDM) model to bolster their team while keeping development costs low.
What advantages do you have to add to your execution engine? Perhaps you have a talented EPM who can really keep everyone on schedule. Perhaps you have a great factory that really acts like a partner. Perhaps, like Dave Nazzaro, a former Apple engineer who became an engineering leader at medical device company Insulet, you are building a regulated product and can leverage the structure of the regulations to create clear-cut product requirements.
Build a culture of execution
Wherever there are people, there are cultural forces in play. Culture can provide "free" advantages to teams -- and while cultural change isn't necessarily free, it is possible. As leaders, we must realize that every culture has positives and negatives and that we may inadvertently reinforce negative or toxic behaviors across the team with how we react or focus on in our public discourse.
For example, suppose you are constantly pressing on the schedule in public meetings -- and perhaps your team feels that pressure is beyond reasonable. I remember sitting in a meeting during Apple Watch NPI with Apple's COO, Jeff Williams, who was in charge of the project at the time. Jeff Williams is an excellent operational leader, and he has built a strong execution engine at Apple, but he's not an NPI leader. He was pressuring the NPI team to send engineers out before all parts had docked for the upcoming engineering build -- arguing that even if there are two parts there, the team can still learn. Ultimately, the team was arguing over the difference of just twelve hours, and the poor engineers (me!) being put on a plane were very clear on how much their time was valued by the organization (not much). The mindset and culture that served Jeff well in executing production programs, felt out of touch and extreme for an NPI program. As a result, this program evolved to have a "fake schedule" that wouldn't cause objection from leadership but did not represent the team's reality. Inevitably, the "fake schedule" would have to change and cause a delay purely fabricated by the cultural pressure from leadership.
As an alternative, consider how Sam Bowen, former engineering leader at Peloton, drives a schedule with his team. He has weekly meetings where he meets with EPMs to understand the new blockers and challenges the teams face. He builds a culture of trust and psychological safety where those team members can share the reality of the situation. As a result, Sam has a much better understanding of the program maturity and can prioritize or marshall additional resources to attack the most significant risks to the schedule.
Building a culture of execution requires thought and commitment from leadership. One way to start is by defining principles for the team that will lead to the outcomes you want. An example relevant to the above stories might be transparency around reality. Still, you'll need to ensure that following that principle is protected and rewarded within the organization.
Invest in the "right weight" of process
Instead of thinking light-weight for process, think "right weight." Given your team's resourcing, the complexity of your design, and the product requirements (safety, function, regulatory, business impact), determine your non-negotiables for the NPI process. The Shedletsky Test outlines twelve, but at the core are the following:
- You need a realistic schedule that balances aggression with what everyone can buy into
- You need functional testing and reliability testing based on realistic product requirements
- You need a reasonable issue discovery, tracking, and resolution process
- You need a factory that acts like a partner and will proactively communicate issues
If you have more resources, do more. But bolstering the processes and workflows around these core pieces are a must.
If I can make a personal assertion about anything -- it's to invest in serialization and direct access to serialized data (that doesn't require reaching out to your manufacturing partner). Data is the core of any execution engine, particularly in NPI.
Leverage technology to amplify what you have
Get speed by leveraging off-the-shelf parts, reference designs, and technology. Don't try to DIY elements of your product or process that are not unique or core to differentiation. Reinventing the wheel is a waste of company resources. Find partner vendors whom you can trust to augment your team. Don't just assume that you "have no budget" -- analyze the opportunity to impact business metrics by launching on time, improving first pass yield (FPY), and improving margin. You'll find that you can create money to invest from the savings of operating faster or leaner.
Data is one area where you may be tempted to DIY, as many teams have the competencies on staff to build something basic. Having seen multiple small and large teams attempt this: it's just not worth it. Data is only useful if it's easy for any problem solver on the team to access and easy to manipulate and learn from. Getting to that level of integration and ease is much more than the "weekend project" an ambitious data science team might think it is -- you can ask me how I know :)