I previously wrote the article below summarizing what we did during the self-restraint requests caused by COVID-19. This is a follow-up article. Rather than wanting to share information with someone, I left it as my own record.

Even after finishing it, I do not think there is any particular lesson summary. On the other hand, as a record of how a team functions, it seems to have value.

What we did to move lessons online _Under the situation above, many issues remained, but I wanted to share even a little knowledge while many school-related people were moving online._medium.com

In the previous article, because online support was urgent, I wrote about how to rotate the PDCA cycle quickly and the importance of continuing user research even in an emergency. This article is a continuation. The timeline overlaps a little, but it is about what happened later. The previous article covered roughly March to May 2020, and this one covers roughly April to June 2020.

In addition, the content of the previous article was something you could do even without an in-house development team. This time, the content is more about what could be done because there was an in-house development team.

Going back a little, in March 2020 information about COVID-19 spread, and considering the nature of the virus, I thought it was inevitable that the situation would become prolonged. On the other hand, a cram-school business model receives monthly fees, so school closures become a life-or-death issue. From the beginning, I thought we had to proceed in parallel with both emergency response and online transition based on the assumption that it would be prolonged.

Therefore, around March to April 2020, I wanted to make emergency response the first priority, and from April onward I wanted to work from a long-term perspective. We had calculated and understood the lesson capacity problem from the time the March measures began moving. Even so, as a life-or-death issue, and because it would be irrational to wait until we could provide it to everyone, we had to move forward even if only partially.

So I tried to view this emergency response as prototyping from a long-term perspective, and to accumulate knowledge in parallel. Specifically, we ran small A/B tests on lessons and collected NPS, investigating which kinds of lessons matched online and which did not. We moved these efforts forward with business-side members without involving the development team. It was a matter of right person, right place.

On the other hand, business-side members do not need to keep a strong awareness of long-term testing. Naturally, in an emergency, they should focus first on overcoming the immediate problems. The fact that we were able to get through online lesson support was largely due to the efforts of the business side.

During this period, while recognizing their contribution, I decided to think of the transition toward a long-term perspective, what you might call igniting the second engine, as one issue.

Additionally, this is partly my personal view, but I think there were members who believed COVID-19 could be completely contained through lockdowns, or that it would become something like influenza. Personally, I had, and still have, the stance that it would be prolonged. That is why I judged that igniting the second engine was necessary. However, there is still no final answer on this.

So what was the engineering team doing during this period? As a team, I told them to hold a long-term perspective. On that basis, the first work was creating scripts for system processing related to school closures. We knew that a large amount of operational cover would appear because of business flows different from normal operations.

It would have been possible to get through this manually, but as I wrote earlier, if we assume a prolonged situation, this is the kind of thing we want to automate. That said, we had no spare effort for full feature changes, and the business side was also at capacity, so there probably was not time for consensus building.

So, although these were scripts, we carried out the review process properly and created stable automated processing scripts.

This had a major effect as the situation changed from Tokyo’s self-restraint request, to self-restraint movements in the Fukuoka area, to the state of emergency declaration. That covers the movement up to around April 2020.

Once the automation scripts were complete, engineers had considerably more development capacity. The planned development roadmap had been completely stopped during school-closure response. At that point, we began in-house development of video call functionality for the online transition.

This period overlapped with the business side desperately rotating the PDCA cycle for online lessons using Google Meet. More precisely, after about two days of internal trial lessons using Google Meet and calculating lesson capacity, I personally judged that in-house development would be necessary.

From here I moved a bit like a CTO. First, I roughly researched SaaS APIs myself. The various articles I wrote about Twilio and similar topics were byproducts of that research.

In addition, over the weekend I built a simple prototype app using the Twilio API. The intention was to shortcut the technology-selection step. Normally, I probably would have asked team members to handle the investigation as well.

After summarizing this information, I told the development team members that a second engine would be needed, and that I wanted to somehow keep the development period to one month.

From here, another interesting part of our development team appeared: a discussion began about whether those requirements were really enough. As a result, although we initially planned to implement chat with SaaS too, we concluded that a separate feature implemented in-house with WebSocket, ActionCable, would be better, because chat could become an obstacle to user experience.

I think we were able to reach that conclusion because of a self-running team, the knowledge from PDCA cycles running in parallel, and our discussion culture.

As for the actual schedule, it took one month to reach the stage where the development team could review it, and then a little under one additional month for debugging and business-side review. In other words, we could not release it in one month. On the other hand, the business side understood this well, so both sides covered each other based on trust.

Through this process, just as online support had mostly reached the upper limit of lesson capacity, the new feature was completed. Seeing something working also taught us many things.

From the business side, we received a comment that the lesson capacity issue, which had been somewhere in the back of their minds, became a light of hope when this feature became visible.

Google Meet had done a great job, but after fulfilling its role, lessons were replaced by our internally developed video call system, and the lesson capacity problem was mostly resolved.

At present, we have moved even further forward, and I would like to say that all problems are solved, but when one issue is solved, another issue appears. The problems solved by the internally developed video call system are still only about 60 to 70 percent.

Another interesting point is that making a feature does not by itself solve a problem. After the feature arrives, it must be integrated back into business-side movement. I could not fully write about that part this time.

Also, until now the movement has basically been defensive, but I want to move toward offense as well. Once we think about offense, many new issues are piled up.

In other words, there are extra-large servings of issues, with unlimited refills, but solving issues is always the PM’s job. I intend to face these issues positively and enjoy working on them. In reality, the movement after March 2020 was difficult, but also fulfilling. I would like to summarize these movements again when there is an opportunity.