Before Dan Markovitz was a Lean consultant, he had what he calls a real job — five years at ASICS in sales, marketing, product marketing, and product development. The years inside an operating company gave him a vantage point most consultants don't have. He watched leaders, including ones he respected, run into the same three traps when something wasn't working.
Throw money at it. Hire a consultant. Buy new computers. Launch a training program. The spending feels like action. Sometimes it is. More often it changes nothing because the spending wasn't aimed at the actual problem.
Reorganize. Move from a functional structure to a matrix. Move back. Shuffle reporting lines. The new chart looks different. The work that wasn't working before continues not working, now with different titles attached to it.
Buy technology. New ERP. New CRM. New software, new hardware, new platform. The technology arrives, gets deployed, and produces what Dan called the classic outcome — a broken process that's now more expensive and faster, but still broken.
These three responses persist because they feel decisive. They produce visible action. They let leaders tell a story about having addressed the problem. What they share is that none of them actually require understanding the problem first. That's the trap.
Dan's book and this session are built around what to do instead — specifically, the first two of four steps he proposes for better decisions: go and see, and frame the problem properly. The other two steps (thinking backwards and asking why) get treated briefly. The session is workshop-style, with three video clips from "Bar Rescue" and two written exercises run live in the chat. The framing exercises are the most actionable part of the session, and the worked examples make the principles concrete in a way most A3 training never does.
Dan Markovitz is founder and president of Markovitz Consulting and helps organizations improve execution by invigorating their Lean efforts. His past clients have included Microsoft, WL Gore, Memorial Sloan-Kettering Cancer Center, CamelBak, Clif Bar, Goodyear Tire, and dozens of smaller companies. He is a faculty member at the Lean Enterprise Institute and teaches at the Stanford University Graduate School of Business, the Stanford Continuing Studies Program, and Ohio State University's Fisher College of Business. He is the author of "A Factory of One" and "Building the Fit Organization," both Shingo Research Award recipients, and "The Conclusion Trap: Four Steps to Better Decisions," published earlier in 2020. He lived in Japan for four years and is fluent in Japanese. He holds a BA from Wesleyan University and an MBA from the Stanford Graduate School of Business.
The origin story Dan opened with is worth telling fully because the entire framework follows from it.
A friend of Dan's runs a software development firm — custom software for things like dialysis machines and diesel engine repair. The president of a logistics company approached him. The logistics company had grown through acquisition, pulling together smaller geographically distinct firms in the Northeast, Northwest, Southwest, and so on, and the company wasn't doing a good job of passing leads between regions. A lead originating in the Northeast that would actually generate business if handed to the Southwest team would die inside the Northeast region. The president wanted a smartphone app. He was convinced an app would solve it. The current internal software was clunky and inconvenient, the staff griped about it, and a sleek mobile experience would fix the lead-passing problem.
Dan's friend agreed to build the app, but asked first to talk to the salespeople who would use it. The president said that wasn't necessary. Dan's friend said it was — that's how he worked. Reluctantly, the president agreed.
What the salespeople said when interviewed wasn't about the software at all. The clunky software annoyed them. A nicer app would be welcome. But the actual reason leads weren't moving between regions was that when a Northeast salesperson passed a lead to the Southwest, the Northeast salesperson got no commission. The Southwest team got the commission for closing it. So the Northeast team sat on leads they couldn't service rather than passing them.
Dan's friend went back to the president. The problem isn't technology. The problem is your incentive structure. I can build you an app, but it won't fix anything. The president said yes, but the software is clunky and I want an app.
They didn't end up working together.
The whole framework Dan walked through this session was built to keep leaders from being that president. The story is so clean it almost reads as a parable, but Dan's point is that variations on it happen constantly across every industry. Someone identifies a symptom, jumps to a familiar-feeling solution, and resists evidence that the solution doesn't fit the actual problem. The pattern is so common that recognizing it is most of the work.
Dan grounded the explanation in Daniel Kahneman's "Thinking, Fast and Slow." Two thinking systems run in every human brain. System one is fast, unconscious, automatic, low-energy. It's what makes you jump back when you see a snake on a hiking trail. It's what answers two-plus-two without you noticing yourself answer. System two is slow, conscious, laborious, energy-expensive. It's what you'd use to navigate the Tokyo subway from scratch or multiply 17 by 46 without a calculator.
Both systems are necessary. The problem isn't that system one exists. The problem is using system one for decisions that require system two. Under stress, fatigue, time pressure, or sheer volume of decisions across a day, the brain defaults to system one even on problems that genuinely need careful thought. A smartphone app is a system-one answer to a problem that needed system two.
Dan layered in a complementary observation from Nassim Nicholas Taleb. Faced with the limits of our knowledge — which is to say, all the time, because nobody ever has complete information — we resolve the tension by squeezing reality into commoditized ideas. The logistics president didn't know everything about his company's sales dynamics. He hadn't talked to his salespeople. So he reached for a commoditized idea — every successful modern company has an app — and treated that idea as if it were the answer to a problem he hadn't actually diagnosed. The reaching is the trap. The commoditized idea feels like analysis. It's actually pattern-matching dressed up as analysis.
The four steps Dan proposed are deliberate friction against this tendency. Speed bumps for system one. Go and see. Frame the problem. Think backwards. Ask why. They look familiar to anyone steeped in Lean — they're essentially the left side of an A3 — but Dan treats them as a general decision-making discipline applicable far beyond process improvement, including to strategy and leadership decisions where A3 thinking is rarely applied.
The session opened on the going-and-seeing step with a John le Carré line Dan said every Lean person should have tattooed somewhere: a desk is a dangerous place from which to view the world.
The translation into Lean language is the difference between data and fact.
Data is the spreadsheet. The report. The dashboard. The 88 percent OEE number. The return rate on shipments. The customer satisfaction score. Data tells you what's happening at a numerical level. It doesn't tell you what's actually going on.
Fact is what you observe when you go to where the work happens. The machines are leaking oil. The maintenance schedule shows the last preventive maintenance cycle was missed. The customer service screens are laid out in a way that forces the rep to tab across multiple fields to enter a single order. These are observable, specific, textured. Data is two-dimensional. Fact has depth.
Dan used a worked example from his ASICS years to make the distinction concrete. The company had a problem with order-entry errors. Customers were getting the wrong shoes shipped to them. The return shipping costs from retailers were substantial. From the data alone — error counts, return rates, return costs — the natural conclusions were either to hire better customer service representatives or put the existing ones through more intensive training.
Both conclusions assumed the problem lived inside the people. Going to see the work surfaced a different fact. ASICS had just deployed a new order entry system. The screens were terribly laid out — black background, green cursor, pre-WYSIWYG. Reps had to tab across the screen to enter information in non-logical sequences. The problem wasn't the reps. The problem was the screens. Better screen design produced the improvement that better training never would have.
Mark added a useful clarification during the session. Data can also be wrong. A bank thermometer showing the outside temperature as 214 degrees is data, but it's not a fact about anything except the thermometer's failure. The phrase "data-driven" often gets used as if data and reality are the same thing. They aren't. Data is one representation of reality, frequently incomplete and sometimes inaccurate. Facts come from where the work happens, observed by someone with the willingness to see.
Dan attributed the framing of "the crime scene" to his colleague Brent Gowalla. The crime scene is where the facts live. Investigators don't solve crimes from their office. They go to the scene and look at what's actually there. The Lean version of this is the gemba. The principle is the same.
The going-and-seeing portion of the session was structured around three video clips from the reality show "Bar Rescue," watched in sequence. Each clip showed more of the same struggling bar — Swanky Bubbles in Philadelphia — and the participants in the chat described what they thought the problem was after each clip.
After the first clip, most of the chat coalesced around surface observations. It's a trend bar. The name is bad. The concept is dated. The exterior looks run-down. The host of the show, John Taffer, had said early on that the problem was that Swanky Bubbles was a trend bar whose trend had passed.
After the second clip, the chat shifted. People started naming accountability issues, lack of ownership, no teamwork, the absence of leadership presence. The problem statements got further from surface and closer to operating conditions.
After the third clip, the chat shifted again. People named the absence of trust, lack of communication, frontline workers not being heard, owners who weren't soliciting feedback, no input from employees being acted on. The problem statements had moved from "this is a bar with cosmetic issues" to "this is an organization with human and cultural problems that no amount of remodeling will fix."
The arc of the exercise is the point. The same situation, observed at three increasing levels of depth, produces three substantially different understandings of the problem. The first level wasn't wrong. It just wasn't deep enough to drive the right intervention. The discipline of going and seeing is the discipline of staying long enough to get past the first impression.
Dan made one safety observation about the third clip that's worth pulling out. When Taffer asked the bartenders and wait staff to share what wasn't working, they didn't raise their hands. They wrote their concerns anonymously on pieces of paper, and Taffer brought those papers to the owners. The structure of that exchange is itself a diagnostic. The staff felt unsafe enough that they needed a third-party facilitator to surface their observations, and even then they needed anonymity. As you go and see, Dan said, pay attention to whether the people you're talking to feel safe enough to actually share what they're seeing. If they don't, the facts you'll collect will be partial at best.
Dan offered "Undercover Boss" as a counter-example of what going and seeing isn't. The premise of the show is that a senior executive disguises themselves to work alongside frontline employees. The joke is that nobody recognizes the executive, which itself indicates a problem worth examining. The executive then learns how hard the frontline work actually is, expresses appropriate emotion, and returns to the C-suite presumably wiser.
The reality most leaders engage in is less dramatic but operates on the same principle. Dan described a friend's experience at American Express. Senior leaders would fly in on the corporate plane, get a PowerPoint presentation in a conference room at the remote customer service facility, listen to one or two customer calls handled by the highest-performing rep on the floor, write up a report about what they had observed, and fly home before dinner.
That isn't going and seeing. That's tourism. The leader experiences a curated, sanitized, presentation-friendly version of the work. The actual conditions on the floor — the frustrations, the workarounds, the systems that don't quite fit together, the conversations between coworkers when the manager isn't watching — never get observed.
Dan connected this to Edgar Schein's "Humble Inquiry." Humble inquiry derives from an attitude of interest and curiosity, oriented toward building relationship. When you go to a facility and sit in a conference room and watch a presentation, you aren't doing humble inquiry. You're being shown things. The questions matter. The willingness to ask questions you don't already know the answers to matters. The willingness to be present long enough to let people open up matters. Without these, going to the gemba becomes a checkbox activity that produces the same conclusions you would have reached from your desk.
The second half of the session was about framing, which Dan argued is the most underexplored aspect of problem-solving in the Lean literature. Books on A3 thinking devote substantial space to current state analysis, background, and root cause work. They don't typically spend much time on the problem statement itself. Dan's position is that the problem statement is doing more work than people realize, and framing it well or badly determines the trajectory of everything that follows.
The opening principle: distinguish among symptom, cause, and problem.
A symptom is what you observe. The patient has a fever of 102. There aren't enough beautiful women at the bar. Sales are down.
A cause is what's producing the symptom. The patient traveled to a region with endemic infection. The bar has a bad name and outdated decor. The marketing campaign isn't reaching the target demographic.
The problem is what actually matters operationally — the gap that needs to be closed, regardless of what's causing it.
Dan worked the Bar Rescue example through this lens. Participants in the chat had named many things they thought were the problem with Swanky Bubbles — accountability, ownership, leadership presence, lack of communication. Dan's argument was that all of those are causes, not the problem. The problem is that Swanky Bubbles is losing $4,000 a month. If the bar were making money hand over fist, the absence of owner presence, the run-out liquor, the silly name — none of those would matter enough to address. They matter because they're contributing to the financial loss. The financial loss is the problem. Everything else is a cause.
The same logic applies to a patient with a fever. The fever is the symptom. The travel history is the cause. The problem is the bacterial infection. The treatment addresses the problem, not the symptom and not the cause.
The Lean community, Dan said, is so well-trained on root cause analysis that it sometimes forgets the problem itself. Causes matter — but only as the path to addressing the problem. The problem statement comes first.
The second framing principle Dan walked through is about whether your problem statement opens up multiple possibilities or forces you toward a single predetermined answer.
He listed three problem statements drawn from actual client work. "Our sales team needs more admin support." "We need a better marketing campaign to support our new artisanal coffee maker." "We never have enough time to close the books each quarter."
None of these are problems. They're solutions masquerading as problems. The only response to "we need more admin support" is to hire more admin staff. The only response to "we need a better marketing campaign" is to build a different marketing campaign. The only response to "we don't have enough time" is to find more time. The framing has already foreclosed all alternatives.
The reframe in each case opens up the question.
"Our sales team spends six hours a week on admin tasks" invites the question of which tasks could be eliminated, automated, redistributed, or redesigned. Hiring more admin staff is one option. Removing tasks that don't need to exist is another. Reassigning tasks to people whose work they actually belong to is a third. The reframed problem has at least four solution paths. The original framing had one.
"Our coffee maker sales are 30 percent of forecast" invites a wider conversation. Maybe the marketing is wrong. Maybe the price is wrong. Maybe the product itself isn't what customers want. Maybe the distribution is wrong. Maybe the forecast was unrealistic. The reframed problem requires investigation. The original framing skipped the investigation.
Dan's diagnostic for solution-disguised-as-problem statements is simple: if you hear phrases like "we don't have enough time," "we don't have enough money," "we don't have enough people," or "we need a better X" — that's sloppy thinking, and the framing is doing the work that analysis should be doing. Good problem statements describe the gap. They don't prescribe the remedy.
The third framing principle is specificity. "We have too much staff turnover" is a useless framing. "We have staff turnover of 38 percent in finance and 8 percent across the rest of the company" is a framing you can actually act on. The first invites generic responses about engagement and retention. The second narrows the question to something specific about finance — the leadership in that department, the work, the compensation, the culture, the manager. The investigation has a target.
The same applies to "sales are down" versus "sales are down 12 percent in the Northeast region for our entry-level product line." Same for "expenses are over budget" versus "we're $40,000 over budget on travel and marketing, primarily in Q2 trade show spending." The specific framing tells you where to look. The general framing produces general conversations that go nowhere.
Dan ran the first written exercise on the difference between two framings of the same general issue.
In 1971, Nixon declared a War on Drugs. The framing was war. The implied actors were enforcement — police, federal agents, courts, prisons. The implied countermeasures were criminalization, interdiction, incarceration. The implied target was drugs themselves and the people supplying them. The implied subject — the drug user — was an enemy combatant in a war being waged against a substance and its supply chain.
In 2017, the federal government declared a public health emergency for the opioid crisis. The framing was public health. The implied actors were medical — doctors, nurses, treatment centers, counselors, hospitals. The implied countermeasures were treatment, harm reduction, medication-assisted therapy. The implied target was the addiction itself and the conditions producing it. The implied subject — the person addicted — was a patient.
Same general issue. Same drugs in some cases (opioids fall in both framings). Radically different operational consequences.
The chat surfaced the implications quickly. War brings urgency and emotional charge. Public health brings empathy and a treatment frame. War criminalizes. Public health medicalizes. War mobilizes one set of resources (tanks, helmets, weapons, borders). Public health mobilizes a different set (clinics, counselors, prescribers). One participant — Adrian — captured what Dan thought was the sharpest version: the first framing makes drugs the focus, the second framing makes public health the focus. Whether you want to attack the drugs or help the people is decided by the framing, not by the analysis that follows.
The way the problem is framed determines the trajectory of every decision after it. The same is true at much smaller scales — in a department, in a project, in a single A3.
The second exercise was around a Wall Street Journal article published after the 2007 Niigata earthquake in Japan. The earthquake disrupted production at suppliers Toyota and other Japanese automakers depended on, and the article framed the resulting shutdowns as a failure of just-in-time inventory management. Mighty Toyota, the implied argument went, was brought to its knees by a short-term supply disruption. The remedy, by implication, was either to abandon just-in-time or to build up large inventory buffers as protection.
Dan walked the chat through the implied framing. The problem, as the journalist had implicitly defined it, was just-in-time itself. Just-in-time doesn't work. Look what happens when you depend on it.
The alternative framings open up substantially different responses.
If the problem is framed as "manufacturing shuts down when important parts are unavailable," then building safety stock of critical parts is one option among several. Other options include redesigning components so they're not single-sourced from one supplier. Standardizing piston rings or other parts across models so they're not specialized to a single platform. Distributing suppliers geographically so an earthquake in one region doesn't disrupt the global supply. Each of these is consistent with just-in-time. None of them requires abandoning the system.
If the problem is framed as "the current supply chain is not resilient," the conversation opens up further. Resilience can be built in many ways. Inventory is one. Component standardization is another. Supplier diversity is another. Reshoring or nearshoring is another. The framing accommodates all of these.
The journalist's framing — just-in-time is the problem — produced an article that pointed in one direction and one direction only. The reframe in either of Dan's alternatives produces a conversation that can lead in five or six directions, several of which are likely to be better than building up inventory.
Mark observed that the same framing pattern persists today. In early 2020, before the pandemic hit the US, the Wall Street Journal ran articles arguing that Chinese factory shutdowns were exposing the failure of just-in-time. The framing was wrong then for the same reason it was wrong in 2007. They thought they were doing just-in-time, Dan said, but if you're sourcing product halfway around the world, that isn't really just-in-time. That's just-in-time language applied to a system whose physical configuration is incompatible with the principle.
The point of the exercise isn't whether just-in-time works. It's that the framing of the problem determines the range of acceptable answers, and a framing that's too narrow forecloses better answers before they can be considered.
A question came in late in the session about why A3 thinking is so easy to mess up. Dan's answer addressed something most A3 training doesn't.
The trap starts, Dan said, with the downloadable A3 template that has boxes. The boxes are seductive. They invite you to fill them in literally and metaphorically. Once you're filling in boxes, you've already constrained your thinking to fit the format. You write smaller. You compress. You skip ideas that don't fit the available space. You let the form dictate the substance.
His preferred starting point is a blank piece of paper and a question: what story am I trying to tell? The A3 exists to make thinking visible. The form is the consequence of the thinking, not the structure that produces it. The story has a beginning (here's what's happening), a middle (here's what we found out about why), and an end (here's what we're going to do and how we'll know if it worked). When the story is clear, the format follows. When the format leads, the story gets sacrificed.
Mark added two related traps. The first is writing the A3 backwards from a pre-ordained solution. If you already know what you want to do, you're not doing A3 thinking. You're documenting a decision and using the form as cover. The second is treating the A3 as something you get right rather than something you iterate. The discipline is the willingness to go back to the problem statement and rewrite it once you've learned something the original statement didn't account for. War on Drugs becomes opioid public health emergency. The reframe isn't a failure. The reframe is the point.
A chat comment from Mark Jaben that Dan affirmed: messing up the A3 is a symptom; the underlying problem is moving thinking from solution-thinking to dilemma-thinking. Solution-thinking is system one — fast, automatic, pattern-matched. Dilemma-thinking is system two — slow, considered, comfortable with not knowing the answer yet. The A3 is the physical manifestation of whichever mode you're in. If the A3 reads as checklist-completed, the thinking was checklist-completed. The remedy isn't a better A3 template. It's a different orientation to the work.
Mike Dennison's comment at the end made a related point: when he teaches A3 work, he focuses on the learning gained from investigating the problem rather than on the solution itself. He uses the term "problem learning" rather than "problem solving" because solving implies driving toward a fix and learning implies understanding what's actually going on. Dan affirmed the framing. The conclusion trap is the trap of jumping to the conclusion. The discipline is to slow that jump down by placing speed bumps in the way — go and see, frame the problem, think backwards, ask why — so that you spend more time learning before you start solving.
A question came in about whether organizations should offer anonymous channels for employee feedback. Mark and Dan handled it together, and the answer was more nuanced than either a flat yes or a flat no.
The first move is the framing move. People being afraid to speak up isn't the same as people not currently speaking up. The first is a cause. The second is a fact. Anonymity is a countermeasure to a specific kind of fear. If the underlying issue is something else — if people aren't speaking up because they don't believe anything will happen when they do, or because they don't want to be assigned the resulting work, or because the speaking-up channels are too cumbersome — anonymity won't address it. The countermeasure has to match the cause.
For continuous improvement specifically, Mark's experience is that named participation works far better than anonymity in most cases. In a healthy improvement culture, people will attach their names to their ideas roughly 90 percent of the time, because the system has demonstrated that ideas get acted on and credit gets given. Anonymity is more appropriate for whistleblower situations and HR complaints than for daily improvement work.
Dan added a structural point. Anonymity hides the context that makes facts useful. If a problem is reported anonymously, you can't tell whether the reporter is on second shift, has been at the company three years, is new and untrained, or is operating in a specific facility with specific local conditions. The anonymity flattens the data and removes the texture that would let you understand what's actually going on. You end up with a thin version of the picture instead of the dimensional one.
The deeper observation is that if people are so afraid to attach their names that you need an anonymous channel to get any feedback at all, you have a cultural problem the anonymous channel won't fix. The channel becomes a workaround for the fear instead of a solution to it. Address the fear directly. The honest channels will follow.
The argument running through this session is that good decisions come from good thinking, and good thinking requires deliberate friction against the system-one defaults that produce most bad decisions. Go and see. Frame the problem. Think backwards. Ask why. These disciplines are human work that no software performs on a person's behalf.
What infrastructure does in this context is reduce the structural reasons that good thinking fails to spread. A3 work that lives in someone's notebook stays in that notebook. A3 work that's visible across a team can be reviewed, coached, and iterated. The discipline Dan emphasized — going back to reframe a problem statement once you've learned something the original statement didn't account for — depends on the A3 being editable, trackable across versions, and visible to coaches who can ask the questions that produce the reframe. None of those depend on software, strictly. All of them are made easier by software that's designed for the work rather than improvised in a tool built for something else.
The going-and-seeing discipline applies in the same way. The facts from the gemba are valuable in proportion to how visible they are to the people who need to act on them. A facility that goes and sees, names problems with specificity, and routes those problems into a system designed to track them and connect them to improvement work captures the learning. A facility that does the same observation work but lets the observations disappear into emails and meeting notes loses most of the value. The observation itself isn't the problem. The capture is.
The framing exercises Dan walked through have the same property. A team that gets better at framing problems doesn't just make better individual decisions — they create a body of well-framed problem statements that the next team can learn from. A framing like "our sales team spends six hours a week on admin tasks" is reusable. A framing like "we need more admin support" produces no useful trace, because the solution has already been embedded in the framing. The disciplined framings, captured over time, become a library of how to think about problems. That library is what infrastructure can hold. Spreadsheets and email cannot.
None of this changes what Dan was teaching. The discipline is the discipline. The thinking is the thinking. What infrastructure does is keep the thinking visible long enough that it can compound.
What are the three solution-traps Dan describes? Throw money at the problem (hire consultants, buy new computers, launch a training program). Reorganize (change the structure, shuffle reporting lines, move from functional to matrix or back again). Buy technology (new ERP, new software, new platform). All three feel decisive and produce visible action without requiring the leader to actually understand the problem first. The trap isn't that any of these responses is always wrong — it's that they get applied as defaults rather than as conclusions of analysis.
What's the difference between data and fact? Data is the numerical, two-dimensional representation of what's happening — the spreadsheet, the report, the dashboard. Fact is what you observe when you go to where the work actually happens. Data tells you that returns are running at a certain rate. Fact tells you that the order entry screens are laid out in a way that forces reps to tab across multiple fields out of sequence to enter a single order. Data is what you have at your desk. Fact is what you find at the crime scene.
Why is system one thinking a trap for problems that need system two? System one is fast, automatic, low-energy, pattern-matched. It's how humans have survived for 40,000 years, and it's the right system for most daily decisions. System two is slow, conscious, energy-expensive, and reserved for genuinely complex decisions. The trap is using system one for decisions that require system two — reaching for a familiar-feeling answer (an app, a reorganization, a training program) instead of doing the work to actually understand the problem. The cost isn't the wrong answer. It's the speed at which the wrong answer gets locked in before any alternative can be considered.
What does "go and see" actually mean in practice? Going to where the work happens, observing what's actually going on, and talking to the people doing the work. Not sitting in a conference room watching a presentation about the work. Not listening to one curated phone call from the highest-performing employee. Not flying in for a half-day visit and leaving with a thin understanding of what you've been shown. The practice requires being present long enough that people open up, asking questions you don't already know the answers to, and paying attention to whether the people you're talking to feel safe enough to actually tell you what they're seeing.
What's the difference between a symptom, a cause, and a problem? A symptom is what you observe — the fever, the lost sales, the absence of customers. A cause is what's producing the symptom — the infection, the marketing failure, the bad name. The problem is the operational gap that actually matters — the bacterial infection that needs treating, the $4,000 monthly loss, the disparity in outcomes. The Lean community is so well-trained on root cause analysis that it sometimes loses sight of which thing is the problem. Causes matter as paths to the problem, but the problem statement comes first.
Why are some problem statements actually solutions in disguise? Because they prescribe the remedy in the framing. "We need more admin support" is not a problem — it's a solution. The only possible response is to hire more admin staff. "Our sales team spends six hours a week on admin tasks" is a problem statement. The response could be hiring, eliminating tasks, redistributing tasks, redesigning the work, or several other paths. If you hear phrases like "we don't have enough time," "we don't have enough money," "we don't have enough people," or "we need a better X," the framing has foreclosed all alternatives and the analysis is being done by the framing rather than by actual investigation.
What does specificity do for a problem statement? It tells you where to look. "Sales are down" produces a general conversation that goes nowhere. "Sales are down 12 percent in the Northeast region for our entry-level product line" produces an investigation with a target. The specific framing narrows the question to something you can actually act on. The general framing produces general responses, which is to say nothing useful.
How does the War on Drugs framing differ from the opioid public health emergency framing? The first frames drugs as the focus and law enforcement as the actors. The second frames public health as the focus and medical professionals as the actors. The implied countermeasures are completely different — criminalization, interdiction, and incarceration versus treatment, harm reduction, and medication-assisted therapy. The same general issue, framed two different ways, produces two fundamentally different operational responses. The framing determines the range of acceptable answers before the analysis even begins.
Why was the Wall Street Journal's framing of just-in-time as the problem misleading? Because it foreclosed alternatives that don't require abandoning just-in-time. If the problem is framed as "manufacturing shuts down when critical parts are unavailable," the responses include building safety stock of critical parts, redesigning components so they're not single-sourced, standardizing parts across models, or distributing suppliers geographically. All of those are consistent with just-in-time. The journalist's framing pointed in one direction only — abandon the system or buffer it with inventory. The reframe accommodates several better answers. The same pattern repeated in early 2020 when supply chain disruptions from China were framed as just-in-time failures, when the actual issue was sourcing product halfway around the world while calling it just-in-time.
Why does Dan recommend starting an A3 with a blank piece of paper instead of a template? Because templates with boxes invite you to fill them in literally and metaphorically. Once you're filling boxes, you've constrained your thinking to fit the format. The A3 exists to make thinking visible, not to organize content into predetermined sections. Starting with a blank piece of paper and the question "what story am I trying to tell?" produces thinking that the format then follows, rather than format that the thinking has to conform to.
What is "problem learning" versus "problem solving"? Mike Dennison's framing from the Q&A. Problem solving implies driving toward a fix. Problem learning implies understanding what's actually going on. Dan affirmed the distinction. The conclusion trap is the trap of jumping to the conclusion — usually a solution — before doing the learning that would have produced a better conclusion. The discipline is to slow the jump down with deliberate friction (go and see, frame the problem, think backwards, ask why) so that more time goes into learning and less into solving.
Should improvement systems allow anonymous submissions? Sometimes, but rarely as a default. Anonymity hides context that makes facts useful — which shift, which facility, which role, which tenure. Anonymity also makes follow-up impossible, which limits the value of the input. For continuous improvement work specifically, named participation works far better in healthy cultures, with anonymity reserved for whistleblower situations and HR complaints. If an organization needs anonymous channels to get any feedback at all, the channel is a workaround for a cultural problem that the channel itself won't fix.
.svg)
Copyright © 2026
Privacy Policy