Reflection:  Learning Launch Tool

Challenge  I am a product manager for a healthcare technology company, and I manage a service used by  health insurance companies to verify credentials of healthcare providers they contract with.  It  consists of back-office business process operations underpinned by a software application.  A  customer interested in purchasing our service wanted a significant amount of customization  before they would sign a contract, but we faced a twofold challenge:

1.  The customization they were asking for was complex, involved significant changes to

both the software as well as multiple back-office processes and there was a high risk that  we would spend a lot of money developing what they thought they needed, but that  even if we built exactly what they said, that it would not meet their needs.  After all, what  people say they want is often different from what they actually want.

2. Our business model made several assumptions about how efficiently our analysts would

be able to do the custom work they needed, and there was a risk that our pricing would  not cover our costs if those assumptions turned out to be incorrect.

Selection  The Learning Launch tool seemed like the perfect tool to address our challenge.  Because we  were doing exactly what Ed Hesse describes in the Learning Launch Tool video of week 4:  we  were creating our financial projections based on a number of assumptions, and we were also  assuming that the customer knew what they wanted and that we understood their description of  it.  Using the Learning Launch Tool, we could address the customer-need uncertainty as well as  mitigate some of the cost risk we were assuming, testing our assumptions of what the customer  wanted as well as our assumptions of how efficiently we could deliver this to them.    Application  We proposed to our customer that we would create a series of service concept prototypes that  we would ask them to interact with so they could experience how the service would work rather  than just hear or read our description of it - after explaining the rationale, they completely  bought into the idea!  Because the credentials verification process can take several days, our first experiment was an  accelerated simulation of the various touchpoints different users of the customer organization  would have with the service.  Rather than making all changes to our software (which would have  been expensive), we had a UX designer create just the front-end screens that users would  interact with.  Behind the scenes, we had people doing the various things that in real life the  software would eventually do - but in the short term it was a lot faster to get people to do it, and  far less expensive to make changes if we learned that it needed to look or behave differently  than we originally anticipated.  We had users place orders, view reports that would show them  the status of their orders, and finally delivered to them (manually generated) credentials files  and asked them to conduct a mock credentialing committee meeting using the files we'd  delivered to them.

Our second experiment was to validate many of our cost assumptions.  We randomly selected a  group of our analysts, trained them on the revised process and had them perform the  verification work on a number of "dummy" credentials files.  By timing them as they went  through the process, we were able to arm ourselves with real data that we could then feed into  our financial cost projections.    Insight  The simulation with the customer was hugely successful!  The experience of actually interacting  with the simulated service allowed them to make several suggestions for improvements to the  interface.  It also gave them a much higher level of confidence that we understood what they  needed.  Most importantly, it led to the discovery that one of the functions they had originally  wanted us to perform required data that was proprietary.  They made the decision at that early  stage to keep the function in-house, whereas it would have cost both parties considerably more  if we had that learning experience later in the process once we'd already started developing the  customization.  The second experiment did not unearth any such surprises.  It was nonetheless valuable,  because by validating our original assumptions it gave our senior leadership greater confidence  in our financial projections and lowered the risk on the project.    Approach  I found the Learning Launch tool to be an extremely effective way to de-risk the two problems of  customer needs uncertainty and operational execution uncertainty.  In future, I would deploy  the Learning Launch tool slightly differently – in hindsight, it felt like our experiments were  slightly large and we were attempting to validate multiple assumptions.  I would conduct smaller,  more focused experiments designed to validate a single assumption or fewer assumptions,  making the management of the experiments easier and gaining the option to pivot sooner if my  learning points me in a different direction than originally envisioned.

