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 can’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 couldn’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.


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 .