How Can You Use AI to Ask Gemba Questions That Actually Get to the Root Cause?

Welcome back to the series on becoming an irreplaceable operations manager. In past posts, we’ve covered turning shift notes into a to-do list and getting one update to every stakeholder who needs it. This post takes on the third item on our list: brainstorming Gemba questions sharp enough to actually find the problem, not just describe it.

You’re standing at the line, clipboard in hand, and your brain goes blank.

Or worse, it doesn’t go blank. It goes straight to the same five questions you always ask, the ones that get you the same five answers, none of which explain why this keeps happening.

That’s not a Gemba walk. That’s a lap.

Gemba means the real place for a reason. You’re supposed to be down there uncovering something you couldn’t see from your desk. Show up with generic questions and you get generic answers, the kind that sound like insight but don’t move the root-cause investigation anywhere.

Meanwhile, everybody’s watching you not have a good question. The operator’s waiting to get back to work. Your site leader wants to know if this walk was worth pulling people off the line for ten minutes. And you’re standing there with “so, uh, how’s it going?” as your best shot.

Give AI the Situation, Not Just the Symptom

Post one covered the four elements of a strong prompt: Situation, Data, Constraints, and Output. For Gemba questions, Situation and Data carry almost all the weight. AI can’t walk the floor for you, so what it hands back is only as good as what you tell it you’re looking at.

●       Situation: what process or line you’re watching, and what normal looks like compared to what you’re seeing now.

●       Symptom, not theory: “downtime is up” is a symptom. “Line 4 stops for about ten seconds every time the sensor at station 3 trips” is data.

●       Depth: tell it your Lean or Six Sigma background so it skips the beginner questions and gets to the ones worth asking.

Vague in, vague out.

What If You Don’t Know What Normal Looks Like Yet

New to this line, or new to the role entirely? You can’t spot the deviation if you don’t know the baseline. Ask AI to help you build that first, before you go anywhere near the actual problem.

Describe what the process is supposed to do and ask it for a short list of questions that establish normal: expected cycle time, what the equipment sounds and looks like when it’s running right, what the operator’s routine looks like on a good day. Your first walk on an unfamiliar line gets spent learning it, instead of guessing at what’s wrong with something you’ve never actually seen work correctly.

That list is reusable. Save it, and you’ve got a fast way to get oriented on any new line, not just this one.

The Prompt

Give it the real symptom, not your best guess at the cause, and let it build the questions from there:

You are an expert in Lean manufacturing and root-cause analysis, acting as a Gemba walk coach. Here is the situation: [describe the process or line]. Here is the specific symptom I’m seeing: [describe exactly what’s happening, not your theory about why].

Structure your output using the exact sections below:

1. CLARIFYING QUESTIONS

- Three questions to ask before I even start walking, to make sure I’m looking at the right thing.

2. ROOT-CAUSE QUESTIONS

- Five specific questions to ask the operator or the equipment itself, based on the symptom I described, not generic manufacturing questions.

- For each question, one sentence on what a surprising answer would tell me.

3. WHAT TO PHYSICALLY CHECK

- Two or three things to look at, touch, or measure while I’m standing there, not just ask about.

4. MY OWN BLIND SPOT

- One question that challenges my own first guess about the cause, so I don’t walk in already sure I’m right.

Keep the questions specific to what I described, not generic Lean training material I could find anywhere.

What Comes Back

Say the symptom is this: line 4 micro-stops for about ten seconds, six or seven times a shift, and nobody’s traced it to one cause. Feed that in, and you get back something like this:

●       Clarifying: does the micro-stop happen at the same station every time, or does it move around the line?

●       Root cause: walk me through what the operator does in the ten seconds right before it stops, not after.

●       Physical check: look at the sensor at that station for buildup or misalignment, not just the control panel readout.

●       Blind spot: you think it’s the sensor. What would it look like if the real cause were upstream, like a slightly inconsistent feed rate from line 3?

That last one is the one that stings a little. Good.

Layer In the Five Whys

Once you’ve got an answer to a root-cause question, don’t stop there. Six Sigma has a name for this move: the Five Whys. Ask why the answer is true, then ask why that’s true, and keep going. AI is actually good at this part, because it won’t get impatient after the second why the way a rushed operator might.

Take whatever answer you got and hand it right back to the same conversation: “Here’s what I found out: [answer]. Ask me why, then keep asking why based on my next answer, five times.” You’ll usually hit the real cause somewhere around why number three or four, not why number one.

The first why is never the real answer. It’s just the loudest one.

Know This Doesn’t Replace the Walk

Here’s the trap: AI will hand you a confident list of possible causes, and confident is not the same as correct. It’s working from your description, not the actual machine.

Here’s a version of this that actually happens. You ask for root-cause questions. One of them nails a plausible answer. The answer feels so right, so you stop digging. You report back that the micro-stops are caused by sensor drift. Maintenance recalibrates the sensors.

Then, BAM!

Two weeks later the exact same problem is back!

The sensor was never the real cause. It was compensating for something upstream that nobody checked, because the first plausible answer felt like the finish line.

If you take its best guess back to your team as fact instead of a starting point, you’ll spend a shift chasing a theory instead of the truth. Use the questions to guide your walk. Don’t skip the walk because the questions sounded smart.

The same goes for the operator you’re questioning. These prompts hand you sharper questions, not a script to read at someone. Ask them the way you’d actually talk to a person you respect, not like you’re running a checklist.

Fine-Tune It Fast

If the first batch doesn’t fit what you’re actually seeing, say so:

●       “Give me three more, all about the material feeding into this station, not the machine itself.”

●       “Assume I already checked the obvious. What am I missing?”

●       “Turn this into questions I can ask the operator without it sounding like an interrogation.”

●       “I only have five minutes on this walk. Cut this down to the two questions that offer the most immediate operational impact.”

The more you refine your “ask” the better answers you’re likely to get from your AI service.

Try It on Your Next Walk

We are three prompts into the series now. The goal isn’t to help AI replace you but to teach you how to use AI so that you become irreplaceable to your organization. More importantly, these prompts help you recover minutes you used to spend staring at a blank notepad, or asking the same five questions because your brain hadn’t caught up with your legs yet so you can devote them to more productive and beneficial pursuits.

Those minutes, saved here and there, by using AI, add up fast to give you back more of your day so you can pursue meaningful process improvements.

Subscribe to TheDailyConstraint so you catch the next post in the series, where we tackle other aspects of becoming an irreplaceable operations manager like jump-starting your start of shift and turning your shift notes into a clean handoff at the end of the day. Try today’s prompt before your next Gemba walk and let me know in the comments if it helped you ask more productive, results-oriented Gemba questions.