Skip to content

Build and Observe

What are we seeing while we do the work?

Series identity. Learn in cycles. Move in a line. The product keeps moving forward, while understanding improves through repeated PDSA learning loops.

Use this guide to: make delivery itself a source of disciplined observation.

PDSA emphasis: Do, with lightweight capture of what happens.

Purpose

Build and Observe treats implementation as contact with reality. The point is not to slow the team down with reporting. The point is to notice surprises, friction, variation, and new information while the work is still close enough to adapt.

When To Use It

  • During implementation of a thin slice, prototype, operational trial, or release.
  • When unexpected technical, user, or workflow details appear.
  • When the team needs to preserve observations for Study instead of relying on memory.

Core Questions

  • What are we seeing that we did not expect?
  • Where is the work harder, easier, or different than predicted?
  • What user or operator behavior is emerging?
  • What variation appears across cases?
  • What should be captured now for the Study step?

Facilitation Pattern

  1. Hold a short observation checkpoint during the build or test window.
  2. Ask for facts first, interpretations second.
  3. Capture surprises without deciding immediately what they mean.
  4. Tag observations against the original prediction when possible.
  5. Decide whether any observation requires immediate adaptation for safety or ethics.

Working Example

While building a claims intake slice, engineers discover that the submitted photos often lack timestamps. Support agents mention this is common in manual claims too. The observation is captured for Study rather than being patched quietly, because it may change the product's evidence model.

Common Traps

  • Only observing after launch.
  • Letting implementation discoveries disappear into chat threads.
  • Treating every surprise as a defect to fix immediately.
  • Ignoring operator workarounds because they are outside the application.

Outputs And Artifacts

  • Observation log.
  • Surprise list.
  • Evidence captured against the prediction.
  • Immediate safety or quality actions if needed.
  • Questions to carry into Study.

PDSA Linkage

Do is where the planned test meets the real system. In PDSA, Do is not merely execution; it is execution with disciplined attention to what the system reveals.

Working Worksheet

  • Keep the original prediction visible.
  • Capture observations as facts before interpretation.
  • Note variation across users, cases, or environments.
  • Preserve artifacts: screenshots, logs, quotes, examples, defects.
  • Flag urgent adaptations separately from Study questions.

Lineage Notes

Direct lineage: Walter Shewhart's statistical view of process learning influenced W. Edwards Deming, and Deming made PDSA a disciplined loop for prediction, action, study, and adjustment. Complementary quality thinkers - Juran, Ishikawa, Feigenbaum, and Taguchi - sharpen the product team's attention to fitness for use, causes, total systems, and variation. Ackoff, Drucker, Ries, and Blank are useful adjacent thinkers for systems, management, and product discovery, but they are not presented here as the historical source of PDSA.

References