Reflection - Learning Launch 

 Challenge   I work in a large global industrial organisation , as part of a product management team developing 

 software for our internal use . Our role is to develop innovative solutions to core business problems 

 that directly improve our bottom line performance . As these problems have not been addressed by 

 existing software vendors , what we do is truly an experiment - testing whether our proposed 

 solution is technically feasible and that it provides a financial benefit to the organisation . Our 

 challenge is undertaking this testing as quick and as cheap as possible . Testing in a live production 

 environment is not feasible as it would impact our manufacturing line and there are also other 

 impacts to performance that makes it difficult to isolate the benefits of our software .     Selection   Based on the challenge outlined above , the tool we have selected is the “ Learning Launch ” tool . This 

 is appropriate as my team and I have already completed the “ What is ” , “ What if ” and “ What wows ” 

 stages of the design thinking process . Additionally , the constraints around testing as described 

 necessitate the use of such a tool .     Application   We applied the “ Learning Launch ” tool to our proposed dynamic product optimisation software 

 whereby we are looking to optimise the value of different manufacturing products produced on an 

 assembly line based on feedback of real time information from our customers and suppliers . In 

 applying the tool , there were four main hypotheses we were looking to test . Firstly , can we 

 technically develop an algorithm to solve the problem that runs in an defined timeframe . Secondly , 

 can we access and ingest the required information from the production line required by the 

 algorithm . Thirdly , can we make a higher value decision that what are employees are currently 

 making . Lastly , how can we implement the new ways of working in a way that improves the 

 engagement level of our employees so that they want to use the new solution .     These hypotheses were prioritised logically according to a sequence - show we can technically do it 

 ( prototype ) , show it improves the result , then show we can get the end users to adopt it ( part of 

 which depends on showing value )     In designing the tests , we simulated the real operating environment - we obtained historical 

 operational data and animated the operation of our assembly line in our test environment according 

 to time stamped events and conditions . These were linked to cost and revenue drivers so we could 

 measure the impact of new decisions . We also brought in multiple assembly line operators to run 

 the software and obtain their feedback .     Setting up the learning launch took a colleague and myself 10 days - 2 days to document the 

 hypotheses , assumptions and tests ( as per the lecture note guidance ) and 8 days to collect and 

 transform the data for the experiment . In parallel , a mathematician and developer were developing 

 the initial algorithm and prototype application ( we have already got a sandbox environment and 

 platform set up for these types of activities ) .   The tests took an additional 3 days after this .     The outcome of the tests confirmed our hypotheses and the decision was made to continue to the 

 development phase . This decision was made however after an additional round of tests were 

 completed ( another 3 days ) as the algorithm result proved inconclusive initially and we had to pivot 

 in the approach taken . 

 Insights 

 ● Prioritisation of assumptions and tests was critical - focussing on the key problems that if 

 you ca n’t solve means that there is no product . If you start on the easy assumptions first 

 and left the hardest ones to last , and they could n’t be solved , then you would have wasted a 

 lot of time and effort . 

 ● It is important to be very definitive on what success looks like for each test . Individuals can 

 be very attached to their solutions . Clear success criteria for each test removes this bias . 

 We had to do some work with our team to get them to be passionate about the problem , 

 not fixated on their solution . 

 ● Culture is hard to change . During our pivot , it was hard to get the individual who had to 

 make adjustments not to feel bad , to see it as a learning experience rather than a failure . In 

 previous roles , his learning has not been valued , only the end result . This stifles 

 experimentation and results in only incremental improvements and less breakthrough 

 innovation .   Cultural development of your innovation team is therefore crucial . 

 ● Customer engagement throughout the process is critical . We bought the customer in part 

 way through the Learning Launch process . To get them on board with what we were doing , 

 we then had to spend a lot more time than we would have had to if they were involved from 

 the start . 

 Approach   The Learning launch tool was used in the right context and will become part of our teams standard 

 process . There are however improvements that we will make in how it is applied . Firstly , we will 

 involve our customers from the beginning to get their full buy - in . Additionally , we will provide more 

 coaching to the team upfront around the behaviours we are trying to encourage in using such a tool . 

 Lastly , we will allow more time for pivots - assuming success when there are downstream teams 

 depending on your outcome leaves little time for multiple pivots that will definitely occur . 


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   I work in a large global industrial organisation , as part of a product management team developing 

 software for our internal use . Our role is to develop innovative solutions to core business problems 

 that directly improve our bottom line performance . As these problems have not been addressed by 

 existing software vendors , what we do is truly an experiment - testing whether our proposed 

 solution is technically feasible and that it provides a financial benefit to the organisation . Our 

 challenge is undertaking this testing as quick and as cheap as possible . Testing in a live production 

 environment is not feasible as it would impact our manufacturing line and there are also other 

 impacts to performance that makes it difficult to isolate the benefits of our software .     Selection   Based on the challenge outlined above , the tool we have selected is the “ Learning Launch ” tool . This 

 is appropriate as my team and I have already completed the “ What is ” , “ What if ” and “ What wows ” 

 stages of the design thinking process . Additionally , the constraints around testing as described 

 necessitate the use of such a tool .     Application   We applied the “ Learning Launch ” tool to our proposed dynamic product optimisation software 

 whereby we are looking to optimise the value of different manufacturing products produced on an 

 assembly line based on feedback of real time information from our customers and suppliers . In 

 applying the tool , there were four main hypotheses we were looking to test . Firstly , can we 

 technically develop an algorithm to solve the problem that runs in an defined timeframe . Secondly , 

 can we access and ingest the required information from the production line required by the 

 algorithm . Thirdly , can we make a higher value decision that what are employees are currently 

 making . Lastly , how can we implement the new ways of working in a way that improves the 

 engagement level of our employees so that they want to use the new solution .     These hypotheses were prioritised logically according to a sequence - show we can technically do it 

 ( prototype ) , show it improves the result , then show we can get the end users to adopt it ( part of 

 which depends on showing value )     In designing the tests , we simulated the real operating environment - we obtained historical 

 operational data and animated the operation of our assembly line in our test environment according 

 to time stamped events and conditions . These were linked to cost and revenue drivers so we could 

 measure the impact of new decisions . We also brought in multiple assembly line operators to run 

 the software and obtain their feedback .     Setting up the learning launch took a colleague and myself 10 days - 2 days to document the 

 hypotheses , assumptions and tests ( as per the lecture note guidance ) and 8 days to collect and 

 transform the data for the experiment . In parallel , a mathematician and developer were developing 

 the initial algorithm and prototype application ( we have already got a sandbox environment and 

 platform set up for these types of activities ) .   The tests took an additional 3 days after this .     The outcome of the tests confirmed our hypotheses and the decision was made to continue to the 

 development phase . This decision was made however after an additional round of tests were 

 completed ( another 3 days ) as the algorithm result proved inconclusive initially and we had to pivot 

 in the approach taken . 

 Insights 

 ● Prioritisation of assumptions and tests was critical - focussing on the key problems that if 

 you ca n’t solve means that there is no product . If you start on the easy assumptions first 

 and left the hardest ones to last , and they could n’t be solved , then you would have wasted a 

 lot of time and effort . 

 ● It is important to be very definitive on what success looks like for each test . Individuals can 

 be very attached to their solutions . Clear success criteria for each test removes this bias . 

 We had to do some work with our team to get them to be passionate about the problem , 

 not fixated on their solution . 

 ● Culture is hard to change . During our pivot , it was hard to get the individual who had to 

 make adjustments not to feel bad , to see it as a learning experience rather than a failure . In 

 previous roles , his learning has not been valued , only the end result . This stifles 

 experimentation and results in only incremental improvements and less breakthrough 

 innovation .   Cultural development of your innovation team is therefore crucial . 

 ● Customer engagement throughout the process is critical . We bought the customer in part 

 way through the Learning Launch process . To get them on board with what we were doing , 

 we then had to spend a lot more time than we would have had to if they were involved from 

 the start . 

 Approach   The Learning launch tool was used in the right context and will become part of our teams standard 

 process . There are however improvements that we will make in how it is applied . Firstly , we will 

 involve our customers from the beginning to get their full buy - in . Additionally , we will provide more 

 coaching to the team upfront around the behaviours we are trying to encourage in using such a tool . 

 Lastly , we will allow more time for pivots - assuming success when there are downstream teams 

 depending on your outcome leaves little time for multiple pivots that will definitely occur .
### Output: 