Example Reflection – Learning Launch

Challenge    I am a member of my company’s process development team for one of our core products. Our  customers gave us the challenge to aggressively improve the performance of a widely adopted product  in the field. This heavily used product has been used in the field for over a decade and has reached the  limits of its performance as customer specifications have tightened. Our challenge is to develop a  hardware improvement package that could retrofit the existing product to improve the performance of  the tool. Our customers have given us 6 months deadline to develop, test, and validate improved  performance of the new hardware in order for them to consider adoption of the new part. The  hardware improvement package has constraints due to the existing product framework in the field, so  we are limited in the manners that we may modify the existing tool.     Selection    Because the process, hardware, and modeling team had already done thorough characterization of the  existing product, we already had ideas on how we might want to improve the hardware. We decided to  use the learning launch tool because of the time constraint placed on us by the customer. As mentioned  in the video, “the key here is to do experiments that are fast and cheap”. So, we used the learning  launch tool to test multiple hypotheses and paths to improve the hardware. Due to time delays of  acquiring hardware, we knew that we had to model, order, and test competing hypotheses of hardware  modifications in parallel to find the best path to achieve our performance benefit and meet the time  constraint by the customer.    Application    In order to apply the learning launch tool to our hardware improvement project, we gathered all the  relevant stakeholders in a meeting. During this meeting, each stakeholder proposed their individual  hypothesis on how to improve the hardware and a rough sketch of the proposed hardware design. This  resulted in a list of 8-10 disparate modifications of the existing hardware with reasons on why each  potential modification would deliver the desired outcome. None of the proposed modifications were  meant to be a final product solution; they were only meant to aggressively test each hypothesis to help  us determine which path would lead us in the right direction for process improvement.    After the initial discussion, we had our modeling group run coarse (cheap and fast) simulations which  would give us a better understanding of which hardware modification plan showed a potential for  performance improvement. After 2 weeks of running simulations on all of the different hardware  modifications, we met again to review the simulation data and refine our ideas. This meeting resulted in  narrowing our potential hardware modifications to four separate ideas. We then had the mechanical  engineers working on the project design the hardware part needed to test each hypothesis.    After all of the designs were complete, the team met one last time to align on the final details of the  designs. After a few slight modifications, we sent the designs out for manufacturing. We chose to use  the learning launch tool to test multiple ideas in parallel in order to find our pathway as quick as  possible rather than simulating, designing, and testing ideas in a serial manner.

Upon receiving all the parts, we tested them as quickly as possible over a wide process window to  determine which pathways would give us the most improvement and which pathway lead us in the  wrong direction. As the video mentions, this was our method of generating data as quickly as possible to  help guide our development of the final hardware improvement package that we would eventually  deliver to the customer.    Insight:    By using the learning launch tool, we were able to quickly determine which hypotheses were correct and  delivered performance improvement and which hypotheses were invalid. The learning launch tool  helped us drop our bias on which method of hardware modification was best and enabled us to rapidly  generate data to test multiple hardware modifications. In testing our hardware modifications, we were  able to narrow down our initial 8-10 ideas into two potential paths that would both deliver performance  improvement. Also, in generating data using all the disparate hardware modifications designs, we were  able to gain a better understanding of the overall process and hardware. The final solution we ended up  providing to the customer was a combination of the two paths that showed improvement and met the  aggressive specifications established by the customer in the 6-month deadline.    Approach    Overall, I was quite pleased with the success of the implementation of the learning launch tool.  However, if I were to use this tool again, I would invite people outside of the stakeholders for hypothesis  generation. Because we were all surprised by some of the findings and data generated, I think we would  have benefited by getting some out-of-the-box ideas from people who were less familiar, and therefore  biased, by our existing knowledge. This would have enabled us to do some inexpensive and rapid  simulations of concepts that may have not been obvious or expected.

