Reflection – Learning Launch 

 Challenge & Selection 

 I am a lead Design Engineer in a startup which focusses on automating mundane processes of item   storage , retrieval , and dispatch , in large warehouses . Since we provide automation solutions to   businesses , there is a lack of direct interaction of engineers with the eventual end customers . The   company started off with a small team who built a compelling solution for businesses , the adoption was   rapid and sales were good . Later , it became apparent that the designs had several hidden limitations   which the team did not anticipate early on , such as , scalability of production , reliability , maintenance ,   assembly , cost etc . While initiating the development of a new product platform , we wanted to avoid a   repeat of the mistakes made earlier . Learning launch tool was the perfect tool to get things started and   to refine our product development process . Using learning launch meant that we could iterate/ refine   various steps of our product development process quickly . As a pilot , we tested a new approach in one of   the product teams . We started by identifying our key stakeholders who could present clearer   understanding of internal and external customer demands , identify problems , eliminate decision   blindness , encourage different lines of thought and shorten development times by designing and   validating quick prototypes . 

 Application 

 We started out by scoping the review team . This team would be responsible for final approval of design   decisions and would comprise of heads from all the major departments in the organization , thus ensuring   that every viewpoint gets taken care of . Insights from the marketing and sales team were hugely beneficial   in understanding the pain points and expectations of the customers , this information was passed on to   the technical teams . We then formed cross - functional engineering teams ( CFTs ) within the organization   to work on specific modules of the product , modularizing the design was a key decision taken early on to   eliminate a cascading effect of failures identified later in the product ’s life cycle . Thus , ensuring that   correct engineering decisions get made at the individual team levels as well . 

 At the beginning of the product development , the CFTs would start by ideating on multiple design   concepts which solve the problem . The teams would then shortlist 3 - 5 designs based on evaluation by the   engineering and production teams . The engineers will then start developing mature versions of the design   and prototype them ( POCs - Proof of Concepts ) . The POCs would then be tested for technical conformity ,   in some cases scaled prototypes would also be built to reduce cost and time . After eliminating the   concepts which had fundamental drawbacks , the remaining designs will be presented to members of the   review team for approval . The team would include the CTO , heads of sales & marketing , engineering ,   production , validation and customer support etc . This meeting would surface a lot of the issues which   went unnoticed by the engineers , it would prove to be a learning platform for the team to modify and   enhance the designs . The outcome of this meeting would be to improve current designs according to   feedback received from various stakeholders , eliminate non - feasible design options , or pick the most   appropriate design which meets the overall goals for further development . 

 Insight & Approach 

 This activity was done to evaluate design outcomes of all CFTs , and it was helpful in eventual selection of   the best designs which move forward to production . The activity also helped in aligning the thought   process of all individuals , making everyone understand different viewpoints , challenges and limitations .   Thus , by the end of the exercise everyone would agree on the chosen design due to its overall merit and   ability in solving a complex engineering problem spanning multiple disciplines . The side - effect of this   approach was also improved motivation among my team members , getting an insight into ideologies of   other CFTs was an eye opener for many , it was an opportunity for growth . 

 The CFT approach for product development was adopted throughout the organization following the   successful execution of an entirely new product platform . With lesser time , better product quality , better   reliability , and improved production / serviceability compared to previous approach of working in silos and   not encouraging a wide debate in the decision - making process ( relying purely on engineering excellence ) .   It was a lesson in entrepreneurship and team building for all members involved and showed the   importance of adopting different methodologies of work depending on the situation . The actual   implementation was a bit more challenging to finalize and execute but I have summarized the gist of the   approach . 

 Personally , this approach was truly educational for a left - brain thinker like me . Sometimes the best   engineering solutions are not the best for solving the problem . Objective metrics such as cost/ product   performance/ quality/ reliability are not the only metrics driving product decisions , it is a mixture of   several elements with the right amount of compromise which builds a good product like ours . Group   thinking and learning through experimentation really helped in proving this point . 


EMAIL: 
ID_NUM: 
NAME_STUDENT: 
PHONE_NUM: 
STREET_ADDRESS: 
URL_PERSONAL: 
USERNAME: 

### Task: You are a PII (Personal Identity Information) Detection. Given a essays written by students, you have to identify ONLY the following:
NAME_STUDENT - The full or partial name of a student that is not necessarily the author of the essay. This excludes instructors, authors, and other person names.
EMAIL - A student’s email address.
USERNAME - A student's username on any platform.
ID_NUM - A number or sequence of characters that could be used to identify a student, such as a student ID or a social security number.
PHONE_NUM - A phone number associated with a student.
URL_PERSONAL - A URL that might be used to identify a student.
STREET_ADDRESS - A full or partial street address that is associated with the student, such as their home address.
### Input: Reflection – Learning Launch 

 Challenge & Selection 

 I am a lead Design Engineer in a startup which focusses on automating mundane processes of item   storage , retrieval , and dispatch , in large warehouses . Since we provide automation solutions to   businesses , there is a lack of direct interaction of engineers with the eventual end customers . The   company started off with a small team who built a compelling solution for businesses , the adoption was   rapid and sales were good . Later , it became apparent that the designs had several hidden limitations   which the team did not anticipate early on , such as , scalability of production , reliability , maintenance ,   assembly , cost etc . While initiating the development of a new product platform , we wanted to avoid a   repeat of the mistakes made earlier . Learning launch tool was the perfect tool to get things started and   to refine our product development process . Using learning launch meant that we could iterate/ refine   various steps of our product development process quickly . As a pilot , we tested a new approach in one of   the product teams . We started by identifying our key stakeholders who could present clearer   understanding of internal and external customer demands , identify problems , eliminate decision   blindness , encourage different lines of thought and shorten development times by designing and   validating quick prototypes . 

 Application 

 We started out by scoping the review team . This team would be responsible for final approval of design   decisions and would comprise of heads from all the major departments in the organization , thus ensuring   that every viewpoint gets taken care of . Insights from the marketing and sales team were hugely beneficial   in understanding the pain points and expectations of the customers , this information was passed on to   the technical teams . We then formed cross - functional engineering teams ( CFTs ) within the organization   to work on specific modules of the product , modularizing the design was a key decision taken early on to   eliminate a cascading effect of failures identified later in the product ’s life cycle . Thus , ensuring that   correct engineering decisions get made at the individual team levels as well . 

 At the beginning of the product development , the CFTs would start by ideating on multiple design   concepts which solve the problem . The teams would then shortlist 3 - 5 designs based on evaluation by the   engineering and production teams . The engineers will then start developing mature versions of the design   and prototype them ( POCs - Proof of Concepts ) . The POCs would then be tested for technical conformity ,   in some cases scaled prototypes would also be built to reduce cost and time . After eliminating the   concepts which had fundamental drawbacks , the remaining designs will be presented to members of the   review team for approval . The team would include the CTO , heads of sales & marketing , engineering ,   production , validation and customer support etc . This meeting would surface a lot of the issues which   went unnoticed by the engineers , it would prove to be a learning platform for the team to modify and   enhance the designs . The outcome of this meeting would be to improve current designs according to   feedback received from various stakeholders , eliminate non - feasible design options , or pick the most   appropriate design which meets the overall goals for further development . 

 Insight & Approach 

 This activity was done to evaluate design outcomes of all CFTs , and it was helpful in eventual selection of   the best designs which move forward to production . The activity also helped in aligning the thought   process of all individuals , making everyone understand different viewpoints , challenges and limitations .   Thus , by the end of the exercise everyone would agree on the chosen design due to its overall merit and   ability in solving a complex engineering problem spanning multiple disciplines . The side - effect of this   approach was also improved motivation among my team members , getting an insight into ideologies of   other CFTs was an eye opener for many , it was an opportunity for growth . 

 The CFT approach for product development was adopted throughout the organization following the   successful execution of an entirely new product platform . With lesser time , better product quality , better   reliability , and improved production / serviceability compared to previous approach of working in silos and   not encouraging a wide debate in the decision - making process ( relying purely on engineering excellence ) .   It was a lesson in entrepreneurship and team building for all members involved and showed the   importance of adopting different methodologies of work depending on the situation . The actual   implementation was a bit more challenging to finalize and execute but I have summarized the gist of the   approach . 

 Personally , this approach was truly educational for a left - brain thinker like me . Sometimes the best   engineering solutions are not the best for solving the problem . Objective metrics such as cost/ product   performance/ quality/ reliability are not the only metrics driving product decisions , it is a mixture of   several elements with the right amount of compromise which builds a good product like ours . Group   thinking and learning through experimentation really helped in proving this point .
### Output: 