Reflection on a learning launch

Challenge    I am head of software development and member of the product management team at a  small to medium sized business in Switzerland. The company sells standard software in a  specific niche of the financial industry. From time to time we have to implement new modules  for our software.  Our challenge is to improve the effectiveness of the software  enhancements we implemented. Why effectiveness ? Because in the past, it was considered  that as a standard software supplier we certainly know what customers needs & pains are.  We then implemented new modules or functions. While offering the newly realized modules,  we experienced regularly that it was nice that we have built something ­ it just was the wrong  thing. No effective solution, because it did not really fit to the customer's needs, so obviously  there was no satisfaction or wow effect at all.      Selection    I have selected the learning launch tool ­ why ? Simply because the learning launch tool  offers the idea/execution of testing a MVP under real market conditions, therefore following a  fail fast (...and with this probably a fail cheap(er)) process. Software development is an  insane expensive process ­ especially in the country I live in. Margins are generally  decreasing, competition is global: if someone has to expect a minimal chance for a fail with a  piece of software ­ then the earlier this happens, the better it is.    The video lesson from Professor Ed Hess in week 4 provided me an additional hint:  One could think to invite some sceptic customers too ­ if the hypothesis “survives” them ­ the  rest will be a piece of cake.     Application    We wanted to provide a new investment management module to our customers. Based on  the experiences in our company, we have taken some advices based on internal experience.  Additionally we did some research on competitors and the market of investment  management software solutions. But the most important part of the learning launch was:    ­ instead of writing a comprehensive specification of what we would like to do over months  ­ we implemented a fully clickable GUI prototype within two weeks ! So the software was  running, could be clicked by the customers, they experienced the workflows being designed  into the software, experienced the look & feel of the software. But of course the functionality  itself was not yet implemented at all ­ if someone pressed a button to calculate a complex  algorithm of something: the button was there, but nothing being executed while pressing the  button.      Insight

Customers were extremely surprised, hat there is a piece of clickable software after two  weeks. This was positive effect number one, because I think we have shown time to market  & responsiveness even if this was not really outstanding from our side, more market  standard in today's global software engineering capabilities. However, other insights were:    The story we have told with our software was good, but: on a certain (detail) level, most of  our guesses and hypotheses actually failed for daily practise. We did not care about things  we called ‘details’ and have learned that this detail would be a showstopper for a customer.  We applied a lot of experience from the past, but no practise from a daily global operational  investment manager.    Another insight especially important for us as a standard software supplier:   we did this learning launch with ​one​ specific customer. This obviously was wrong ­ we  should have had a sample of probably three to four customers from different countries. So  we did this later on as an extra round. The next time we certainly will increase importance of  an appropriate sample of customers to run our learning launch.      Approach    For us, this was a success ­ but as described in the insights, it is obvious that we need to  have an inspect & adapt cycle. We need to have a more representative sample of  customers. And I think if we would apply the earlier steps of the design thinking process,  then we would actually ​co create​ a hypothesis for a new software module with this group of  customer representatives. Then we even would have optimized the next learning launch  experience, because we do not need to implement a prototype for two weeks to experience  a partial fail ­ if we already have hardened the hypothesis before some software is written.    Generally I think this learning launch tool is very similar to the build ­ measure ­ learn cycle  being well known from the lean startup methodic (running lean book). Fail fast/early ,  continuously improve by inspect & adapt are things being pushed by the agile thinking.  It is pretty cool, that the lean agile process / culture gets some extra tools as the learned  ones in this course.

