Manufacturing quality problem solving: a Pareto chart showing concentrated defect categories on a shop floor.

Stop Spreading the Peanut Butter: A Practical Guide to Quality Problem Solving in Manufacturing

July 24, 2026

|

By

Todd Hanlin

Summarize this article with:

TL;DR

  • Quality data piles up because collection becomes the endpoint. Quality problem solving starts when someone prioritizes the data and drives action.
  • Keep defect categories at 30-40, not 1,000 — at that level the Pareto actually tells a story.
  • Go after the top of the Pareto (the 15, 18, and 20 percent categories), not the 1 percent tail.
  • Stop spreading the peanut butter: go deep on one or two problems per cycle instead of giving 100 problems 10 minutes each.
  • Operations owns the fix; quality has to help. Cross-functional teams find root cause faster than any solo investigation.
  • Celebrate the wins — firefighting cultures have forgotten what one feels like. Part 2 shares hard numbers from a live A3 engagement in one work cell.

Questions This Blog Answers

  • What is quality problem solving in manufacturing?
  • Why does quality problem solving fail in most manufacturing operations?
  • Who should own quality problem solving on the shop floor?

Introduction

The facility I am working in right now has a mountain of quality data and almost no quality action. Thousands of defect records logged. Clean spreadsheets. Tools that can slice and dice the data into any Pareto chart you want. And yet the problems on the floor look the same today as they did six months ago. Nobody is forcing the issues up to the surface where someone could do something about them.

If you run a manufacturing operation, particularly in aerospace, defense, or any regulated industry with heavy quality documentation, this probably sounds familiar. The issue is almost never a shortage of data. It is a shortage of prioritized quality problem solving that actually closes the loop on root cause.

This is a two-part series. In this first piece, I want to walk through the principles that separate quality programs that actually move the needle from quality programs that just accumulate data. The short answer: pick the top two defects on your Pareto, put a cross-functional team on them, and go deep instead of spreading thin. The rest of this article is the why and the how.

Why quality data keeps piling up but quality problem solving stalls

Quality teams, by nature, are data boards. We collect data. We like having data. We build spreadsheets, databases, logging tools, and defect taxonomies to capture as much as we can. There is nothing wrong with that instinct. The problem starts when collection becomes the endpoint instead of the first step.

I used to tell teams they were wasting time collecting data they never used. I do not say that anymore. The collection is not a waste. The data has value the moment you decide to go back and ask a specific question. If you are not capturing it, you have no basis for any future decision.

What I have switched to saying is: you are not wasting time, you are missing opportunities. Every log entry that sits untouched is a signal that never makes it to someone who could act on it. The opportunity cost of uncollected data is being able to ask better questions later. The opportunity cost of uncollected action is the defects that keep happening on the line today.

Quality problem solving starts when someone takes the collected data, prioritizes, and drives action. Without that step, the rest is recordkeeping.

The defect category trap

One of the most common mistakes I see is breaking defect categories down to the nth degree.

If you have 1,000 defect categories, you do not have a prioritization tool. You have 1,000 buckets with two or three entries in each one. Which one do you go after first? You cannot tell. Neither can anyone else. The data is so fragmented that no single category ever accumulates enough mass to force a conversation.

The right level of granularity is usually 30 to 40 categories, not 1,000. Big enough that when a bucket starts to fill, you can see it. Big enough that four or five of those buckets will together represent 60 to 70 percent of your total defect volume.

When you back up to that level, the Pareto becomes obvious. You usually find one category at 15 percent, one at 18 percent, one at 20 percent, and then a long tail of onesie-twosies. I do not particularly care which of the top three you go after first. I care that you stop spending time on the bottom.

The 1 percent tail is where quality programs go to die. It feels productive to work on specific defects, because every specific fix is a story you can tell. But the math does not favor you. Solving a 1 percent problem buys you, at best, 1 percent of your time back. Solving a 20 percent problem buys you, representatively, 20 percent of your time back. Over a year, the gap compounds.

Go after the mass.

Stop spreading the peanut butter

Here is the pattern I see in almost every overwhelmed quality operation. There was a problem yesterday. Somebody asks about it on the daily walk. You have to have an answer. You assign a person. Another problem today. Another person. Another problem tomorrow. Another person.

What happens next is predictable. If you have 1,000 minutes of quality engineering time this week and 100 problems on your list, every problem gets 10 minutes. That is what I call spreading the peanut butter. Every slice of toast gets a thin layer. None of it tastes like much.

At the end of the week, you wonder why none of the problem solving was effective. The answer is in the arithmetic. No root-cause analysis worth the name happens in 10 minutes. No corrective action survives that kind of superficial treatment. You have not actually fixed anything. You have visited a hundred problems and left them where they were.

The alternative is uncomfortable at first because it feels like you are ignoring things. It looks like this: take the same 1,000 minutes and put 500 on one problem, 500 on another. Two problems. Go deep. Solve the problem. Make sure you picked the right two, which really means pick ones that matter, not ones that are perfect.

When you go deep, three things happen. First, you actually fix the problem, and it stays fixed. Second, you discover contributing factors that also apply to other defect categories, so you get collateral positive impact on issues you did not directly target. Third, the team starts to feel what a win looks like. In a firefighting culture, most people have forgotten.

Analysis paralysis: the enemy of quality problem solving

There is a version of this conversation that happens in every quality meeting I walk into. Somebody pulls up the data. Somebody else disagrees about which category is actually the biggest. A third person points out that the numbers are pulled from a different date range. The argument goes on. Nobody picks a problem. Nobody solves anything.

We can argue about first, second, and third all day long. We are still not fixing any problem.

The quality field is especially susceptible to this because precision is part of the job. Quality engineers are trained to get the number right. When the numbers disagree, the instinct is to reconcile before acting. That instinct is useful in the lab. On the shop floor, it is what keeps problems alive for years.

A rough prioritization, acted on this week, beats a precise prioritization acted on never. Pick something in the top three. Go deep. Come back next month and pick the next one.

Operations owns the fix. Quality has to help.

Quality problem solving is faster when operations, quality, manufacturing engineering, and the shop floor are in the same room.

Responsibility for fixing quality issues on the production line sits with operations. That is the right structure. Operations owns the process, the staffing, the tooling, and the delivery schedule. They have the authority to make changes stick.

That does not mean quality gets to disengage. Operations owning the fix does not absolve quality from supporting. The teams that solve problems fastest are the ones that put a manufacturing engineer, a quality engineer, an industrial engineer, a shop lead, a couple of mechanics, and a quality tech in the same room and tell them to go figure it out.

Every one of those people sees the problem from a different angle. The ME sees the tooling and the sequence. The QE sees the defect signature. The IE sees the workflow. The shop lead sees what actually happens when the supervisor is not looking. The mechanics know why the last fix did not work. Put them together and the root cause shows up faster than any individual investigation could produce.

Cross-functional (a core Lean Manufacturing principle) is not a buzzword. It is how you move.

What we are doing right now in one work cell

Rather than try to boil the ocean, we picked a single work cell. The A3 team is focused on defect reduction in that specific cell. We are looking at two things: what is coming in bad from upstream shops, and what is going out bad to the downstream ones.

We are going to identify the top defect coming into the cell and the top defect going out. Two problems. Not twenty. Two. Then we are going to solve them.

What I already know from experience, and what I expect to see confirmed in the data, is that the defects we surface in this one cell are going to show up in other cells too. Drilling defects tend to travel across drilling operations. Paint issues tend to travel across paint booths. Assembly handoff problems tend to travel across assembly areas. When we solve the root cause in this cell, the lessons translate.

We will have hard numbers in about two to four weeks. That is what Part 2 of this series will cover. I would rather show the math than predict it.

What leaders should take away now

Effective quality problem solving is not a tool problem. It is a focus problem. A few principles worth holding onto before the results arrive.

Collect data with a user in mind. If nobody is going to look at the log, do not make the collection elaborate. Collect enough to ask useful questions later. Keep the categories large enough that a Pareto tells a story.

Prioritize on mass, not on precision. The exact ranking of your top three defects does not matter as much as the decision to stop working on the bottom twenty. Top of the Pareto is where the time savings live.

Go deep on one or two problems per cycle, not on everything. Peanut-butter resource allocation produces peanut-butter results. Two deep investigations per month will out-deliver fifty shallow ones.

Put the right people on the team. Operations owns the fix, but quality, manufacturing engineering, industrial engineering, and shop-floor experience all need a seat. Problems that span functions need teams that span functions.

Celebrate the wins you do get. Most firefighting operations have forgotten what a win feels like. Every resolved defect category is also a culture change.

Common questions about quality problem solving in manufacturing

What is quality problem solving in manufacturing?

Quality problem solving is the disciplined work of identifying, prioritizing, and resolving defects in a manufacturing operation. It combines data analysis (Pareto charts, defect categorization), root cause investigation, and cross-functional action between operations, quality, and engineering. It is not just data collection. The collected data only matters when it drives prioritized fixes that stay fixed.

Why does quality problem solving fail in most manufacturing operations?

The most common failure is spreading limited engineering hours thinly across too many problems. If a team has 1,000 minutes of quality engineering time and 100 open issues, every problem gets 10 minutes, and no root cause survives. The fix is to pick two problems in the top of the Pareto and go deep.

Who should own quality problem solving on the shop floor?

Operations owns the fix because operations owns the process, the staffing, the tooling, and the schedule. Quality, manufacturing engineering, industrial engineering, and shop-floor mechanics support the investigation. The best results come from a cross-functional team working the same problem in the same room.

Closing thought

Quality data is not the problem. Quality data rarely fixes quality problems on its own. What fixes problems is prioritization, focus, and cross-functional teams going deep on a chunk of work that actually matters.

Part 2 of this series will show the data from the current engagement. My bet is that going after the top in-bound defect and the top out-bound defect in one work cell, with the right team, will produce more improvement in a month than the previous year of spreading the peanut butter did.

If you are sitting on a mountain of quality data and not enough quality action, the first move is not more data. It is picking something and going deep.

Want to talk about your challenges? Let’s connect.

Latest Insights

  • Manufacturing leadership team reviewing WIP and flow metrics during a lean transformation.

    Why Lean Transformations Plateau

    Early lean gains are real, and so is the plateau that follows. Tim Christlieb explains why the constraint shifts from individual processes to the…

  • Plant manager reviewing flow and constraints with a supervisor on a manufacturing floor shows operational excellence leadership behavior in practice

    Operational Excellence Is a Leadership Behavior

    Operational systems perform to the standard leadership allows. Tim Christlieb examines the tolerated behaviors that make congestion structural, the floor signals that reveal a…

Sign up to receive our latest insights!

"*" indicates required fields

This field is for validation purposes and should be left unchanged.
Name*