Example Reflection – Learning to Launch 

 Challenge : 

 The context for this problem is the product launch in my startup . We launched our first   product “ Enterprise Resource Planning ( ERP ) products for midscale real estate developers and the   product was an economical failure . Upon a thorough post - launch analysis of the product , it was   determined that the demands and pain points of the customers were not addressed completely by the   product . Determined to keep the company afloat me and my co - founder got back to the drawing board   and decided to launch the customer relationship management ( CRM ) product . This launch was very   crucial because we were very low on budget and the future of the startup depended on the success of   this product . 

 Selection : 

 The tool selected is learning launch tool . This was the tool selected because we have already   built the minimum viable product and wanted to improve the product further only based on the   feedback and the inputs from the customers . We wanted to perfect the “ What wows ” aspect of the   design thinking process as described in the lecture 2 . 

 Application : 

 The initial set of customers , who would use the minimum viable product , were identified   and were sent the product to do a trial run . The product only had the basic functionalities and nothing   better than the product they were currently using . However , after a week of them using the product we   conducted two in - depth interviews with 18 people using the product . The purpose of the interview was   just to find out what features they liked and what features they did not like . After completing the   interview of 18 of our customers , we went back to the drawing board and dropped all the features that   were voted down . To put things in perspective we had few features that worked and we were back in   the “ What if ” stage . We brainstormed a couple of ideas and mapped all the ideas that would enhance   the features that were voted up by the customers . The ideas finalized were developed and incorporated   into the product . 

 The product was sent again for trial and this time again we interviewed the people using the product   with the sole intention of finding which features eased their work and used more frequently than   others . Our product development cycle repeats , we were brainstorming ideas only on the features that   our customers loved and we were focused on making those features the best in the market . The other   features which were not liked by our customers , we completely stopped the development of those   features . 

 Third time is the charm , we enhanced the features a bit and sent them for a trial again and asked them   to use the product for 2 weeks . But this time , we interviewed the managers of the people using the   product to understand their perception on the productivity of their teams . The idea was to identify 

 which aspects of the product were driving the productivity and made an economic sense for the   decision makers . The aspects they highlighted were eye - openers because nearly 40 % of the features   appreciated by the daily users of the product had actually made no significant changes in the   productivity but the other 60 % of the features had increased the productivity of the teams by 25 % .   Incorporating the features suggested by the managers had made our product widely useful and our   sales increased just based on the word of mouth . 

 Insights : 

 If there is one take away from the complete process it would be to make your customers an   integral part of the product development . The insights from the customers and the managers were mind   numbing because we sketched 30 features and it turned out that only 8 of them were useful . As a   startup this information is very critical considering the resource and finance constraints . Eliminating the   features with least utility has freed up many of our resources to invest in the features that work . 

 Approach : 

 If I had to do the complete process once again , I would further categorize my customers into   segments and would try to come up with a categorization of a segment just as done by “ Daily   Challenge ” . I would go ahead and test the minimum viable product on the different segments and then   customize the product according to the segment . Doing this would make my product equally appealing   to all the customer and would lead to faster adaptability . 


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: Example Reflection – Learning to Launch 

 Challenge : 

 The context for this problem is the product launch in my startup . We launched our first   product “ Enterprise Resource Planning ( ERP ) products for midscale real estate developers and the   product was an economical failure . Upon a thorough post - launch analysis of the product , it was   determined that the demands and pain points of the customers were not addressed completely by the   product . Determined to keep the company afloat me and my co - founder got back to the drawing board   and decided to launch the customer relationship management ( CRM ) product . This launch was very   crucial because we were very low on budget and the future of the startup depended on the success of   this product . 

 Selection : 

 The tool selected is learning launch tool . This was the tool selected because we have already   built the minimum viable product and wanted to improve the product further only based on the   feedback and the inputs from the customers . We wanted to perfect the “ What wows ” aspect of the   design thinking process as described in the lecture 2 . 

 Application : 

 The initial set of customers , who would use the minimum viable product , were identified   and were sent the product to do a trial run . The product only had the basic functionalities and nothing   better than the product they were currently using . However , after a week of them using the product we   conducted two in - depth interviews with 18 people using the product . The purpose of the interview was   just to find out what features they liked and what features they did not like . After completing the   interview of 18 of our customers , we went back to the drawing board and dropped all the features that   were voted down . To put things in perspective we had few features that worked and we were back in   the “ What if ” stage . We brainstormed a couple of ideas and mapped all the ideas that would enhance   the features that were voted up by the customers . The ideas finalized were developed and incorporated   into the product . 

 The product was sent again for trial and this time again we interviewed the people using the product   with the sole intention of finding which features eased their work and used more frequently than   others . Our product development cycle repeats , we were brainstorming ideas only on the features that   our customers loved and we were focused on making those features the best in the market . The other   features which were not liked by our customers , we completely stopped the development of those   features . 

 Third time is the charm , we enhanced the features a bit and sent them for a trial again and asked them   to use the product for 2 weeks . But this time , we interviewed the managers of the people using the   product to understand their perception on the productivity of their teams . The idea was to identify 

 which aspects of the product were driving the productivity and made an economic sense for the   decision makers . The aspects they highlighted were eye - openers because nearly 40 % of the features   appreciated by the daily users of the product had actually made no significant changes in the   productivity but the other 60 % of the features had increased the productivity of the teams by 25 % .   Incorporating the features suggested by the managers had made our product widely useful and our   sales increased just based on the word of mouth . 

 Insights : 

 If there is one take away from the complete process it would be to make your customers an   integral part of the product development . The insights from the customers and the managers were mind   numbing because we sketched 30 features and it turned out that only 8 of them were useful . As a   startup this information is very critical considering the resource and finance constraints . Eliminating the   features with least utility has freed up many of our resources to invest in the features that work . 

 Approach : 

 If I had to do the complete process once again , I would further categorize my customers into   segments and would try to come up with a categorization of a segment just as done by “ Daily   Challenge ” . I would go ahead and test the minimum viable product on the different segments and then   customize the product according to the segment . Doing this would make my product equally appealing   to all the customer and would lead to faster adaptability .
### Output: 