My company provides school scheduling software for middle and high schools who use the web  based program to schedule students into courses with teachers for each school year. This re- quires taking thousands of individual course requests for students, setting the parameters of the  school day (such as rooms, teachers, sections) and so forth and attempting to ﬁt each individual  course request so that each student has a complete schedule. It is one of the most essential  processes for schools that often has bunches of complicating factors. It can be long and tedious  despite the best scheduling software based upon the variable factors of the user. Our cus- tomers, the school administrators,  trust us to provide a program without glitches  as that can  cause severe issue like holding up the start of their school year , students missing graduation  requirements, teacher union issues and more.

Past feedback from current customers had identiﬁed a feature that we needed to add that would  allow a regular education teacher to share students with a special education teacher and com- bine the number of students to ﬁt what would normally be one section/class size. We had been  aware during the building of the original BETA program (and during the initial user trials) that this  feature would be needed. We had hoped our coding and development would be further along  before we had to add the feature though. With complicated software coding, adding a feature  without proper planning and testing can upset the apple cart and cause unwanted errors across  other essential program functions. An additional challenge was that there was not consensus  across the internal team (customer support, development, user experience and the CEO) on  how, when, and with what initial customer to implement this feature, yet the demand was con- tinuing to pressure us.

We needed to act quickly, but with an implementation plan that would not cause errors in the  program and risk losing customer trust. Since we were beyond incubation of an idea to solve  this issue and felt that one of the previously identiﬁed solutions was likely to be successful, we  felt that Learning Launch would be our best tool. After much internal collaboration and discus- sion , we felt we had strong intuition into the solution, but were missing the most important part.  We needed customer use and feedback on success or failure. One of the most important take  aways from this course for he has been when implementing a new idea to “fail fast and cheap”.  In this instance that meant applying minimal resources to the coding of the new feature, getting  out quickly in a Learning Launch setting, while having protocols for immediate testing and feed- back all without disrupting the customers work ﬂow and our daily business operations. Previous- ly, we had always called these types on implementations a “pilot”. After taking this course, I en- couraged our team to transition our thinking to that of a Learning Launch. The greatest shift in  this change came in our realization that in implementing this feature, our goal was to be speciﬁc  about what we wanted to learn and what we wanted the client to learn. This helped us formulate  speciﬁc, measurable goals for our Learning Launch. The goals were, the length and extent of  client training required for the new feature, the ease of use within the workﬂow or the program,  the extent of accuracy or error in the desired result, eliminating bugs to other program functions,  and customer needs and satisfaction with the end result.

In order to implement our Learning Launch it made the most sense to choose a small to medium  size customer who had the speciﬁc need of combining regular and special education teachers in  one course section. The New York City High Schools had an abundance of this issue so we  chose one of our longest running customers with which we had a great relationship and history.  In order to succeed (or fail) quickly we needed to implement the new feature in a safe environ- ment for the client, meaning to begin the Learn Launch at a non-essential season when any is- sues would not delay their start of school. In order to do this, we created a “sand-box” replica of

the schools real data to mimic the scenario as it would have occurred in the previous scheduling  cycle.  In the fall, the customer success department trained the school administrators on the  new features, then set them free to use it for the intended task with their “practice” data.

The result was a much improved learning process for us and the customer, but not without  glitches. Despite the development and customer success teams best efforts to “predict” the  needs of the customer, there were items not covered in the training and documents support we  provided. So, they had to reach out to the customer success team by phone for direction, which  we hoped would not happen. Shortly after the customer completed their task with the customer,  a survey was sent out to gather details on the items we had hoped to measure at the onset of  the launch. Without going into too much detail on each item, we learned that overall the comple- tion of the task was satisfactory, but the usability and work ﬂow for the customer wasn’t as  seamless as we had hoped. Along with that, the questions we asked in the follow-up survey  weren’t on target with the customers most valuable feedback. Which was that the new functions  we implemented would operate much better in a different part of the programs workﬂow. That  was super valuable, but “an additional item” they added on the survey themselves. We eventu- ally implemented to new program features, but the Learning Launch was a huge advancement  forward for us as to how we would approach future feature additions.

There was a larger lesson for our group to be learned that is much in line with the course. At the  onset, e focused too much on our “predicted” thoughts on the customers needs instead of  spending more time before the Learning Launch on watching, observing the customers daily life  and approach the task in a way that was most valuable to them. This provided us insight that  there are probably many more places within the use of our program where we need to study  more in depth their workﬂow and whats most important to them. We vowed to do this in the fu- ture before any new feature launches. Subsequently, the customer support team began to  spend more time on site with the customer on a regular basis for the purpose of gathering data  and information through observation and conversations on their largest needs they foresaw in  the future.Previously we had done this with on-line, impersonal surveys.

In the future we decided that the idea of the Learning Launch to test the new feature was a  great one and provided much value for us. But, we needed to ﬁrst view the behavior and the  workﬂow of the customer, get their feedback and build the feature with that information in mind  ﬁrst, instead of “predicting” what they would need and the best way to measure the success.  This lesson is in line with much of what is taught in this course around being customer centric  and understanding whats most important to them as a company.


My company provides school scheduling software for middle and high schools who use the web based program to schedule students into courses with teachers for each school year . This re- quires taking thousands of individual course requests for students , setting the parameters of the school day ( such as rooms , teachers , sections ) and so forth and attempting to ﬁt each individual course request so that each student has a complete schedule . It is one of the most essential processes for schools that often has bunches of complicating factors . It can be long and tedious despite the best scheduling software based upon the variable factors of the user . Our cus- tomers , the school administrators , trust us to provide a program without glitches as that can cause severe issue like holding up the start of their school year , students missing graduation requirements , teacher union issues and more . Past feedback from current customers had identiﬁed a feature that we needed to add that would allow a regular education teacher to share students with a special education teacher and com- bine the number of students to ﬁt what would normally be one section / class size . We had been aware during the building of the original BETA program ( and during the initial user trials ) that this feature would be needed . We had hoped our coding and development would be further along before we had to add the feature though . With complicated software coding , adding a feature without proper planning and testing can upset the apple cart and cause unwanted errors across other essential program functions . An additional challenge was that there was not consensus across the internal team ( customer support , development , user experience and the CEO ) on how , when , and with what initial customer to implement this feature , yet the demand was con- tinuing to pressure us . We needed to act quickly , but with an implementation plan that would not cause errors in the program and risk losing customer trust . Since we were beyond incubation of an idea to solve this issue and felt that one of the previously identiﬁed solutions was likely to be successful , we felt that Learning Launch would be our best tool . After much internal collaboration and discus- sion , we felt we had strong intuition into the solution , but were missing the most important part . We needed customer use and feedback on success or failure . One of the most important take aways from this course for he has been when implementing a new idea to “ fail fast and cheap ” . In this instance that meant applying minimal resources to the coding of the new feature , getting out quickly in a Learning Launch setting , while having protocols for immediate testing and feed- back all without disrupting the customers work ﬂow and our daily business operations . Previous- ly , we had always called these types on implementations a “ pilot ” . After taking this course , I en- couraged our team to transition our thinking to that of a Learning Launch . The greatest shift in this change came in our realization that in implementing this feature , our goal was to be speciﬁc about what we wanted to learn and what we wanted the client to learn . This helped us formulate speciﬁc , measurable goals for our Learning Launch . The goals were , the length and extent of client training required for the new feature , the ease of use within the workﬂow or the program , the extent of accuracy or error in the desired result , eliminating bugs to other program functions , and customer needs and satisfaction with the end result . In order to implement our Learning Launch it made the most sense to choose a small to medium size customer who had the speciﬁc need of combining regular and special education teachers in one course section . The New York City High Schools had an abundance of this issue so we chose one of our longest running customers with which we had a great relationship and history . In order to succeed ( or fail ) quickly we needed to implement the new feature in a safe environ- ment for the client , meaning to begin the Learn Launch at a non - essential season when any is- sues would not delay their start of school . In order to do this , we created a “ sand - box ” replica of the schools real data to mimic the scenario as it would have occurred in the previous scheduling cycle . In the fall , the customer success department trained the school administrators on the new features , then set them free to use it for the intended task with their “ practice ” data . The result was a much improved learning process for us and the customer , but not without glitches . Despite the development and customer success teams best efforts to “ predict ” the needs of the customer , there were items not covered in the training and documents support we provided . So , they had to reach out to the customer success team by phone for direction , which we hoped would not happen . Shortly after the customer completed their task with the customer , a survey was sent out to gather details on the items we had hoped to measure at the onset of the launch . Without going into too much detail on each item , we learned that overall the comple- tion of the task was satisfactory , but the usability and work ﬂow for the customer was n’t as seamless as we had hoped . Along with that , the questions we asked in the follow - up survey were n’t on target with the customers most valuable feedback . Which was that the new functions we implemented would operate much better in a different part of the programs workﬂow . That was super valuable , but “ an additional item ” they added on the survey themselves . We eventu- ally implemented to new program features , but the Learning Launch was a huge advancement forward for us as to how we would approach future feature additions . There was a larger lesson for our group to be learned that is much in line with the course . At the onset , e focused too much on our “ predicted ” thoughts on the customers needs instead of spending more time before the Learning Launch on watching , observing the customers daily life and approach the task in a way that was most valuable to them . This provided us insight that there are probably many more places within the use of our program where we need to study more in depth their workﬂow and what s most important to them . We vowed to do this in the fu- ture before any new feature launches . Subsequently , the customer support team began to spend more time on site with the customer on a regular basis for the purpose of gathering data and information through observation and conversations on their largest needs they foresaw in the future . Previously we had done this with on - line , impersonal surveys . In the future we decided that the idea of the Learning Launch to test the new feature was a great one and provided much value for us . But , we needed to ﬁrst view the behavior and the workﬂow of the customer , get their feedback and build the feature with that information in mind ﬁrst , instead of “ predicting ” what they would need and the best way to measure the success . This lesson is in line with much of what is taught in this course around being customer centric and understanding what s most important to them as a company .