A3 problem solving is a structured way to investigate a problem, develop a response, and inspect the result while keeping the reasoning visible in a concise report. The report is a communication aid. Filling its boxes is not evidence that the problem has been understood or solved.
The Lean Enterprise Institute's A3 resource describes A3 as more than a document: it supports dialogue about a problem and the reasoning behind proposed countermeasures. The layout and working example below are practical suggestions, not a claim that every organization must use identical headings.
When is A3 a good fit?
Use A3 when a recurring gap deserves investigation and the people involved need a shared account of the reasoning. Examples include repeated review delays, a confusing operational handoff, or preventable rework that spans several steps.
A3 is less useful as a ceremonial wrapper around an obvious correction. If a broken link has a clear fix, fix and verify it. At the other extreme, a regulated incident or safety issue may require specialist methods and mandatory records. An A3 can summarize learning without replacing those obligations.
Choose an owner who can coordinate observation, discussion, and follow-up. That person need not have authority over every contributor. They do need access to the people doing the work and a clear route for decisions beyond their authority.
A practical A3 layout
| Part | Question to answer | Evidence to bring |
|---|---|---|
| Background | Why does this issue matter now? | Affected outcome and scope |
| Current condition | What happens today? | Direct observations and representative records |
| Target condition | What should be different? | A measurable or observable gap |
| Analysis | What could explain the gap? | Supported mechanisms and unresolved hypotheses |
| Countermeasures | What response addresses those conditions? | Options, tradeoffs, and prediction |
| Implementation | Who will try what, and when? | Ownership and dependencies |
| Follow-up | What happened, and what next? | Results, limitations, and next decision |
Keep the main report readable. Put detailed logs, interview notes, or sensitive records in the appropriate source system. Link to them with access controls rather than shrinking everything into unreadable text.
Observe before choosing the countermeasure
Begin with the actual work. Ask someone to walk through a recent example, including waiting, exceptions, and informal steps. Compare the stated process with what people did. A procedure document can describe an intention while missing the conditions that shape everyday decisions.
Separate observations from explanations. “Four changes waited for approval after implementation started” describes a pattern. “People are bad at planning” is an interpretation that does not identify a mechanism.
Then narrow the target. “Improve delivery” is too broad to inspect. “Request content approval before implementation begins on the next three eligible changes” provides an observable process target. Whether it also reduces rework remains a separate question to investigate.
Worked example: review work arrives too late
Hypothetical example: a software team notices that small interface changes often need another implementation pass after a content review. Its A3 owner examines six recent changes and observes two work items moving through the process.
The initial explanation is “reviewers respond too slowly.” The observations show a different possible condition: no one requests review until implementation is nearly finished. Reviewers also cannot tell which requests need a decision and which are informational.
The team considers three countermeasures: add an earlier review request, reserve a recurring review session, or create a clearer decision-ready checklist. It chooses a small trial combining an earlier request with two required fields: the decision needed and the latest useful response time.
The prediction is specific: on the next three eligible changes, the content decision will be available before implementation begins. The team also watches for a harmful side effect: starting work later while waiting for unnecessary approval.
At follow-up, it records what happened on each trial item. If one still started without a decision, the team investigates that exception. It does not average the result into a vague success story or claim a proven percentage improvement from three examples.
Review the reasoning with a colleague
A useful A3 review is a conversation, not a presentation defense. Ask the owner to explain where the evidence changed their mind. Then probe the weakest connection between the observed condition and the proposed response.
Questions that help include:
- Which observation makes this problem worth addressing?
- What alternative explanation did you consider?
- Which part of the analysis is still a hypothesis?
- How does the countermeasure change the suspected mechanism?
- What result would make you stop or revise the trial?
- Who experiences a cost if the trial works as designed?
The last question exposes local optimization. A team may reduce its own waiting by transferring uncertainty to another team. Include that team's perspective before calling the change an improvement.
Keep implementation and learning separate
A countermeasure has two kinds of completion. The change can be implemented, and the prediction can be inspected. Those dates may differ.
For example, adding a review field is an implementation task. Learning whether the field leads to timely decisions requires actual use. Record both in the plan. If the team closes the action when the field exists, the A3 becomes a delivery log instead of a problem-solving record.
Use the retrospective improvement guide to schedule the learning conversation. A routine agile retrospective can inspect the trial without turning every meeting into a full A3 review.
Common A3 mistakes
Starting with a preferred tool. “Install a new system” belongs among possible responses. It does not establish what gap the team needs to close.
Compressing away uncertainty. A concise report can still say “not yet known.” Removing that note makes the document look stronger while making the decision weaker.
Treating the target as a forecast. A desired outcome is not a promise that the proposed change will achieve it. Write the prediction and the evidence needed to judge it.
Making the owner the sole problem solver. The owner maintains a coherent investigation. People who experience the work must still contribute and challenge the account.
Closing after a good first result. A short trial may reveal feasibility without demonstrating sustained benefit. Agree on an appropriate later review when the risk or cost justifies it.
Choose a simple retrospective board for collecting observations. Keep the A3 as the connected reasoning record rather than forcing every brainstorming card onto the final page.
Frequently asked questions
Does an A3 have to fit on physical A3 paper?
The name comes from the paper size, but the practical goal is a concise, connected account of the thinking. A digital report can serve that purpose if it remains readable and supports discussion.
Is A3 the same as an action plan?
An action plan records implementation. An A3 also explains the problem, evidence, analysis, predicted effect, and result. Without those connections, the report cannot show why the action was chosen.
Can a retrospective produce an A3 topic?
Yes. A recurring issue identified in a retrospective can become the focus of a deeper investigation. Do not require a full A3 for every small improvement; match the effort to the uncertainty and consequence.