Plan Do ~~Check~~Study Act

We make plans for every work task. We try to build things according to those plans, and when things deviate from the plan, we usually try to fix them.

However, we do not always evaluate whether our hard-fought efforts are actually beneficial, nor do we record them. When measurement and evaluation are weak, we end up continuing to use things that provide no value. When we try to make improvements, without external feedback, we tend to just make changes based on our own assumptions.

The point here is that initially building something based on your own ideas is not a problem. Time is only wasted when you fail to correct what isn't working.

To understand why we fall into this trap and how to fix it, we have to look at a famous framework PDCA - Plan-Do-Check-Act.

The Origins of PDCA (Plan-Do-Check-Act)

The Japanese use a framework known as the Plan-Do-Check-Act Cycle. Where did PDCA come from? It originated from Dr. Deming's seminars held in Japan in 1950. In those seminars, Dr. Deming explained how to manufacture high-quality products. He presented the "Deming Wheel," which was an improved version based on Shewhart’s Cycle.

Shewhart and Deming wheel Japanese executives took the Deming Wheel and distributed it across their companies and organizations as the "PDCA Cycle," which is how the term became established. PDCA teaches us how to produce quality products. In practice, it is widely accepted not just in Myanmar, but globally, that Japanese products are of excellent quality and highly durable.

However, Dr. Deming warned the Japanese that PDCA was misguided. Primarily, the word "Check" in English carries the connotation of "holding back" or hindering. Later on, when PDCA became ubiquitous, Dr. Deming felt this was unacceptable and personally introduced PDSA (Plan-Do-Study-Act) to replace it.

When people talk about "Check" in PDCA, they often describe it as "looking to see if what we planned matches reality." But Dr. Deming didn't just want people to "check." He intended for us to analyze why things went wrong when real-world results deviate from our assumptions, and to use that knowledge to revise our initial theories.

Let me explain with a simple example:

PLAN We assume our application is boring because it lacks dynamic movement compared to regular apps. Therefore, we decide to add a greeting AI animation on the Home Screen as soon as users open the app. We predict that this will excite users and increase app open rates by at least 15%.

DO We implement the AI animation. However, instead of releasing it to everyone, we test it by enabling the animation for only 50% of our user base.

Using the "Check" System

Measurement: According to the metrics, the app open rate only increased by 4% in reality.
Conclusion: The AI animation did not hit our 15% prediction. Therefore, we declare that it didn't work.
Next Step (ACT): We decide we need to brainstorm a completely new idea, or we just settle for the 4% increase.

Using the "Study" System

Measurement: According to the metrics, the app open rate only increased by 4% in reality.
Finding the Cause: When we thoroughly investigate why there was only a 4% increase, we discover that Desktop users actually opened the app 20% more (exceeding our expectations). On the flip side, Mobile users opened the app 10% less than before. We find out that the animation we added was causing mobile phones to lag.
Conclusion: Based on our findings, we learn that adding the animation does make users happy. However, we also learn that if we add one, it must be lightweight enough for mobile phones to handle.
Next Step (ACT): We modify and optimize the existing animation until it runs smoothly on mobile devices.