01 · Purpose and boundaries
Purpose and boundaries
Anti-solution brainstorming, also called reverse brainstorming in some settings, asks how a process could be made worse before reversing the answers into possible improvements. It is useful when ordinary discussion produces familiar advice or when participants can readily recognize failure mechanisms but struggle to invent remedies.
Define the desired outcome and its opposite precisely. “How could we ensure dispatch is delayed?” is more productive than “How can we ruin the company?” Keep the exercise hypothetical and process-focused. Never perform harmful actions to demonstrate an idea. The output is a set of failure hypotheses and corresponding countermeasures; it is not a complete risk assessment or evidence that the failures actually occur.
02 · How the method works
How the method works
Restate the operational objective and reverse it. Ask participants to generate process conditions that would reliably create the unwanted outcome. Encourage specificity: losing a replenishment signal is more useful than poor management. Defer evaluation during this stage while maintaining respectful boundaries.
For each anti-solution, identify the underlying mechanism. “Print labels in random piles” creates an identity-matching problem; “delay document requests until the truck arrives” creates late information dependency. Reverse the mechanism into one or more design options, such as one-parcel label flow or early document completeness checks. A literal opposite is not always the best solution.
Compare the hypothetical mechanisms with actual observations. Keep confirmed or plausible mechanisms separate from imaginative but unsupported ones. Apply safety, quality, and customer requirements to the candidate countermeasures. Develop and test selected ideas. Close the session with constructive actions so cynical language does not become the lasting message.
03 · Worked logistics example
Worked logistics example
Fictional MarshLink dispatches 300 orders per day, with 36 late to the carrier cutoff. The reverse question is “What operating rules would maximize missed cutoffs?” Participants suggest releasing incomplete orders, changing priorities every ten minutes, hiding queue age, and assigning every urgent order the same status.
Observation supports two mechanisms: 18 late orders wait for missing documents, and 10 lose time through repeated priority changes. Eight are affected by other causes. The team translates these into a document-readiness gate and a governed priority rule with an accountable exception owner. It does not adopt the literal opposite “never change priorities,” because legitimate customer emergencies still exist.
A five-day pilot processes 1,500 orders. Document-related late cases fall from an expected 90 to 35, and priority-related late cases from 50 to 25. The other category records 42 compared with an expected 40. The overall late count becomes 102 instead of the baseline expectation of 180, while the team checks that readiness holds do not simply conceal customer delay before release.
04 · Interpretation and decisions
Interpretation and decisions
The reversal exercise revealed testable mechanisms. It did not prove them; observation and the pilot provided the evidence. The illustrative overall reduction is 78 late orders over five days, about 43%. Investigate the slightly higher other-cause count and compare mix and volume before generalizing.
A readiness gate can improve internal flow while increasing time outside the process. Include total customer lead time and backlog age. A stable priority rule should still permit clearly authorized exceptions. Interpret the anti-solution as a causal prompt, not a moral accusation or a recommendation for rigid behavior.
05 · Common misapplications
Common misapplications
The method can turn into sarcasm about colleagues. The facilitator must redirect statements toward process conditions and decisions. “Hire bad people” yields little design insight; “provide no approved instructions for changed products” identifies a controllable mechanism.
Do not implement an anti-solution, disclose sensitive vulnerabilities unnecessarily, or confuse imaginative failure stories with measured causes. Mechanical reversal can also fail: the opposite of inspection is not necessarily eliminating inspection, and the opposite of excess stock is not zero stock. Translate the failure mechanism into a context-appropriate control. Formal safety and risk reviews remain necessary where required.
06 · Advanced adaptation
Advanced adaptation
Combine reversal with process-state analysis. Ask how each handoff could lose identity, timing, quantity, or authority, then develop safeguards for these dimensions. This can reveal interface failures missed by an activity-focused discussion.
Use positive framing during implementation: explain the desired rule and its rationale rather than preserving the negative slogan. For service workflows, imagine how a request could become invisible, duplicated, or prematurely closed, then examine ownership and status controls. Retain the distinction between actual evidence and hypothetical failure paths, and revisit assumptions when process conditions change.
Document the positive design rationale so future teams understand why a control exists. Otherwise a safeguard may later be removed as apparent bureaucracy, recreating the failure mechanism that prompted its introduction.
07 · Implementing and sustaining the change
Implementing and sustaining the change
Introduce anti-solution brainstorming within a clearly named operating boundary. Identify the product family, shift, equipment, and handoffs affected; record what happens immediately before and after that boundary. A change that improves one task while exporting its delay to another department has not established an improvement. Agree who can stop the trial, who handles exceptions, and which customer commitment takes priority when the normal rule cannot be followed.
Establish a baseline from actual work rather than a single demonstration. Include normal variation in order mix, replenishment timing, staffing, and workload. Keep the denominator visible: minutes per order, defects per shipment, or completed lines per available hour answer different questions. Record the workload and conditions alongside each observation so that a quiet trial period cannot masquerade as better performance. Observe the process with the people who do it; their explanation of interruptions often changes the proposed design.
Start with a reversible pilot large enough to expose handoff problems. Explain the expected mechanism before launch: which action changes, which delay or failure it removes, and which result should respond. Train all affected shifts and support roles using the same operating definition. During the pilot, capture exceptions as information about the design. Do not conceal them through unofficial stock, unrecorded overtime, or a specialist who quietly repairs every failure.
Review customer service, safety, quality, work content, and inventory together. A faster average with more severe late orders may be unacceptable; a lower inventory level with repeated emergency deliveries may have displaced the cost. Investigate variation before declaring success. If the expected mechanism does not appear, revise the design or return to the baseline rather than defending the idea. A promising observation is a reason to test more conditions, not proof that every operating context will behave identically.
After a successful trial, make the new rule part of daily work. Give an accountable owner responsibility for the operating standard, change control, training, and periodic review. Specify the abnormal condition that requires escalation and the person who responds. Check whether the improvement remains effective when a trained colleague is absent or demand changes. Sustain the mechanism through routine management and learning; documentation is useful only when it describes the process people actually follow.
Connections
Related methods and phase use
Placed under Improve because of the outcome it supports. Use the method in other phases when its purpose and assumptions fit the work; the phase list is a guide to selection, not a compulsory sequence.
Sources
Professional foundations and further reading
The explanation and fictional teaching examples are written for LeanTrainingLab. Linked primary sources provide professional foundations; example values and local conventions are stated in the guide. The accepted toolset draws on Six Sigma+Lean Toolset, second edition (Lunau, editor; Springer, 2013). No book text or examples are reproduced here.