Most organizations don't have a problem-solving problem. They have a slowing-down problem.
The bias for action runs deep in North American and European management culture. Decades of planning without follow-through created a reaction: just do it. Kaizen events emphasize speed. Improvement programs reward visible activity. The result is a workforce trained to skip the planning phase and start implementing -- often before the actual problem has been defined.
Jon Miller has spent more than 25 years watching that pattern. Born and raised in Japan, he began his Lean career as an interpreter and translator working alongside Japanese consultants from the Shingijutsu company bringing TPS methods to North American manufacturers in the 1980s and 1990s. He went on to found Gemba Research in 1998, served as CEO of Kaizen Institute Consulting Group after the firms merged in 2011, and co-founded Gemba Academy. He has co-authored the Shingo Prize-winning book Creating a Kaizen Culture and has written over a thousand articles on his blog Gemba Panta Rei.
His framing for this session is borrowed from a phrase that has been around the business world for years: go slow to go fast. The principle isn't that slower is better. It's that organizations that invest enough time in the planning and checking phases of PDCA make their implementation faster, more effective, and more durable than organizations racing to action. Measure twice, cut once. Sharpen the axe before chopping the tree. The folk wisdom is correct. It got abandoned somewhere along the way and needs to come back.
This webinar is a conversation format -- Jon in dialogue with Mark Graban -- working through the Toyota Business Practices 8-stage problem-solving process and the patterns that make it work or fail in real organizations.
Mark opens the substantive discussion by noting that the bias for action sometimes produces work people have to redo because the problem wasn't well understood at the start. Jon agrees with the diagnosis and adds the missing piece: deliberate doesn't mean slow.
The framing matters because most leaders, when told to slow down, hear "do less" or "take longer." That's not the argument. The argument is that the time spent clarifying the problem and understanding root causes is what makes the rest of the work efficient. Skipping it doesn't save time -- it relocates the time to a later stage where the cost is higher. Countermeasures aimed at the wrong cause produce iteration. Iteration produces frustration. Frustration produces abandonment.
The deeper principle is in the language. Practical problem solving is practical because it requires practice. Practical because it is realistic, not idealistic. The goal isn't elegance or completeness on the first attempt. The goal is structured movement toward a real result.
Asked to describe the process at the highest level, Jon reduces it to three things. Make sure you're working on the right problem. Make sure you're addressing it through an understanding of root causes. Make sure your countermeasures actually counter those root causes.
If those three things connect properly, the work succeeds. When practical problem solving fails -- whether in an A3, a Kaizen event, or a daily improvement -- one of those three is missing or misdirected. The eight stages are a way of operationalizing those three principles with enough resolution that practitioners can act on them. The number of stages isn't sacred. The connection between them is.
The lineage goes back further than most practitioners realize. The Shewhart cycle, developed by Walter Shewhart in the 1930s, became the foundation of Deming's improvement work in Japan after the war. Deming initially applied it to product development, then to production processes. Ishikawa and other Japanese practitioners built it into the QC Circle system, then into the broader TQC and TQM programs. The structured "storyline" most A3 thinking borrows from was already present in TQC and TQM decades before A3 became a recognized term.
Toyota's recent codification as Toyota Business Practices (TBP) reflects something specific: as a global company with factories on every continent and workers across many cultures, Toyota recognized that the traditional Japanese apprenticeship model -- come up alongside a master, watch, copy, eventually internalize over 10 to 20 years -- couldn't scale. TBP makes explicit what used to be implicit. It is the same thinking, with the steps detailed in a way that can be taught across languages and cultures without depending on multi-decade apprenticeships.
Mark raises a question worth holding. Why is a formal problem-solving methodology useful at all, as opposed to "go solve problems"?
Jon's answer is sharper than the usual one. Formal structure matters if you want to reach the level of unconscious competence -- the place where the thinking is automatic and doesn't require conscious effort. Nobody reaches unconscious competence in anything without practice. And practice requires structure. The structure isn't about constraining the natural problem-solver. It's about giving everyone else a path to develop the skill.
A second reason is teachability. Even if some people are natural-born problem-solvers, the organization can't rely on naturals. It needs a way to develop the skill in people who don't start with it. A framework gives the organization a curriculum -- a way to coach, evaluate, and practice deliberately.
The third reason is less obvious but important. There are right ways and wrong ways to practice. Practicing the wrong way at the piano or in athletics produces bad habits and injuries that are hard to undo later. The same is true of problem-solving. Without structure, people develop habits -- jumping to solutions, treating containment as countermeasure, declaring victory after one cycle -- that become harder to correct the longer they operate.
The question isn't whether to have a framework. It's whether to use a framework that produces good habits or no framework at all and accumulate bad ones.
Most struggles in practical problem solving show up here. Human nature pushes toward solutions before the problem has been adequately defined. People arrive with their proposed answer and then reverse-engineer a problem statement that justifies it.
Jon offers a checklist for what a clarified problem statement actually requires. It doesn't contain a cause. It doesn't contain a solution. It defines a gap -- ideally against the organization's goals, customer goals, and the team's own goals. These are simple criteria. They are surprisingly hard to do consistently. Most "problem statements" practitioners encounter fail one or more of them.
Breaking the problem down is the next discipline. Most problems are composite. They have multiple elements, multiple processes contributing to them, multiple stakeholder groups involved. Trying to attack the entire problem at once produces large, expensive solutions that are hard to back out of and often don't get you the whole way. Breaking the problem down -- by where, when, who, what (not yet why) -- lets you classify the data, group the phenomena, and pick a specific piece to attack first.
The example Jon uses is sharper than typical: he points to the city of Seattle's stated goal to end homelessness. Without the breakdown work, the response defaults to general spending that may or may not address specific causes. The phenomenon grows rather than shrinks. The breakdown question -- who specifically, where specifically, what specifically is going wrong -- is the work that turns a "big bag" problem into something a team can actually act on.
Stage three is often misunderstood. The Japanese wording translates roughly as "set an achievement target" or "set a target that will be achieved." The word commitment matters. This isn't a stretch goal handed down from leadership. It isn't a sandbagged minimum. It is a real commitment the team makes after having clarified and broken down the problem, based on what they actually believe they can achieve.
The implication has two sides. For the team, committing early -- before doing root cause analysis -- removes the fear of overcommitting to a number after the fact. The commitment scopes the analysis. Rather than trying to solve all of the problem, the team is solving the specific piece they committed to, with the option to come back for the next piece on the next cycle. For leadership, the commitment is something to coach against, not enforce against. An enlightened leader sees that the team committed to a 3% improvement and asks if there's a broader scope they could consider -- but does so as a coaching question, not as a mandate.
Mark adds a useful counterpoint from a customer organization he admires: their teams aim for roughly 50% improvement but get the same recognition when they achieve 30%. The point isn't the precision of the target. It's that the culture protects experimentation by recognizing the work, not just the outcome. Fear-based cultures produce sandbagged targets and risk-averse problem-solving. Cultures that protect honest commitment produce real improvement.
One of the most useful distinctions in the conversation is between short-term containment and true countermeasures.
Containment is what you do when the building is on fire. Get people out. Stop the bleeding. Add inspection stations, add rework, add whatever it takes to protect the customer right now while the longer work of root cause analysis proceeds. Containment is necessary. It is not improvement.
Countermeasures are different. A countermeasure is an action specifically aimed at a root cause you've identified. The word matters because "solution" implies finality -- you've solved it, you can move on. A countermeasure acknowledges that the problem may not be 100% resolved on the first attempt. There may be other root causes. The countermeasure itself may need to be adjusted. The work is iterative.
Jon's framing: many organizations spend years in containment without ever doing the root cause work. They add inspectors, add checks, add reminders -- all of which are valid short-term moves but none of which actually eliminate the cause. The problem persists because the underlying system hasn't changed. Containment without countermeasure is firefighting forever.
Mark raises a common claim from the Lean Startup community: "all you need is to ask why five times." Jon's response is direct. Any sentence that begins "all you need is..." is a bad hypothesis. Nothing complex resolves to a single technique.
The deeper point about 5 Whys is that root cause analysis rarely runs as a clean linear chain. More often it looks like exploring an ant nest -- you go down one path, it splits, you have to decide which branch to follow. If you hit a dead end, you come back to the branch point and try another route. Multiple causes can contribute to the same phenomenon. Multiple paths might be valid. The single-linear-chain version of 5 Whys is the simplified textbook example, not the typical reality.
The breakdown work in stage two is what makes root cause analysis manageable. If you've broken the problem down properly, you're not trying to find the root cause of "patient wait times" as a single composite phenomenon. You're finding the root cause of a specific, observable, scoped piece of that phenomenon. The chain stays manageable because the problem stayed manageable.
Jon also references Deming's system of profound knowledge as a useful diagnostic. If root cause analysis is going wrong, one of four areas is usually being neglected: understanding of variation, human psychology, theory of knowledge (epistemology), or appreciation of the system. These are the four big failure modes that catch problem-solvers who rely on intuition. Cognitive biases produce false pattern recognition. Variation gets ignored or misread. The system context gets lost in favor of attention to individual events.
The final stage matters more than most teams give it credit for. The work isn't complete when the improvement shows up in the data. It's complete when the standard has been updated, the new process is being audited, the lessons are shared with teams who might face similar problems, and the next gap is named so improvement continues.
The Japanese concept yokoten applies here -- the deliberate horizontal spread of learning from one team or area to others who could benefit. Yokoten doesn't mean copy-paste. It means sharing the process, the lessons learned, and the failure modes so other teams can adapt rather than start from scratch. Without this, every team re-solves the same problem in parallel and the organization never accumulates institutional knowledge.
The "start again" is the recognition that PDCA is a cycle, not a project. The improvement that closed one gap reveals the next gap. The standard that worked today is the baseline that gets challenged tomorrow. Practical problem solving isn't a method you finish. It's the way the work gets done.
One of the more honest moments in the conversation comes when Mark asks about lack of education showing up as a root cause -- the "try harder" countermeasure that surfaces when teams want to look like they've done the work but haven't.
Jon's response separates two ideas. The true root cause and the actionable root cause may not be the same thing. If your problem-solving team has the authority and resources to address lack of training, then lack of training is both a true cause and an actionable cause. If you've dug deeper and the real cause is that leadership doesn't believe people need to be trained well, that's a true cause -- but it's not actionable to a frontline team. You can't fire your management. You can't restructure the company from inside a Kaizen event.
The discipline is to dig until you find a root cause that is both real and addressable at your level of authority. Sometimes the answer is that the true root cause sits above where you can reach, and the responsible move is to address the deepest cause you can actually act on while making the higher-level cause visible to leaders who can. That's not selling out. That's recognizing the boundary of practical problem solving and the boundary of revolution.
Practical problem solving at scale depends on infrastructure that supports the discipline rather than fighting it.
The 8-stage structure works best when teams can document their thinking as they go -- not as a post-hoc report but as a living workspace during the analysis. A3 templates integrated into the platform make the format a thinking guide rather than a form to fill out at the end. The stages are visible. The status of each is trackable. The next step is obvious.
The yokoten principle -- spreading learning horizontally -- depends on visibility across the organization. A completed A3 in one department's binder cannot help a team in another department facing the same problem. A completed A3 in a shared system can. Teams can search, find prior work, contact the people who did it, and adapt rather than rebuild.
The commitment-and-check discipline -- committing to a target and then checking whether the process and results matched the commitment -- depends on tracking that's lightweight enough to actually use. Heavy manual tracking gets abandoned. Tracking that lives in the same place as the work gets used.
None of this substitutes for the discipline Jon describes. The platform amplifies what the practice produces. Without the practice, the platform produces tracked-but-shallow improvement. With it, the platform makes the discipline sustainable at organizational scale.
Jon Miller is co-founder of Gemba Academy and a former CEO of Kaizen Institute Consulting Group. He co-founded Gemba Research in 1998, which merged with Kaizen Institute in 2011. He has led dozens of Lean transformations across more than 20 countries and has co-authored the Shingo Prize-winning book Creating a Kaizen Culture. Born and raised in Japan and fluent in Japanese, he began his Lean career as an interpreter and translator for Japanese consultants in the 1980s and 1990s. He writes regularly at his blog Gemba Panta Rei and contributes to a variety of publications on Lean and Kaizen.
Mark Graban is Vice President of Improvement and Innovation Services at KaiNexus. He is an internationally recognized Lean consultant, author, and speaker with extensive work in healthcare and other industries, focused on strengthening improvement culture and leadership practices.
What does "go slow to go fast" actually mean?
It means investing enough time in the planning and checking phases of PDCA that the implementation phase becomes faster, more effective, and more durable. It does not mean working slowly or taking longer overall. The time spent clarifying the problem and finding root causes is what makes the rest of the work efficient. Skipping it relocates the time to a later stage where the cost of rework is much higher.
What are the three things that matter most in problem solving?
Work on the right problem. Address it through understanding of root causes. Take appropriate action against those root causes. The 8-stage framework is a way of operationalizing those three principles with enough detail that practitioners can act on them consistently. When practical problem solving fails, one of those three is usually missing or misdirected.
Why is a formal framework necessary at all?
Three reasons. To develop unconscious competence -- the level where the thinking is automatic and doesn't require conscious effort. To make the skill teachable, so the organization doesn't depend on natural-born problem-solvers. And to ensure that practice produces good habits rather than bad ones. Practicing the wrong way at piano or in athletics produces bad habits and injuries that are hard to undo. The same is true in problem-solving.
What's the difference between containment and countermeasure?
Containment is the short-term action you take to protect the customer or stop the bleeding while you do the deeper work. Add an extra inspector, add a rework step, add a check. Necessary, not improvement. Countermeasures are actions specifically aimed at root causes you've identified. The word "countermeasure" instead of "solution" matters because it acknowledges the work may need to iterate. Many organizations spend years in containment without ever doing the root cause work, and the problem persists.
Why commit to a target before doing root cause analysis?
To scope the analysis and remove the fear of overcommitting after the fact. If the team commits to closing 10% of the gap before starting root cause work, the analysis stays focused on that 10%. The team isn't trying to solve all of the problem. They're solving the piece they committed to, with the option to come back for the next piece on the next cycle. Setting the target after countermeasures are developed hedges the commitment and weakens the discipline.
Why isn't "ask why five times" enough?
Because root cause analysis rarely runs as a single linear chain. More often it looks like an ant nest -- one path splits into multiple branches, dead ends require backtracking, and multiple causes can contribute to the same phenomenon. The five-whys-as-clean-linear-chain version is the simplified textbook example, not the typical reality. Breaking the problem down properly in stage two is what makes the analysis manageable, because the chain stays focused on a specific scoped piece rather than trying to find a single root cause for a composite phenomenon.
What is yokoten and why does it matter?
Yokoten is the deliberate horizontal spread of learning from one team to others who could benefit. Not copy-paste, but sharing the process, the lessons learned, and the failure modes so other teams can adapt rather than start from scratch. Without it, every team re-solves the same problems in parallel and the organization never accumulates institutional knowledge. It belongs to the standardize-share-start-again work in stage eight.
.svg)
Copyright © 2026
Privacy Policy