Pdca cycle
The PDCA Cycle - Plan, Do, Check, Act - is an iterative four-step management method for continuous improvement. Originally developed by Walter Shewhart and later popularized by W. Edwards Deming, the cycle provides a systematic approach to testing changes before full implementation. Each iteration builds on the last, creating a spiral of learning that gradually improves processes, products, and outcomes.
Why it matters
Organizations often implement changes without rigorously testing them first, then struggle to understand why results don't match expectations. The PDCA cycle imposes discipline: plan what you'll change, test it on a small scale, measure the results, and only then decide whether to adopt, adapt, or abandon the change.
This structured approach reduces the risk of large-scale failures, builds organizational learning, and creates a culture where improvement is continuous rather than episodic. In product development, PDCA thinking underlies practices from A/B testing to sprint retrospectives.
The four steps
Plan
Planning establishes what you're trying to improve and how you'll measure success. This phase involves:
Good planning requires resisting the urge to jump to solutions. Understanding why current performance is what it is - through data analysis, observation, and inquiry - leads to better hypotheses about what will actually help.
Do
The Do phase implements the plan on a small scale. This isn't full rollout; it's a controlled test designed to generate learning. Key activities include:
The limited scope is intentional. Small tests are cheaper, faster, and less risky than organization-wide changes. They also generate clearer learning because there are fewer confounding variables.
Check
Check analyzes the results to determine whether the change worked. This phase compares actual outcomes to expected outcomes:
Honest assessment is critical. Confirmation bias makes it tempting to declare success prematurely or explain away negative results. The Check phase requires objectivity and willingness to accept that the hypothesis might be wrong.
Act
Act decides what to do based on what was learned:
Act also prepares for the next cycle. Successful changes often reveal new opportunities for improvement. Failed experiments generate learning that informs better hypotheses. The cycle continues.
Pdca in product development
The PDCA cycle maps naturally to product development practices.
Feature development uses PDCA thinking when teams hypothesize that a feature will improve a metric (Plan), build and ship a minimal version (Do), measure impact through analytics (Check), and decide whether to expand, iterate, or kill the feature (Act).
Sprint retrospectives follow PDCA logic: the team plans improvements for the next sprint, implements them, observes results, and decides what to continue or change.
A/B testing is essentially compressed PDCA: hypothesize which variant will perform better, run the test, analyze results, and decide which to ship.
Pdca vs. agile
PDCA and Agile share philosophical roots - both emphasize iteration, learning, and continuous improvement. The differences are in scope and context.
PDCA is a general problem-solving framework applicable to any process improvement. It originated in manufacturing and has been applied everywhere from healthcare to education.
Agile is specifically a software development methodology with detailed practices, roles, and ceremonies. Agile incorporates PDCA thinking but adds structure specific to building software products.
Teams using Agile methods are implicitly using PDCA. The sprint cycle is a PDCA cycle applied to product development.
Common mistakes
Skipping the Plan phase leads to unfocused activity. Without clear hypotheses and measurement plans, teams can't distinguish between changes that worked and changes that happened to coincide with improvement.
Going too big in Do undermines learning. Large-scale changes have many variables; when results come in, it's hard to know what caused what. Small tests generate clearer signals.
Superficial Check wastes the investment in planning and doing. Cursory review - "looks good, let's move on" - misses the learning that makes PDCA valuable. Rigorous analysis of what happened and why is essential.
Skipping Act means learning doesn't translate to action. Some teams cycle through PDCA without ever standardizing successes or abandoning failures. The cycle only improves outcomes if Act actually changes how work is done.
Running one cycle and stopping treats PDCA as a one-time tool rather than a continuous practice. The power comes from repeated iteration, with each cycle building on previous learning.
Building a pdca culture
Organizations that use PDCA effectively make it part of how work happens, not a special exercise.
Small, frequent cycles normalize improvement as part of regular work rather than separate initiatives. Many small experiments beat occasional large ones.
Visible tracking helps teams see cycles in progress and learn from each other. Shared boards or documents showing active experiments, their hypotheses, and their results spread learning across the organization.
Celebrating learning equally with success reinforces that failed experiments that generate insight are valuable. If only successes are recognized, people stop taking risks.
Product feedback tools like Klero support PDCA thinking by providing the data needed to Check effectively - understanding whether changes actually improved customer experience, not just internal metrics.
