The PDCA loop that every lean person already knows also applies to working with a large language model (LLM), but with Prompt replacing Plan. The model does the Do. Check and Act stay mainly with you. Our previous article (“Prompt, Do, Check, Act”) covered this loop at a higher level; today we go deeper into the most important part of it, the initial prompting and discussion with the model for best results. We will use problem solving as an example throughout, as anyone can relate to the topic.
Question: How do you actually prompt for problem solving?
Just like in lean thinking, there are value-added parts of a prompt and wasteful parts. And interestingly, what worked well one year ago might not work as well today. In this article we will discuss the basic parts of a prompt, citing Anthropic’s own documentation for best practices,1 using the topic of basic problem solving. We encourage you to work along with an LMM as you read.
A Generic Prompt
Type this into any model:
Act as a problem-solving coach and help me think through a problem.
It is a reasonable request. Chat with the model and review what comes back.
The results will vary, and two years ago they varied a great deal. One response might give you design thinking. Another gives Six Sigma. Another gives 8D. Another frames the problem mathematically. Sometimes the model assembles a method of its own and presents it with complete confidence. A lot of that depends upon the exact model, thinking effort, and the personalized settings you have given it for memory. However, run the same prompt again tomorrow, and you will get a slightly different answer than you got today. Models are not deterministic, and responses will vary.
Notice, however, that nothing in that prompt told the model which exact method to use. In other words, we failed to give the model proper job instruction training or standardized work. There are thousands of examples of problem-solving coaching in the model’s training data, and we asked for all of them at once. So it averaged them. And it has to guess as to which one you want.
This is where many people were initially inclined to write off LLMs entirely. They typed in something generic, read what came back, and concluded the tools are useless. They were right about the output. They were wrong about the cause. Even the models of two years ago produced far better results when they were prompted or instructed properly. The limiting factor was not the model. It is what is increasingly being called the “harness.” Think of this as the prompt, tools, data, scripts, and other devices the model can access. An average model with a great harness can beat a great model with a poor harness.
We’re going to stick to the more basic part of the harness, known as the prompt. Quite simply, generic prompts produce underwhelming responses. In lean thinking this is the same as generic standardized work producing wide variation in operator results. The more that is left to interpretation, by the model or by the person, the less specific the result.
Anthropic publishes its own guidance on prompting, and it is worth reading directly,2 listing five general principles:
- Be clear and direct. Think of the model as a brilliant but new employee who lacks context on your norms and workflows. The more precisely you explain what you want, the better the result.
- Add context to improve performance. Give the motivation behind an instruction, not only the instruction. The model generalizes from the explanation.
- Use examples effectively. Three to five well-chosen examples steer the output more reliably than description alone.
- Structure the prompt. Separate your instructions, context, examples, and input so the model does not mistake one for another.
- Give the model a role. A single sentence of persona changes the behavior and the tone.
The golden rule is a good check on your own work: show your prompt to a colleague who has minimal context on the task and ask them to follow it. If they would be confused, the model will be too.
We will not cover each principle in detail. Instead we will build one simple problem-solving prompt and let the principles show up as we advance its complexity.
Clearly Specify the Method
The first basic change we will make to our initial, simplistic prompt is to tell the model to assume a persona and to specify which problem-solving method to use.
Assume you are an expert coach in the Toyota Business Practice eight-step method. Help me solve a problem.
Even 18 months to two years ago, on older weaker models, this produced a noticeably improved type of coaching response. Today, on frontier models like Claude Opus 4.8, Claude Fable 5, or ChatGPT-5.6 Sol, it does even better. With this subtle change in the prompt the model now sticks to one method instead of averaging across many. It will better follow a defined sequence, use the vocabulary of that method, and ask questions more relevant to the method.
We use Toyota Business Practice as our specific example here, but that obviously is not a requirement. Use the method you actually practice: 8D, Six Sigma, Kepner-Tregoe, Design Thinking. Use whatever your organization has standardized on and whatever fits the type of problem you are facing. The model does not care which method you pick. It just does a better job of following whatever method you clearly specify.
This is a one-sentence change and well worth making before anything else.
Specify the Steps and the Key Points
Next we will build upon the prompt and get even more specific. This is akin to Anthropic’s advice to add context and examples so the model understands your goal. Naming the method gets you into the right territory. It does not get you a good coach. The more recent frontier models all know the eight steps of Toyota Business Practice in name only:
- Clarify the problem
- Break down the problem
- Set a target
- Analyze the root cause
- Develop countermeasures
- See countermeasures through
- Evaluate both results and process
- Standardize successful processes
Most any model can recite those. The knowledge that matters, however, is inside them. What does “clarify the problem” actually require before you are allowed to move on? What separates breaking down a problem from simply restating it? Those key points are what a real coach uses, and they are what the model often does not have unless you supply them more clearly.
So for your problem-solving prompt write the steps and key points out and add more contextual details. Notice that this is the same work as writing a job instruction breakdown sheet, and it takes about as long to do well. Important steps, key points, reasons why.
Then add the rest of your situation:
- Your industry and your role. The coaching a maintenance engineer needs is not the coaching a plant manager needs.
- The type of coaching you want. Directive. Guided and neutral. Question-only. These produce three genuinely different sessions, and most people have never considered that they get to choose.
- Anything else that bears on the situation.
- What to avoid. For example, do not propose training as the countermeasure, and stay with cause-and-effect relationships that can be verified.
Click here for a sample of a fuller problem solving prompt.
Note: You will have to instruct the model to follow this prompt. Cut and paste works well. If you just drag and drop the prompt the model often considers it reference material or optional to follow.
The last item is worth pausing on. You can tell the model what to focus on, or be clear about the type of response you are guarding against. Do not propose training as the root cause or the countermeasure, for example. Or require a specific form of analysis. We will explain why later in the article.
Take One Step and Prompt It Properly
A perfectly normal instinct at this point is to keep making the prompt bigger, until the whole method is specified in one long eight-page document, for example.
That longer detailed pattern works very well most of the time. However, sometimes there is a better way. Unfortunately it varies by situation. For experimenting and learning, now try taking a single step out of the method and prompting that specific step on its own.
Root-cause analysis is an obvious one to start with. A model asked simply to “find the root cause” with Toyota Business Practice problem solving will reach for 5 Whys nearly every time, because that is what most of the internet contains. But that may or may not be the right tool for your problem. So, for example, you might want to additionally specify something like this in the body of the prompt:
- Which type of analysis fits this problem. 5 Why. Fishbone. Scatter plot. Design of experiments. The choice depends on the problem, and it is yours to make, not the model’s.
- Ensure that the point of cause is actually being addressed, rather than the point of detection.
- What was observed at the genba, and by whom.
- Who has been talked to. Operators. Maintenance. Engineering. Vendors. All concerned personnel.
- What data is to be collected, and of what type.
- Similar known root causes in your industry. The model may well have read more about these than we have.
- Guardrails. More on those below.
Click here for a sample root-cause analysis full prompt.
Note: You will have to instruct the model to follow this prompt. Cut and paste works well. If you just drag and drop the prompt the model often considers it reference material or optional to follow.
While this prompt is several paragraphs long, it’s not eight pages. And it will often do more work for you on that single step than the eight-page version, this is because everything in it is specific to the step you are actually working on. Problem solving is advanced one step at a time, so most of the time prompting a model should proceed one step at a time as well. Models can be like humans at times. Do not accidentally create confusion by mixing in “sharing best practices” when we really need to focus on “analyze the root cause.”
You can do the same for “clarify the problem” or any other step. One hyperfocused prompt will often serve you better than one that tries to carry the entire method at once. Of course, this all depends upon your situation and where you are in the process. Early on, generic-discovery-oriented prompts might work better. As you proceed, specific detailed ones will likely work better. One size does not fit all cases.
What to Leave Out
Detail is not what hurts a prompt. Irrelevant material does. Researchers added a single irrelevant sentence to math problems that models had already solved correctly, and accuracy fell sharply.3 Waste in a prompt behaves like waste anywhere else. It does not add value. Anthropic’s own guidance says much the same from the other direction, telling users to remove over-prompting and to stop handwriting the model’s procedure for it because the model’s reasoning frequently exceeds what a person would prescribe.4
So the rule is not to write less. It is to write clearly. Cut contradictions, cut stale instructions left over from an older model, and cut anything that has nothing to do with the step you are on. Keep the detail that is doing work.
Guardrails
The “what to avoid” part deserves its own name. Those are guardrails, and they are the part of the prompt most people fail to sufficiently address.
A model will hand you a root cause. It will do it confidently, on request, with no data. It will even propose a countermeasure (e.g., standardized work) before the true problem is clear. Guardrails are the lines that stop it:
- Analyze only the data I give you.
- Do not invent numbers.
- Do not state the root cause. Ask me for what you do not have.
- Do not blame the operator.
- Explain the probable cause-and-effect mechanism.
Most people writing a prompt are thinking about what they want the model to do. Guardrails are also about what it must refuse to do, and about the reasoning you want in place of the shortcut. Sometimes that is where the value in your prompt actually lives.
There is a limit to how far this goes when you retype the same instructions every morning. At some point you want the method installed rather than retyped, so that every time and everyone on your team is using the same instructions. That is called a “skill file,” and it is the subject of a future article.
Viwinco Problem-Solving Example
Tyson Heaton of LEI and Andrew Buczewski of Viwinco worked through a real-life version of this together. Air was getting trapped between two panes of glass during lamination, a scrap problem that had persisted for some time. What follows did not happen in one sitting. One exchange with the model set off a cascade that played out over time.
The first move was not to demand an answer. It was to add context and change the request. Instead of asking “how do I fix the bubbles,” they told the model which machine and process were in use, described what they did not understand, and asked it to teach the underlying chemistry as if to someone with a ninth-grade chemistry background. That is “add context” and “give the model a role” applied at once.
The response did not solve the problem, and that is the point. It created awareness on two fronts. First, it exposed assumptions about the machine and the process that the team had not known they were making. The model explained the chemistry, flagged that the process was unusual compared to the industry standard, and pointed away from operator variation. The reflex human answer had been to study the operator’s standardized work. The chemistry was the higher-leverage place to engage, and without the exchange the team would have been stuck longer. Second, it showed the team what the model could reach. Relevant industry knowledge existed that they had never tapped.
That second awareness is what let them keep going. They invoked research mode and asked the model to scour the academic and industry literature on this specific and relatively new glass chemistry. The model worked for about an hour. They filtered the reports and loaded them into a project as a shared knowledge base. From there they iterated with the project as a second coach. They ran experiments, built more shared context, and kept the interventions that moved the result. The outcome was better process controls and added checks at quality points in the process and in the machine. The scrap problem significantly declined. What was more valuable perhaps was how much the team learned in the process.
One case does not prove a rule, and we are not claiming the model is a better coach than the person. The model did not know the answer either. What the exchange did was surface the right question, make the team’s assumptions visible, and point to knowledge that already existed. The improvements came later, from the team’s own experiments, and only through testing and verification.
Where to Practice
If you want to practice this on your own, the self-paced lab from our last article is still open at https://aiworkshop.tech.lean.org/, housed on LEI’s LeanTech portal. We had workshop participants try it out together to see some of the differences we are explaining here. With experimentation you will get the idea pretty quickly. A login is required for basic security, a six-digit code comes to your email, and LEI collects no data. Check your spam filter if it does not arrive. We also run these as live workshops. Contact Tyson Heaton, LEI Executive Director Lean Tech/AI, if your organization wants this rapid-learning experience.
Summary
In lean thinking and problem solving, the initial steps always seem easy, but underneath they are deceptively difficult. Prompting a model for problem solving, coaching, or coding for that matter is remarkably similar. The analogy of Training within Industry job instruction is quite useful.
Name the method you actually use. Write out its steps and the key points inside them, and be clear on the reasons why, the same way you would write a job instruction breakdown. Add your industry, your role, and the kind of coaching you want. Add the things the model must not do. Then take one step and go more detailed. Root-cause analysis is a good example to experiment with when you reach that stage. Prompt that step on its own, in detail, with the facts and data and process the analysis requires.
And as in lean, cut anything in the prompt that is not doing work or adding value. Sometimes less is more. And you will have to experiment and learn by doing.
The model should not replace your own thinking. Do not outsource your understanding of a problem or its causes. But you can use it to help your thinking and get better results faster.
Humans + AI > Problems.
- “Prompting best practices,” Anthropic.
- Ibid.
- Shi et al., “Large Language Models Can Be Easily Distracted by Irrelevant Context,” ICML 2023.
- “Prompting best practices,” Anthropic.
