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 . 


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 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 .
### Output: 