A
This is Part 1 of a two-part series on A3 thinking. Watch Part 2: A Deep Dive into A3 Thinking →
Most A3 thinking webinars walk through a manufacturing example. A defect reduction project on a production line. A cycle time improvement in an assembly process. A quality issue traced back through five whys to a root cause that wouldn't have been obvious from the symptom level. The examples are useful because they're concrete, but they also reinforce a common misconception: that A3 thinking is a manufacturing methodology that has to be adapted carefully to be applied elsewhere.
Jess Orr's webinar takes the opposite approach. She walks through using A3 thinking on her own communication problem -- a problem severe enough that three people walked away from conversations with her thinking she was planning to leave her job, which she wasn't. The methodology is the same one she learned at Toyota and used to lead a 75%-plus reduction in chronic Camry defects. The problem is one most of us would recognize. The combination produces one of the most useful introductions to A3 thinking available in webinar form.
This is the first of two sessions Jess presented with KaiNexus. Part 1 establishes the methodology through the worked example. Part 2 goes deeper on the questions that arose -- when to use A3 versus other tools, how to engage teams, how to handle resistance, how to sustain gains. The two sessions work together, but Part 1 is the right place to start.
Jess Orr is founder of Yokoten Learning and at the time of this session was a continuous improvement practitioner at WestRock. She earned the Toyota Business Practices certification during her years at Toyota -- a certification process that required engineers to present completed A3s to a panel of managers and defend the thinking behind them. She holds two Six Sigma Black Belt certifications and a bachelor's degree in mechanical engineering from Virginia Tech. Yokoten is a Japanese term for the lateral spread of knowledge across an organization -- the practice of taking what was learned in one place and applying it elsewhere. The name fits what she does.
The session is hosted by Clint Corley, Enterprise Account Executive at KaiNexus.
The term A3 refers to the size of paper traditionally used to document the methodology -- an 11x17 sheet. That detail is the most commonly misunderstood part of A3 thinking, and Jess addresses it directly. The paper size doesn't matter. If your printer only handles 8.5x11, use that. What matters is following the process the paper is designed to hold.
The process originated at Toyota and is formally documented as Toyota Business Practices, or TBP. Jess learned it while working in quality engineering at Toyota, where all engineers in the department had to be certified on TBP. The certification process was rigorous. Engineers would present completed A3s to a panel of managers who would critique the thinking, send them back to work on specific sections, and require them to return for another panel review. The iterative discipline of that certification process is the discipline the methodology requires to actually work.
A3 thinking is structured problem-solving rooted in the scientific method. Form a hypothesis about what's causing a problem. Test the hypothesis through experimentation. Draw conclusions from the results. Adjust based on what you learned. The methodology is named for the paper it's documented on, but the paper is just the artifact. The real work is the disciplined thinking that the artifact captures.
Jess names several characteristics that distinguish A3 thinking from other problem-solving approaches:
It forces slowing down. Humans tend to jump to conclusions. A3 thinking interrupts that tendency by requiring the team to spend substantial time understanding the problem before proposing solutions.
It requires teamwork. There's no such thing as a lone-ranger A3. The methodology assumes that the people closest to the work have knowledge the project leader doesn't have, and that the work of analysis is collaborative rather than individual.
It produces sustainable countermeasures when done correctly. The discipline of the methodology, particularly the root cause analysis and the iterative experimentation phases, produces solutions that address underlying drivers rather than symptoms. Solutions that address drivers tend to hold.
It encourages collaboration through the visual artifact. The single-page format means anyone can see where the project is in the process at a glance. The visibility supports the kind of dialogue that produces better thinking.
One of the most operationally useful framings Jess offers is the problem complexity spectrum. The question of when to use A3 versus other tools is one of the most common questions practitioners have, and the complexity spectrum gives a usable answer.
On the low-complexity end sit problems where the solution is generally known. Examples Jess gives: disorganized tools in a workplace (5S is the answer, not an A3), a recurring software bug with five customer complaints this month (fix the bug, not run an A3). For these problems, a single PDCA cycle is usually enough. The A3 methodology is overkill -- it adds friction without adding value when the root cause is already understood.
On the high-complexity end sit problems that require more sophisticated tooling. Examples: mating component fitting issues caused by tolerance stack-up in manufacturing assembly, optimizing hospital staff scheduling based on historical patient demand patterns. These problems benefit from tools like DMAIC (Define, Measure, Analyze, Improve, Control) from Six Sigma, which is built on the same scientific method foundation as A3 but provides more rigorous structure for measurement-and-analysis work. A3 can be used at this end, but typically needs supporting documentation that exceeds what a single page can hold.
Most problems sit in the middle. Examples Jess offers: reducing rework in an assembly process, increasing the accuracy of pricing estimates. The solution isn't obvious. The problem is bounded enough that structured analysis can produce a useful answer. The work benefits from team-based root cause analysis and iterative countermeasure testing. This is A3's natural territory.
The classic Lean-versus-Six-Sigma debate misses the point. The approaches are complementary. What matters is following a disciplined structured process appropriate to the problem complexity. A3 provides a strong foundation for the middle territory, which covers most of what most CI practitioners encounter.
The standard A3 process has eight steps, though Jess presents it as seven by combining steps two and three into a single current-and-target condition step. Her reasoning: in her experience, identifying the current state and setting the target happen together rather than sequentially, and the combined step makes the workflow cleaner.
The seven steps as Jess teaches them:
Step 1: Define the problem. Understand the situation from the customer's perspective. Resist the urge to include a proposed solution in the problem statement.
Step 2: Current and target conditions. Identify the gap between where you are and where you need to be, with quantifiable metrics for both.
Step 3: Root cause analysis. Spend the time required to understand why the problem is happening, using tools like 5 Whys and fishbone diagrams.
Step 4: Countermeasures. Experiment with potential solutions, testing one or two changes at a time to avoid confounding factors.
Step 5: Evaluate results. Compare the outcome to your target using the same measurement system you used to establish the current state.
Step 6: Sustain the gains. Put monitoring and triggers in place so the improvement doesn't erode over time.
Step 7: Reflection (Hansei). Capture what went well and what should be improved next time. This is the step most teams skip, and the one that produces the compounding improvement in A3 capability over multiple projects.
The proportion of effort matters as much as the steps themselves. Jess spends roughly 60 to 75 percent of her A3 effort on the first three steps -- problem definition, current and target conditions, and root cause analysis. The remaining 25 to 40 percent goes to the last four steps. The investment in upfront analysis pays back substantially in the speed and accuracy of countermeasure work that follows.
The 60/75 distribution is the opposite of how most teams actually work with A3. Most teams flip this, spending 20 percent on problem definition and 80 percent on countermeasure development and implementation. The result is countermeasures that don't address root causes. Going slow at the beginning to go fast at the end is the discipline that distinguishes effective A3 work from improvement theater.
The choice to use her own communication problem as the worked example was deliberate. Jess had been doing A3s in professional contexts for years. Her hypothesis was that if the methodology worked for chronic professional problems, it should work for chronic personal problems too. She decided to test the hypothesis.
The problem was specific. She'd been having severe communication difficulties for several months. The issue had gotten serious enough that three different people had walked away from conversations with her thinking she was planning to leave her job. She wasn't. The gap between what she was actually communicating and what people were hearing had grown to the point that she couldn't ignore it.
The honesty of using a personal problem matters editorially. Most A3 webinars present sanitized case studies where the methodology produces clean wins. Jess's case study includes a failed A3 from her professional life that she opens with -- one where the team took a leadership survey indicating gaps in decision-making, didn't really understand what decisions or what gaps the survey was pointing at, and proceeded with a fuzzy problem statement that doomed the A3 from the start. The failure taught her more about A3 thinking than any of her successful projects. The discipline of the methodology became real to her through what happened when she didn't follow it.
The first step of any A3 is defining the problem clearly. This is where most A3s start to fail, and Jess uses a specific example to illustrate the failure mode.
A bad problem statement includes a solution: "We need to reduce our delayed shipments through purchase of digital equipment." The statement has already jumped to the conclusion that the answer is digital equipment. The team isn't going to discover whether that's actually the right solution, because the problem has been framed in a way that assumes it is.
A better version of the same problem: "We have a six-month spike in customer complaints about late shipments and rising internal expedite shipping fees." No solution embedded. Just the problem, in specific quantifiable terms.
For her own communication problem, Jess applied the same discipline. The problem statement wasn't "I need to learn the Socratic method" or "I need to stop being so direct." It was the gap between what she was communicating and what people were receiving, evidenced by the three colleagues who had inferred she was planning to leave.
The framing matters because it shapes what the team will explore. A problem statement with a solution embedded in it constrains the analysis to confirming the solution. A problem statement that just describes the problem opens the analysis to whatever the data actually shows. The Einstein quote Jess invokes makes the point: if he had an hour to solve a problem, he'd spend 55 minutes thinking about the problem and five minutes thinking about solutions. The proportion is closer to the right one than most teams' default practice.
The Toyota term for this discipline is Genchi Genbutsu -- literally "go and see" the actual problem in its actual location. Don't analyze problems from a conference room. Get your boots on. Watch the work happen. Understand what's actually going on before forming a hypothesis about what's causing it.
The second step is establishing the current state and the target with quantifiable metrics. The discipline here is that you can't improve what you can't measure. If your goal is "better communication," you have no way to know whether the countermeasures worked.
Jess used two measures for her communication problem. The first was a communication score from an online assessment -- 25 to 30 questions producing a score out of 100. Her baseline was 69. Her target was a 25 percent improvement, which would put her around 86.
The second measure was the percentage of miscommunications per opportunity. She defined an opportunity as a crucial conversation. At the end of each crucial conversation during the baseline period, she would check with the person she'd been talking to and verify whether the message she'd intended to communicate had actually landed. The baseline showed that 22 percent of the time, it hadn't. She set an aggressive target of 5 percent.
Two notes on her measurement choices. First, the online communication assessment is gameable -- you could answer the questions in ways that produce a higher score without actually improving your communication. Jess acknowledges this and notes that she tried to answer truthfully because gaming the measurement wouldn't help her solve the actual problem. The integrity of the measurement is in the user, not in the instrument.
Second, the miscommunication-per-opportunity measure required substantial discipline to capture. Each crucial conversation needed to be followed by a check-in with the other person. The data didn't exist in any pre-existing system. She had to create the measurement system as part of the project.
The general principle: when the metric you need doesn't exist, create it. Don't rely on subjective impressions of whether the process is improving. Find a way to measure it, even if the measurement is imperfect, and trust the data over the impression.
The third step is the deepest. Jess spends substantial time here because the quality of the root cause analysis determines the quality of everything that follows.
The 5 Whys methodology is straightforward in concept and harder in practice. Start with the problem. Ask why. Take the answer, and ask why again. Continue until further asking stops making sense. The five in "5 Whys" isn't magic. Sometimes the root cause emerges at three whys. Sometimes seven. The discipline is digging past the symptom level to the underlying driver.
Jess walks through her own 5 Whys for the communication problem. One thread:
Why was I having communication difficulties? Because I was jumping to conclusions in conversations rather than understanding the current situation first.
Why was I jumping to conclusions? Because I wasn't prioritizing feedback. I wasn't seeking out the information that would have told me the situation was different than I assumed.
Why wasn't I prioritizing feedback? Because new information is difficult for me. I have elaborate mental models, and integrating new information often requires adjusting those models, which is uncomfortable cognitive work.
At that point, asking "why is updating mental models uncomfortable cognitive work" stops being productive. The answer is something like "because that's how human cognition works under attention scarcity," which isn't actionable. The countermeasure has to address the actionable layer: the resistance to integrating new information that doesn't fit the existing model.
Another thread from her analysis:
Why do I have particularly poor communication when I'm stressed? Because my fight-or-flight thinking overrides my rational thinking.
Why does fight-or-flight override rational thinking? Because no saber-toothed tiger is actually chasing me, but my nervous system responds to the stress signal the same way it would to an actual threat.
Why am I not engaging rational thinking in stressed moments? Because I'm not always aware when I'm stressed. My default assumption is that my analysis is fine because normally my analysis is one of my stronger capabilities.
The countermeasure that emerged from this thread wasn't "be less stressed." It was "create space between stimulus and response when I notice I'm stressed -- don't have crucial conversations in that moment, give the situation time before acting."
The Q&A produced an additional technique worth pulling out. When you've completed a 5 Whys analysis, you can validate the logic by running it backward up the chain with the word "therefore." Start at the deepest cause and work back to the problem. "I have difficulty updating my mental models, therefore I'm not asking for feedback, therefore I'm jumping to conclusions, therefore I'm having communication difficulties." If the chain flows logically backward as well as forward, the analysis is sound. If it doesn't, you've gone down an unproductive thread and need to revisit the path.
The fourth step is countermeasure design. The language matters. Countermeasures are experiments. They're hypotheses about what will address the root cause. They're not solutions in the sense of guaranteed fixes.
Jess identified several countermeasures for her communication problem. Two of them turned out to be particularly effective.
The first was using the Socratic method to guide crucial conversations. Rather than entering a conversation with a position to defend, she would enter with questions. The questions surfaced information about the other person's perspective and gave her the chance to update her mental model in real time while the conversation was happening. The effect was substantial. The discipline of asking questions rather than asserting positions changed the dynamic of every crucial conversation she had during the experiment period.
The second was creating space between stimulus and response when stressed. The operational form of this countermeasure was simple: don't send important emails in the moment. Write the email, save it as a draft, and review it the next morning before sending. Her husband Shane helped hold her accountable to the discipline. There were several emails she wrote during the experiment period and never sent after reading them the next morning. The countermeasure prevented several specific communication breakdowns that would have happened if she'd sent the original emails.
Other countermeasures she tried produced more limited results. The discipline of running multiple countermeasures, evaluating each, and keeping the ones that worked is what distinguishes A3 experimentation from solution implementation. You don't know in advance which countermeasures will produce the effect you predicted. You find out by trying them and measuring.
The discipline Jess emphasizes here: don't change too much at once. If you implement five countermeasures simultaneously and the metric moves, you don't know which countermeasure produced the effect. Try one or two changes at a time. Evaluate. Adjust. Then try the next.
The fifth and sixth steps are evaluation and sustainment. Both are commonly underweighted relative to the front-end work.
Evaluation requires using the same measurement system established in the current-state phase. Jess's results: a 19 percent improvement in the communication score (against a 25 percent target) and a drop in miscommunication rate from 22 percent to 7 percent (against a 5 percent target). Neither target was hit precisely. She still calls the project a win because the gains are substantial and the methodology produced learning that will inform the next cycle.
The framing matters. Most A3 projects don't hit their targets exactly. The question isn't whether you hit the number. It's whether the methodology produced meaningful improvement and whether the team learned something that will inform future work. Both conditions were satisfied. The A3 succeeded.
Sustainment is where most A3s fail. The team makes gains, the project closes, attention moves elsewhere, and six months later the process has drifted back to its previous state. Jess set up specific monitoring practices to prevent this. Weekly check-ins to gather feedback on whether her communication had degraded. Monthly retake of the communication assessment to track the score over time. A trigger threshold: if the score drops below 80, that triggers a review of whether she's still using the Socratic method discipline and the email-overnight practice. Without the triggers, the gains would erode invisibly until someone -- or some moment -- forced her attention back to the problem.
The seventh step is reflection, which Toyota calls Hansei. After every A3, the team reflects on what went well and what should be improved. The reflection isn't pro forma. It's the discipline that produces compounding improvement in A3 capability over multiple projects.
Jess's reflection on the communication A3 surfaced several things. The 360-degree feedback she gathered was critical and would have been worth more of it. Her boss Shannon helped her see her resistance to changing mental models, an insight she hadn't seen on her own. If she were to do the A3 over, she'd incorporate more external feedback into the communication score itself rather than relying primarily on the self-assessment. She'd also dig deeper into stress management as a root cause -- the analysis stopped at the fight-or-flight level, but managing stress before it triggers fight-or-flight is the deeper actionable territory.
The companion practice to Hansei is Yokoten -- the lateral spread of best practices across the organization. After her successful Camry defect reduction, the first question she would get from leadership was always "have you looked at applying this to Avalon?" The methodology has the spread question built into the standard practice. For her personal A3, the question was different but the principle the same: are there other people who might benefit from elements of what worked? The countermeasures aren't cut-and-paste solutions for other people's communication problems, but the structure of the analysis might be useful for someone facing a similar issue.
Yokoten is the term that gave Jess's consulting practice its name. Her work is about helping organizations spread learning across their boundaries rather than rediscovering the same lessons in every department.
The closing principles Jess offers are worth pulling out as a unit because they capture the discipline the methodology requires.
Do trust the process. The right process leads to the right results. When the first experiments don't go as expected, go back to the team and reevaluate. Don't abandon the methodology because individual countermeasures didn't work.
Do seek a deep understanding of the problem. The discipline of slowing down in the front end pays back substantially in the speed and accuracy of countermeasure work that follows.
Do let the data drive decisions. Explore what's working and what isn't through measurement rather than impression.
Do sustain the gains. The improvements you produce in the first three months mean nothing if they erode in the next three.
Don't think A3 is a one-size-fits-all tool. Some problems benefit from simpler approaches. Some need more sophisticated tooling. Thinking is still required.
Don't work alone. There's no such thing as a lone-ranger A3. The team produces better thinking than any individual, including team leaders who would prefer to work independently.
Don't jump to root causes or solutions before investigating. The methodology's value depends on the discipline of working through the steps in order.
The closing principle Jess returns to most often is progress over perfection. She's done about 25 A3s in her career and none of them have been perfect. Every one produces entries in the "what should be improved next time" column. The discipline isn't to produce a textbook A3 on your first attempt. The discipline is to use a structured process that produces better results than you'd get without it, and to learn enough from each project that the next one is slightly better.
Jess's session is methodology-focused rather than platform-focused. She presents A3 thinking as a discipline that exists independently of any particular tooling. The platform integration is implicit rather than explicit.
That said, several specific practices A3 thinking requires are substantially supported by the platform.
The A3 storyboard as a living document during the project benefits from a system that holds it where everyone on the team can see it, including team members who aren't physically co-located. Jess uses paper-and-pencil A3s when the team is in the same place, but notes in the Q&A that she uses simple Excel templates for distributed teams. The platform extends this further, holding the storyboard as a structured document with role-appropriate visibility and edit permissions.
The sustainment work the methodology requires -- the monitoring, the triggers, the action when the metric crosses the threshold -- is exactly the kind of work platform infrastructure was built to support. Without it, sustainment depends on people remembering to check the metrics, which rarely scales beyond the immediate aftermath of the project.
The Yokoten practice of spreading learning across the organization depends on visibility of completed A3s to other teams that might benefit. When an A3 produces a successful countermeasure in one area, the platform can make that work discoverable to other areas with similar problems. Without a shared system, the lateral spread depends on people happening to mention their work to the right colleagues, which is unreliable and slow.
The 60-to-75-percent investment in the first three steps -- problem definition, current and target conditions, root cause analysis -- benefits from a system that holds the artifacts of that analysis durably. Fishbone diagrams, 5 Whys chains, baseline data, target metrics -- all of these are artifacts that benefit from being preserved and accessible across the project lifecycle.
The platform doesn't substitute for the methodology. The disciplines Jess teaches -- the slow thinking, the team-based analysis, the structured root cause work, the experimental countermeasure design, the sustainment vigilance, the Hansei reflection -- are practitioner disciplines that no system can perform on its own. What the system can do is hold the artifacts of the work in a place where they remain visible, accessible, and connected to the broader organizational improvement portfolio.
Jess Orr is founder of Yokoten Learning and a continuous improvement practitioner with more than ten years of experience across multiple industries. At Toyota, she earned the Toyota Business Practices certification through her work leading a project that reduced chronic Camry supply part defects by more than 75 percent. She later used A3 thinking to engage a workforce in continuous improvement in a project that helped save over 200 jobs. She holds two Six Sigma Black Belt certifications and a bachelor's degree in mechanical engineering from Virginia Tech. At the time of this webinar, she was working at WestRock in continuous improvement. She is available for coaching through her website at yokotenlearning.com and can be reached on LinkedIn.
What is A3 thinking?
A structured problem-solving methodology rooted in Toyota Business Practices and the scientific method. The name refers to the size of paper traditionally used to document the methodology (11x17), but the paper size doesn't matter -- what matters is the discipline of the process. A3 thinking guides teams through defining a problem precisely, establishing measurable current and target conditions, analyzing root causes, experimenting with countermeasures, evaluating results, sustaining the gains, and reflecting on the process to improve the next cycle. It's a thinking discipline more than it is a template.
How is A3 thinking different from other problem-solving approaches?
A3 thinking forces slowing down in a way most problem-solving approaches don't. It requires teamwork explicitly -- there's no such thing as a lone-ranger A3. It uses a single-page visual artifact that supports communication and alignment across stakeholders. And it builds in sustainment and reflection steps that most simpler methodologies treat as optional. The methodology is most useful for medium-complexity problems where the solution isn't already known but the problem can be bounded enough to analyze with structured tools.
When should I use A3 versus PDCA or DMAIC?
The choice depends on problem complexity. For low-complexity problems where the solution is generally known -- disorganized tools (5S), a recurring software bug (fix the bug) -- a single PDCA cycle is usually enough. For high-complexity problems requiring sophisticated measurement and analysis -- tolerance stack-up in manufacturing assembly, optimizing hospital staff scheduling against historical demand -- DMAIC from Six Sigma is often the better fit. A3 sits in the middle, which covers most of what most CI practitioners encounter: problems where the solution isn't obvious, the analysis benefits from team-based root cause work, and the work needs to produce sustainable countermeasures.
What percentage of A3 effort should go to problem definition and root cause analysis?
Jess spends 60 to 75 percent of her A3 effort on the first three steps -- defining the problem, establishing current and target conditions, and analyzing root causes. The remaining 25 to 40 percent goes to countermeasure design, evaluation, and sustainment. Most teams flip this distribution, which produces countermeasures that don't address root causes. Going slow at the beginning to go fast at the end is the discipline that distinguishes effective A3 work from improvement theater.
What makes a good problem statement?
A problem statement that describes the problem without embedding a solution. "We need to reduce delayed shipments through purchase of digital equipment" is a bad problem statement -- it's already jumped to the solution. "We have a six-month spike in customer complaints about late shipments and rising internal expedite fees" is a better statement -- it describes the problem in specific, quantifiable terms without prescribing how to solve it. The framing matters because it shapes what the team will explore. A problem statement with a solution embedded constrains the analysis to confirming the solution.
How do you know when to stop asking "why" in a 5 Whys analysis?
When further asking doesn't logically make sense. The five in "5 Whys" isn't magic. Sometimes the true root cause emerges at three whys, sometimes at seven. A useful validation technique: once you've completed the chain, run it backward up the chain with the word "therefore." If the chain flows logically backward as well as forward, the analysis is sound. If the backward flow doesn't make sense, you've gone down an unproductive thread and need to revisit the path.
How much should I train my team on A3 thinking before starting a project?
Don't show them the template right away. The template can overwhelm people who haven't seen it before, particularly when they're looking at seven or eight unfamiliar steps. Better practice: guide them through the methodology step by step, building the A3 together as the project progresses. The team learns the methodology through doing the work, not through training that precedes the work. Focus on the process within each step rather than on the tool.
What if I run out of space on the A3 and need more PDCA cycles?
Start a child A3. After you've completed the initial A3 and produced gains, if you want to push further, create a new A3 that defines the remaining gap as its own problem. Jess recommends this over layering more PDCA on the original A3 because the process you're working with may have changed since the first A3 started, and the child A3 lets you re-baseline against the new current state.
Should I do a storyboard for every A3, and when should I create it?
Yes, and create it during the project rather than after. The storyboard serves three functions. First, it guides the project through the steps -- if a section is blank, you know what work still needs to happen. Second, it makes the project's status visible to team members and stakeholders at any moment. Third, it produces an artifact that can be referenced later if a similar problem comes up, supporting the Yokoten practice of spreading learning across the organization. Creating the storyboard after the fact, when the work is already done, defeats most of these purposes.
How do you set SMART goals that are challenging but achievable?
Ask the team what they think is reasonable for the time frame, then add about 5 percent to challenge them. Or look at historical gains from previous A3s on similar problems to set a baseline expectation. For projects with executive sponsorship, the target setting is often a negotiation: leadership might want a 50 percent reduction, the team might propose 30 percent, the agreed target lands at 40 percent. The exception is safety: the only acceptable target for safety incidents is zero, even if zero isn't achievable in the time frame.
Is it okay if an A3 fails?
Yes. Failed A3s are how practitioners learn the methodology. Jess opens this webinar with a story about a failed A3 in her own work -- one where the team started with a fuzzy problem statement (taken from a leadership survey indicating gaps in decision-making, without understanding what decisions or what gaps the survey was actually pointing at) and produced an A3 that couldn't recover from the bad start. The failure taught her more about A3 thinking than any of her successful projects. After about 25 A3s, she notes that none of hers have been perfect either. The discipline isn't to produce a textbook A3 on your first attempt. The discipline is progress over perfection.
How does this connect to Toyota's broader methodology?
A3 thinking is part of Toyota Business Practices (TBP), the formally documented problem-solving methodology Toyota engineers are certified on. It connects to several other Toyota practices: Genchi Genbutsu (go and see the actual problem), Hansei (structured reflection after the project), and Yokoten (lateral spread of learning across the organization). The methodology is grounded in the scientific method but specifically shaped by decades of Toyota's experience using it across manufacturing, supplier development, and organizational improvement work. The Toyota lineage is one of the reasons the methodology has held up across multiple industries -- it was refined through repeated practice against complex real-world problems before being exported.
.svg)
Copyright © 2026
Privacy Policy