Every product team runs experiments now, and most of them skip the stage that makes an experiment worth running: writing down, before the test, what result would count as success. PDCA is the 70-year-old loop that puts that stage first and refuses to let a cycle end without a decision about what to keep. The plan stage is a prediction, and a test without a prediction can only confirm whatever the team already wanted to believe, which is why the oldest improvement loop in industry still describes the best-run growth experiments better than most of the newer vocabulary does.
In this glossary topic:
What is the PDCA cycle?
The PDCA cycle (plan, do, check, act) is a four-stage loop for improving a process or a product: plan a change and predict its effect, do it on a small scale, check the result against the prediction, and act on what was learned by making the change standard or starting the loop again. It is the basic shape of continuous improvement, and it runs the same way whether the process is a factory line, a release pipeline, or a checkout flow.
The cycle is a loop rather than a list because the act stage feeds the next plan. A change that worked becomes the new standard and the baseline for the next cycle; a change that didn't becomes information that goes into the next plan. PDCA treats every change as an experiment with a prediction attached, which is what separates it from trying things and keeping the ones that seem to help.
What happens at each stage of PDCA?
- Plan: name the problem, describe the current state, state a hypothesis about its cause and the change that should fix it, and decide how the effect will be measured. The whole cycle depends on this prediction being specific enough to be wrong.
- Do: carry out the change, ideally in a limited setting such as one team, one segment, or one line, and record what happened, including anything unexpected.
- Check: compare the measured result with the prediction. Did the change produce the effect, by how much, and with what side effects?
- Act: if the change worked, make it the standard, update the procedure or the design, and spread it; if it didn't, drop or adjust it and start the next cycle with what was learned.
The check stage is where most cycles quietly fail, because a team that never wrote down a prediction has nothing to check against and will read any result as a success. The KPI a cycle will be judged on belongs in the plan, chosen before the do stage starts; the Defining Success Metrics lesson covers how to pick one that a check can actually move.
Where does the PDCA cycle come from?
Walter Shewhart, a statistician at Bell Labs, drew the first version. His 1939 book Statistical Method from the Viewpoint of Quality Control described specification, production, and inspection as a circle rather than a line, on the argument that each pass through production taught something the next specification should use. W. Edwards Deming, who had worked with Shewhart, took the idea to Japan in 1950 in lectures for engineers and executives, where it was known as the Deming wheel. Japanese practitioners reshaped it into plan, do, check, act, and it spread through manufacturing as the working engine of kaizen, improvement in small steps by the people doing the work. Toyota built it into its production system and its one-page A3 problem reports, and it later became the organizing structure of the ISO 9001 quality standard.
Deming himself never liked the word "check." In his later work he called the cycle PDSA, plan, do, study, act, arguing that "check" suggests inspection, holding something back to see whether it passes, while "study" is about learning from the result. The vocabulary has shifted, but the loop has kept its four stages for more than 70 years, and most teams today use PDCA and PDSA to mean the same thing.
How does PDCA differ from waterfall-style planning?
A waterfall plan runs once. Requirements, design, build, test, and release follow each other, each stage finished before the next begins, and the plan is judged by whether it was followed. PDCA runs repeatedly and is judged by what each pass taught. In a waterfall project a wrong assumption surfaces at the end and gets corrected in the next project; in PDCA it surfaces at the check stage of a short cycle and gets corrected in the next plan, weeks later rather than months.
The two also disagree about what a plan is for. A waterfall plan is a commitment to a scope and a date; a PDCA plan is a hypothesis and a measurement design, and it expects to be revised. A project plan is finished when the work is done; a PDCA cycle is finished when the next one starts. That is why PDCA sits comfortably inside agile methods: a retrospective is a PDCA cycle applied to the team's own process, and a sprint review is a check stage for the product.
How does PDCA map onto product experimentation?
Product experimentation is PDCA with newer vocabulary. Plan is the hypothesis, "if the signup form drops from seven fields to three, completion will rise," together with the metric and the audience. Do is the build and the exposure to a slice of users. Check is the analysis. Act is the rollout, the rollback, or the follow-up test. Eric Ries's build-measure-learn loop from The Lean Startup is a direct descendant, with the same three working stages and the same insistence that the learning, not the build, is the point.
An A/B test is not a PDCA cycle but the middle of one. It covers the do and the check: expose two variants, measure the difference. The plan before it, which decides what to test and what result would matter, and the act after it, which decides whether to ship, iterate, or stop, are where the thinking lives, and they are the stages a team skips when it runs tests to "see what happens." A test launched without a prediction has no check stage, because every outcome can be read as a win.
What does the PDCA cycle look like in practice?
PDCA is almost always drawn as a circle divided into four, with an arrow carrying the reader from act back to plan. The drawing is the method: the four quarters are equal in size because none of them can be skipped, and the arrow closing the loop is the difference between a cycle and a project. A team that cannot say which quarter it is currently in has stopped running PDCA, whatever its process document says.
The four stages as a closed loop around their purpose: plan predicts, do tests, check compares the result with the prediction, and act either standardizes the change or hands the next cycle its starting point. From the lesson Product Management Terms for Planning & Estimation.
Where does PDCA fit in design work?
Design already runs on the loop, usually without the name. A round of usability testing is a PDCA cycle when it is done well: the plan states which tasks should get easier and by how much, the sessions are the do, the analysis is the check, and the act is the revised design that goes into the next round. The rounds that disappoint are the ones with no plan stage, where five sessions are run to see what comes up and the findings are too diffuse to act on.
The same shape governs how a design system matures. A component change is proposed with a stated reason, released to a few product teams, checked against adoption and the defects it was meant to remove, and then either promoted to the library's standard or rolled back. The act stage is what turns a design decision into a standard rather than a preference, and a system without it accumulates variants instead of improvements.
The Testing and Iterations lesson walks through the test-and-revise rhythm the loop describes. For a design system, the equivalent record is the changelog, where each entry should read as the act stage of a cycle that had a plan.
