When API designs are inconsistent and reviews take too long, changing the review process everywhere at once makes it hard to tell what helped. The plan-do-check-act (PDCA) cycle offers a smaller, repeatable approach: plan a change, try it, check whether it worked, and act on the result before beginning another iteration. section 2.12.1 section 2.2
Use each pass through the cycle to answer a practical question:
- Plan: Define the problem and desired outcome, gather evidence, identify a likely cause, and choose a corrective action to test. section 2.12.1 section 2.2
- Do: Carry out the proposed change on a small scale rather than assuming it will work across the organization. section 2.12.1
- Check: Compare what happened with the plan’s intended result. If implementation failed, determine what correction the plan needs. section 2.12.1
- Act: Decide what to keep, revise, or test next. For a successful improvement, plan how to standardize it and share what was learned. section 2.12.1 section 2.2
Shortening API design reviews
Suppose a team wants more consistent APIs and shorter design reviews. It can document current review times and recurring design issues, test a proposed countermeasure, then compare the results with its goal. If the change helps, the team can plan a wider rollout; if it does not, it can revise the plan. An A3 report provides places to record the problem, root-cause analysis, countermeasures, effect confirmation, and follow-up actions. The A3 approach is based on the closely related PDSA cycle, not specifically on PDCA. section 2.2 section 2.12.1
PDCA’s Check step is chiefly about whether the implementation of the plan succeeded and how to correct the plan if it did not. Do not treat it as identical to plan-do-study-act (PDSA): PDSA emphasizes predicting results, studying what occurred, and revising the theory of how the system works. For API product decisions driven by a hypothesis about customer behavior, that distinction matters. section 2.12.1 section 11.1.1
