Driving Eureka!

1. 1Before generating ideas, run Stimulus Mining across the six areas (Wisdom, Patent, Market, Insight, Future, Unrelated) so your diverse group has fresh raw material to react to — diversity fuels the reaction, but stimulus sparks it.
2. 2Map who can help you think smarter on this specific challenge: identify people inside AND outside your organization with different perspectives, since the source passage states someone in each domain exists for any challenge.
3. 3Actively ask for help and solicit advice — treat this as the hardest discipline, because research on 12,000+ managers shows 95% of companies don't collaborate well.
4. 4Structure the session so people share ideas rather than compete: use a collaboration mechanism (like the Collaboration Cafe digital suggestion box) that gets more people sharing more ideas and advice.
5. 5Listen to the advice and be genuinely willing to change your mind — the passage names this as one of the greatest challenges of the new mindset.
6. 6After raw ideas are generated, define, edit, and evaluate them, then count how many Meaningfully Unique ideas survive — this is the metric that proves diversity's multiplicative effect.
7. 7Pair diversity with driving out fear (define the whole idea + run PDSA cycles), because diverse ideas only come alive in proportion to how much fear you remove.

A new product team faced two regulatory barriers that blocked scaling up test products — barriers they couldn't change because rule changes would take a multinational company years. Rather than compromise or give up on a product both customers and the team loved (high Meaningful Uniqueness scores), the team leveraged diverse thinking in a problem-solving session that produced a dozen theories on how to address the problem. They ran Fail FAST, Fail CHEAP (Plan, Do, Study, Act) experiments against those theories. Within a week they had identified a new raw material and a new patentable production method that overcame both regulatory issues. The result was a product preferred versus the original. This shows diversity of thinking generating many candidate solutions, then fear-reduction (PDSA experimentation replacing declare-and-defend) letting the best survive.

• If you're stuck on a challenge, then assume someone inside or outside your organization can help and go find them — never treat it as a solo problem.
• If your team is competing for individual credit rather than helping each other win, then you have a collaboration failure (like a poor sports team) and diversity will not multiply your output.
• If you're defending your position instead of curious to discover, then you're operating in 'declare and defend' — switch to PDSA and let data settle it.
• If someone offers advice that contradicts your view, then treat willingness to change your mind as the win, not as losing the argument.
• If a session has low diversity of thinking, then expect roughly half the surviving Meaningfully Unique ideas (18 vs 46 in the research) and deliberately widen the perspectives before proceeding.

• Solo hero mode — believing you must solve it yourself; the tell is you never ask anyone inside or outside the org for help.
• Fake collaboration — people are in the room but focused on individual achievement; the tell is players optimizing personal wins instead of the team winning, matching the 95% of companies that don't collaborate well.
• Asking for advice but not listening or changing your mind; the tell is you keep defending your original idea after hearing diverse input.
• Generating diverse ideas in a high-fear environment; the tell is big ideas dry up (research: high-fear groups yield fewer Meaningfully Unique ideas) because good ideas only come alive as fear is driven out.
• Relying on extrinsic contest mechanics (suggestion box with a prize) to spur sharing; the tell is participation spikes once or twice then dies because only one or two ever win and the purpose becomes the prize, not pride of work.

• ▸Challenge statement: write the specific problem or opportunity in one sentence.
• ▸Internal perspectives to recruit: name 3+ people from different functions who see this differently.
• ▸External perspectives to recruit: name 2+ people/sources outside the org who can help you think smarter.
• ▸Stimulus feeding the group: list which of the six Stimulus Mining areas you drew from.
• ▸Advice received / mind-changed: log the input that made you change your view.
• ▸Fear-reduction step: note the whole-idea definition or PDSA experiment used to make the unknown known.
• ▸Meaningfully Unique ideas surviving: count ideas remaining after define/edit/evaluate.
• ▸Diversity level (High/Medium/Low): self-rate against the research benchmark (High=46, Med=30, Low=18).
• ▸Next action: the one PDSA experiment (1 hour to 7 days) you'll run next.

1. 1Make the unknown known first. Before asking people to create, define the system on paper: its aim, boundaries, stakeholders, and the one-system metric. Fear feeds on ambiguity, so removing ambiguity removes the first source of fear.
2. 2Separate creation from evaluation. Run Create sessions where judgment is suspended entirely. Instruct participants to only create, create, create — no critiquing any idea in the first pass — so no one withholds ideas for fear of being shut down.
3. 3Have senior leaders go first with a deliberately 'stupid' idea early in the session. This stretches the psychological safety zone, so others reason 'at least my idea isn't as dumb as what the CEO said' and speak up.
4. 4Reward with 'thunderous applause' every time someone shares with the group. This builds positive momentum where all ideas — good or bad — act as stimuli for more ideas, creating a chain reaction of positives.
5. 5Switch from extrinsic to intrinsic motivation. Kill contest-and-prize mechanics (the suggestion box with a prize) and instead connect the work to purpose, pride, and personal engagement — 'Cool Sh*t That Matters!' — because intrinsic motivation lasts and extrinsic fades after one or two rounds.
6. 6Push for volume before selection. Challenge the team to create many ideas first, then pick the best, because quantity creates quality — the more ideas, the more connections to bigger ideas.
7. 7Convert fear into learning with disciplined Plan-Do-Study-Act cycles. Frame every attempt as an experiment, so a 'bad' idea becomes data rather than a failure — making rapid, low-cost cycles the mechanism that makes the unknown known.
8. 8Diagnose negative psychology explicitly as Step 3 of system improvement: identify which parts of the system demotivate people, then take an action to remove that negative psychological force.

In a Create session, two kinds of teams appear. One team follows the instruction to suspend judgment and generate a large quantity of ideas before choosing; the other tries to shortcut straight to 'the one big idea,' thinking it's faster. Every time the author remembers, the best ideas come from the team that created many ideas first. This mirrors Dean Keith Simonton's study of 2,036 scientists: the most respected scientists produced not only more great works but also more bad ones — they simply produced. The lesson for driving out fear is operational: when you don't fear producing bad ideas, you produce more of everything, and the initial ideas act as stimuli that connect to bigger ones. The mechanism that makes this safe is separating creation from evaluation, so no idea gets shot down in the moment and the chain reaction of positives keeps going.

• If people stop volunteering ideas, then you are evaluating too early — split creation and evaluation into separate passes.
• If you're relying on a prize or contest to spark ideas, then expect participation to die after one or two rounds — replace it with intrinsic purpose and pride.
• If a session feels psychologically tense, then have the most senior person share a crazy or 'stupid' idea first to widen the safety zone.
• If the team wants to jump straight to the single big answer, then require a high quantity of ideas first, because quantity creates quality.
• If a problem recurs, then assume it's the system (94%) not the worker (6%) — fix the system rather than blame or intimidate people.

• Creating and evaluating in one pass. Tell: ideas get shot down as they're spoken, and soon people go quiet and withhold fresh ideas for fear of being shut down.
• Using extrinsic motivators — bribes or intimidation to force creativity. Tell: participation spikes then collapses, and only one or two people ever 'win,' so the purpose becomes the prize, not the work.
• Leaders staying safe and conventional in Create sessions. Tell: no one else risks a bold idea because the psychological safety zone was never stretched.
• Blaming workers for problems. Tell: repeated errors get pinned on individuals when 94% belong to the system that management controls — fear rises and improvement stalls.
• Hunting for the single big idea. Tell: the team produces few ideas, fewer connections, and weaker results than teams that generated volume first.

• ▸System aim: state the purpose this session serves in one sentence.
• ▸One-system metric: name the primary output you're trying to improve.
• ▸Suspend-judgment rule: write the phrase you'll use to separate create from evaluate.
• ▸Leader's 'stupid' idea: draft the deliberately crazy idea the senior person opens with.
• ▸Applause cue: define how the group acknowledges every shared idea (e.g., thunderous applause).
• ▸Intrinsic hook: state why this matters to participants personally (Cool Sh*t That Matters!).
• ▸Quantity target: set the number of ideas to generate before any selection.
• ▸PDSA next step: name the smallest Plan-Do-Study-Act experiment to test the top idea.
• ▸Negative psychology to remove: identify one demotivating force in the current system to eliminate.

1. 1Make the human system visible before touching motivation: map who works on innovation projects and how they interact with the work, so you can locate where drive is being killed rather than guessing.
2. 2Identify areas of negative psychology in that system — points where people are intimidated into innovating or bribed to think creatively. These are the demotivators to remove first.
3. 3Strip out extrinsic motivators masquerading as encouragement: suggestion-box prizes, contests, and metric-based rewards. They work once or twice, then participation dies because the purpose becomes the prize, not the pride.
4. 4Install the three levels of meaningfulness as the gate for what gets worked on: meaningful to the customer, meaningful to the company (profitable and aligned to leadership's vision), and — the level most skip — meaningful to the workers doing it.
5. 5Test worker-level meaningfulness directly by asking whether the person loves the idea enough to see it from idea to reality. If they don't want to make the change happen themselves, do not proceed on drive alone — you cannot bribe them into it.
6. 6Convert metrics from motivators into system-improvement tools. Use the two Innovation Engineering measures (weighted pipeline value; percent proactive vs. reactive work) to diagnose the system, never to reward or punish individuals.
7. 7When someone shows genuine internal belief in a struggling project, give them a bounded, low-risk window to act on it (a weekend, a small-scale test) rather than killing it on the metric alone.
8. 8Run improvements as Deming PDSA / 'Fail FAST, Fail CHEAP' cycles: take one action to remove a demotivator, study the result, and repeat — so intrinsic drive is protected by fast, cheap learning instead of high-stakes bets.

On a new product for a major beverage company, hundreds of consumers tasted three final test-market options. Two did well; the third failed, and the obvious call was to kill it. But the product developer said, 'I really believe in the product that failed. And I think I know how to fix it. Could I have the weekend to work on it?' On Monday she reported it was fixed and could be perfected by week's end for small-scale production. With three options — delay and retest, drop it, or trust her — the low risk of a small-scale test market made trust the right call. Her response, 'I won't let you down. It will be great,' was internal drive, not an incentive. In market, her product had nearly twice the repeat purchase rate of the other two — the direct payoff of intrinsic motivation being given room to act.

• If a person loves the idea and wants to make the change happen themselves, then back them with a bounded, low-risk window; if they only comply for a reward, then expect it to stall through the inevitable ups and downs.
• If you're using a metric to motivate rather than to improve the system, then stop — metrics used to motivate are destructive and ignite gaming; metrics are the outcome of the system, not the lever.
• If an idea is meaningful to customer and company but not to the workers, then it lacks the energy to become real, no matter how profitable — do not force it.
• If a motivation tactic is intimidation or bribery, then assume it works only short-term; if it's purpose, pride, or personal engagement, then it's durable enough to survive setbacks.
• If a contest or suggestion-box prize is driving participation, then watch for the drop-off after one or two rounds and replace the prize with pride of work before it dies.

• Inspecting quality into innovation: reviewing projects more frequently and diligently to force success. The tell is added review meetings and metrics with no change to the methods and tools — stress rises, drive falls.
• Rewarding people for hitting the numbers. The tell is 'gaming' the system — numbers improve while the underlying work doesn't, and fear increases.
• Dressing up an old product with a new 'skin' and expecting different results — like the Alliance Carriage Company pouring energy into design and a direct-sale brochure while rejecting the motor. The tell is investment in framing and marketing instead of in the substance; the internet exposes the smoke and mirrors fast.
• Treating the customer/company case as sufficient and skipping worker meaningfulness. The tell is a well-justified project that nobody on the team actually wants to see through, so it drags.
• Killing a struggling project on the metric alone while ignoring a developer's genuine belief. The tell is a fast 'obvious' kill decision made before anyone with internal conviction is given a low-risk window to act.

• ▸Project / idea name — the innovation being evaluated.
• ▸Meaningful to customer? — one sentence on the specific benefit to them.
• ▸Meaningful to company? — can you profitably develop/produce/deliver it, and is it aligned to leadership's vision?
• ▸Meaningful to workers? — name who wants to make this happen themselves and why they love it.
• ▸Extrinsic tactics in play — list any prizes, contests, or number-rewards to remove.
• ▸Negative psychology to remove — the specific demotivator (intimidation, bribery, fear) blocking this work.
• ▸Low-risk window offered — the bounded time/scale test given to the believer (e.g., a weekend, small-scale test market).
• ▸System measure, not motivator — how this feeds pipeline weighted value or proactive-vs-reactive percentage.
• ▸Next PDSA cycle — the one Fail FAST, Fail CHEAP action to test and study next.

1. 1Name the Death Threats first. Before running any cycle, list the specific assumptions that, if false, kill the idea — feasibility challenges you must confront openly rather than ignore. Tag each as a Death Threat.
2. 2Rank Death Threats by risk and pick the one to resolve now. Cycles exist to reduce uncertainty on the highest-stakes unknown, not to polish what already works.
3. 3Design the smallest, fastest experiment that could disprove the assumption (Fail FAST, Fail CHEAP). Ask: what is the least time and money that produces a real answer? Redesign the system if the cycle is too slow — as P&G did, cutting a three-month cycle to seven days.
4. 4Run PLAN: write down the assumption, the prediction, the test method, and what result would count as pass or fail. Documentation is not optional — it is what makes the learning transferable and the process reproducible.
5. 5Run DO: execute the test exactly as planned, in the real world, gathering data rather than opinion so decisions rest on evidence, not corporate politics.
6. 6Run STUDY: compare actual results against your prediction — this is where real learning is amplified. Separate special cause from common cause: was the outcome a system pattern or a one-off?
7. 7Run ACT: decide to persevere, pivot, or kill based on the data. Update your Death Threat list, then start the next cycle on the next-biggest unknown.
8. 8Keep cycling until the Death Threats are resolved or the idea is honestly killed cheaply. Speed of learning, not volume of activity, is the scoreboard.

At Procter & Gamble, Doug Hall and Eric Schulz inherited a failing food & beverage innovation group and started by learning everything they could — interviewing experts, reading academic articles, running experiments. They quickly saw a system problem: a single learning cycle (concept, package, customer research, analysis) took three months, so they could only complete four cycles a year. Rather than accept that pace, they changed the system, inventing 'Rapid Test,' which created, tested, and reported results from four cities in seven days. That collapse in cycle time meant they could resolve uncertainty and confront feasibility on ideas far faster. A finance audit later compared their projects to similar-complexity ones and found the P&G Invention Team took products to market with dramatically less time. The lesson: when cycles are too slow, you don't run more of them — you re-engineer the system so each cycle is faster and cheaper.

• If an assumption would kill the idea when false, then tag it a Death Threat and test it before anything else.
• If a learning cycle takes months, then change the system to shorten it rather than accepting only a few cycles per year.
• If the STUDY result contradicts your prediction, then treat it as learning to act on, not a failure to hide — 'I will never apologize for learning.'
• If an error is common cause (a system pattern), then fix the system; if it's special cause (a one-off), then address that specific instance — don't blame the workers for a system fault.
• If a decision is being driven by corporate politics rather than data, then stop and run a cycle to generate evidence.

• Ignoring feasibility challenges instead of tagging them as Death Threats — the tell is a plan with no listed risks and lots of optimism.
• Running slow, expensive cycles and blaming the idea when only four fit in a year — the tell is 'we don't have time to test' while the cycle itself is never re-engineered.
• Skipping the STUDY step: acting on gut after DO, so no real learning accumulates — the tell is repeated activity with no documented comparison of prediction versus actual.
• Not documenting cycles, so learning stays in one person's head and can't be reproduced or transferred — the tell is decisions no one can trace back to evidence.
• Confusing special cause and common cause, then blaming workers for what is actually a system failure — the tell is punishing people while the same error keeps recurring.

• ▸Death Threat: the assumption that kills the idea if false
• ▸Risk rank: why this is the one to test now
• ▸Prediction: what you expect to happen and the pass/fail line
• ▸Test design (FAST/CHEAP): least time and money to get a real answer
• ▸DO log: what you actually did and the data collected
• ▸STUDY: actual vs. predicted; special cause or common cause?
• ▸ACT: persevere, pivot, or kill — and why
• ▸Next Death Threat: the unknown this cycle exposes to test next

1. 1Split every idea evaluation into two independent axes: Meaningful (obvious value customers pay time, energy, and money for) and Unique (a nonobvious, patentable leap). Score each separately before you combine them.
2. 2Source stimuli for both brains: pull right-brain trends and customer insights to find meaning, and pull left-brain technologies and existing patents to find the nonobvious leap. Weak ideas usually starve on one axis.
3. 3Write the value as a specific customer benefit, then test it against 'if you're not meaningfully unique, you'd better be cheap' — if the only reason to buy is price, the meaning is missing.
4. 4Attack feasibility head-on: tag the biggest unresolved risks as 'Death Threats' and resolve them through disciplined, documented Fail FAST, Fail CHEAP cycles of learning rather than ignoring them.
5. 5Prove uniqueness in the market, not the boardroom: run head-to-head tests against the incumbent standard and demand a decisive win margin before scaling.
6. 6Engage the 85% of left-brain logical thinkers by grounding decisions in data (math and writing), not corporate politics — without them, engineering, finance, production, and operations never make the idea real.
7. 7Compress the calendar: drive from invention through development to test market in months, using each Fail FAST cycle to retire risk quickly.

Brain Brew Custom Whisk(e)y is the passages' clearest case. The meaningful side: 'the world doesn't need another whiskey, but everyone needs their own whiskey' — a specific, payable benefit for forward-thinking craft enthusiasts who want their own mash bill and aging style. The unique side: a patented Time Compression technology that crafts whiskies and bourbons in 40 minutes instead of years or decades — a nonobvious, patentable leap, not a flavor tweak. Uniqueness was proven head-to-head: the products win 2-to-1 and 3-to-1 against luxury scotches and bourbons in taste tests, and won double gold medals at the North American and San Francisco World Spirits competitions. The team confronted feasibility directly and moved from invention to test market in 10 months, winning top international honors in 18. They also accepted that traditionalists would resist, and deliberately targeted taste-over-tradition buyers instead of trying to please everyone.

• If an idea is meaningful but not unique, then expect to compete on price — 'you'd better be cheap' — so either add a nonobvious leap or drop it.
• If an idea is unique but not obviously meaningful (no customer will pay time, energy, or money), then it is a novelty, not an innovation — kill or reframe it.
• If a major feasibility risk exists, then tag it a Death Threat and resolve it in a Fail FAST, Fail CHEAP cycle before spending on development.
• If the concept can't win a head-to-head test against the current standard, then you have not yet earned the 'unique' claim.
• If traditionalists resist but your forward-thinking target audience is served, then proceed — accept 'some call us the crazy ones' rather than diluting the leap for everyone.

• Chasing uniqueness alone: building a clever, patentable thing no customer will pay for. Tell — you can describe the technology but not the specific benefit someone buys.
• Chasing meaning alone: a valuable but obvious offering with no leap. Tell — competitors can copy it and the only differentiator left is price.
• Ignoring feasibility to protect the excitement. Tell — known 'Death Threats' go undocumented and resurface late as expensive surprises.
• Running a right-brain-only process that alienates the 85% logical thinkers. Tell — engineering, finance, and operations disengage or become active resisters and the idea never becomes real.
• Deciding by corporate politics instead of data. Tell — the winning concept is the loudest person's favorite, not the one that wins the taste test or the numbers.

• ▸Offering / idea name: one line naming the product, service, or system
• ▸Meaningful benefit: the specific value a customer pays time, energy, or money for
• ▸Meaningful score (1-10): how obvious and payable is that value
• ▸Unique leap: the nonobvious, patentable difference vs. today's standard
• ▸Unique score (1-10): how nonobvious and defensible is the leap
• ▸Head-to-head proof: the test/result showing you beat the incumbent (or 'not yet run')
• ▸Death Threats: the top feasibility risks that must be resolved
• ▸Fail FAST plan: the fast, cheap experiment to retire the biggest risk
• ▸Target audience: who you serve even if traditionalists resist

1. 1Set the strategic aim at the top first: define where the whole organization is innovating before any department, division, or team optimizes its own area — the outcome of the whole system drives the properties of the parts, not the reverse.
2. 2Shift innovation from the job of a small group of gurus to a system that enables innovation by everyone, everywhere, every day — this is the only mechanism that produces the combined speed-and-risk result rather than one at the expense of the other.
3. 3Refuse the two easy traps: do not accelerate projects while ignoring risk, and do not slow everything to never-ending analysis. Engineer both simultaneously by changing how you think, lead, and work.
4. 4Start each new idea with a Fermi Estimate: build a first estimate from component drivers (e.g., customers per night x amount paid per customer for food + amount paid per customer for alcohol), accepting high variance as a starting point.
5. 5Quantify uncertainty on each estimate by taking the standard deviation divided by the best estimate, then use red/yellow/green stoplight coloring to locate where the greatest risk sits.
6. 6Run Plan-Do-Study-Act cycles on the highest-variance element first, reducing variation with Stimulus Mining, calibration against known examples, and Rapid Research Tests.
7. 7For advanced risk reduction, use Trailblazer delphi to estimate unknowns and risk-adjusted Monte Carlo simulation to run the innovation into the market 10,000 times, reading off the probability of hitting each sales or savings level.
8. 8Document each proven element in an operational manual so the process is reliable and reproducible; teach students to execute exactly as taught first, then improve the method once they gain confidence.

Doug Hall's father worked a carbonless-paper quality problem that became one of Dr. Deming and Bill Conway's early case studies of system thinking. The plant's coating pH and temperature were stable, but the viscosity of the toner supplied in each drum varied wildly, causing 'skips' and poor quality. No amount of beating, bribing, or inspecting the workers fixed it, because the variance was built into the system — the worker's output quality was controlled by the viscosity of each barrel poured into the coater. Rather than pressuring the frontline, his father worked with the toner supplier to control viscosity upstream. With viscosity stabilized, the company could reduce the amount of toner applied, producing a savings of $750,000 in 1980 dollars. The lesson: the system, not the worker, was perfectly designed to get the results it got — change the system and both quality and cost improve at once.

• If you got speed by accelerating projects without regard to risk, then you have not achieved the outcome — the goal is the combination of increased speed (up to 6x) and decreased risk (up to 80%).
• If departments are creating their own visions for optimizing their areas, then the strategic aim at the top is missing — set the aim for the whole system first.
• If your innovation success rate sits at the industry norm of 5–15%, then you have worse odds than a Las Vegas roulette table (47%) and should suspect the system, not the people.
• If a stoplight shows red on an estimated input, then focus your Plan-Do-Study-Act energy there for the greatest reduction in risk.
• If you are pressuring, bribing, or inspecting frontline workers to fix quality, then stop — every system is perfectly designed to get the results it gets, so change the upstream system input.

• Optimizing parts before the whole: defining departments and teams first and deriving the whole from them. The tell is each area has its own vision because no top-level strategic aim exists.
• Treating innovation as the job of a few 'gurus.' The tell is that speed and risk gains stay small and don't compound — contrast Sumitomo, whose gains grew exponentially only after enabling everyone from the top down to foremen.
• Chasing one metric alone: reducing risk by subjecting everything to never-ending analysis, or gaining speed while ignoring risk. The tell is one number improves while the other degrades.
• Blaming the worker for variance built into the system. The tell is repeated inspection and pressure with no quality improvement, as in the carbonless-paper case.
• Treating first estimates as final. The tell is acting on a Fermi Estimate's high-variance number without running PDSA cycles to reduce variation on the riskiest input.

• ▸Strategic aim (whole system): state where the organization is innovating before naming any part.
• ▸Innovation idea: name the product, service, or way of working being estimated.
• ▸Component drivers: list the inputs that build the first estimate (e.g., customers/night, paid per customer).
• ▸Best estimate per driver: enter your single best-guess value for each input.
• ▸Uncertainty per driver: enter standard deviation ÷ best estimate to quantify variance.
• ▸Stoplight rating: mark each driver red/yellow/green by where the greatest risk sits.
• ▸Highest-risk focus: name the red/yellow driver to attack first with PDSA.
• ▸Variation-reduction method: pick Stimulus Mining, calibration, or Rapid Research Test for that driver.
• ▸Speed & risk target: state the intended gain (toward 6x speed / up to 80% risk reduction) and how you'll verify both.

1. 1Measure your current culture with the Innovation Engineering culture metric: track what percent of employees' time is spent on proactive (discovering and developing ideas) versus reactive (firefighting, rework) work. Reactive-heavy time signals no culture yet.
2. 2Set the target at the 10% tipping point: build UNSHAKABLE belief in the ability to innovate in at least 10% of your team, company, or community. You do not need everyone at once — you need a committed minority who cannot be argued out of it.
3. 3Build innovation into work systems and tools rather than relying on inspection or special people. Deploy scalable education (the Create, Communicate, Commercialize systems) so innovation becomes the mission of everyone, everywhere, every day.
4. 4Engage both brain styles deliberately: give the 15% right-brainers a system to turn ideas into reality, and win the 85% left-brainers with structure, clarity, and discipline. Use idea-sparking stimuli that combine right-brain trends/insights with left-brain technologies/patents.
5. 5Ground decisions in data, not corporate politics. Tag feasibility risks as 'Death Threats' and resolve them through disciplined, documented Fail FAST, Fail CHEAP cycles instead of ignoring them.
6. 6Protect intrinsic motivation. Use metrics to improve the system, never to motivate or reward hitting numbers — extrinsic bribery and 'beating of workers' increases fear and kills the passion innovators need to survive the ups and downs.
7. 7Track the pipeline: maintain the weighted value of the innovation pipeline, with each project aligned to a strategic priority (Blue Card) and weighted by its development stage versus historical norms.
8. 8Convert naysayers by teaching, not fighting. Treat them as people who simply don't yet understand that innovation can be a reliable science — 'How could they know there was any other way?'

Consider the failure of the classic command-and-control system under accelerating change. When innovation is run as a department led by specialists, the world moves faster than the meetings, communications, miscommunications, and rework the silo system generates. The passages prescribe replacing this with a culture where innovation is everyone's mission daily, amplified by scalable education and tools — 'just as a tractor amplifies the amount of land a farmer can work versus with a horse and plow.' John Muldoon, an Innovation Engineering Black Belt at the Edrington Group in Scotland, framed the determining factor as 'having a leader and a team that have the courage to determine their own future, not becoming a victim of someone else's future.' The mechanism is the 10% tipping point: once one in ten people hold unshakable belief in their ability to innovate, the culture takes hold. This is why cost cutting, working harder, and beating the workers all fail — the only sustainable answer to the accelerated pace of change is a culture of innovation.

• If a metric is being used to motivate or reward people, then stop — use it only to improve the system; otherwise you ignite gaming and fear.
• If you have unshakable belief in fewer than 10% of the group, then you do not yet have a culture — keep building the committed minority before expecting self-sustaining change.
• If a feasibility problem is being ignored or worked around, then name it a 'Death Threat' and resolve it with a documented Fail FAST, Fail CHEAP learning cycle.
• If someone resists the system, then treat them as not-yet-understanding (people are fundamentally good) rather than as an enemy of change.
• If time is spent mostly on reactive firefighting and rework, then the culture measure is failing regardless of how busy the team looks.

• Trying to inspect quality into innovation — reviewing development more frequently. The tell: more gates and reviews, but no change in the underlying work system or tools.
• Managing by metrics and rewards to 'hit the numbers.' The tell: people gaming the system, rising stress, and short-term number-hitting without sustained improvement.
• Leaving innovation to a department, specialists, or 'special people' waiting for the light bulb. The tell: innovation described as luck or serendipity, and a backlog of meetings and rework.
• Amplifying risk-avoidance as the market speeds up. The tell: infrastructure 100% focused on decreasing risk, silos rewarded over the organization.
• Engaging only one brain style — all right-brain ideation with no execution system, or all left-brain structure with no fresh ideas. The tell: right-brainers frustrated their ideas die; left-brainers disengaged for lack of structure.

• ▸Group scope: name the team, company, or community you are shifting.
• ▸Proactive vs. reactive %: current share of time spent discovering/developing ideas vs. firefighting.
• ▸Unshakable-belief count: number and % of people with unshakable belief in their ability to innovate (target ≥10%).
• ▸Death Threats logged: list feasibility risks named and their Fail FAST/Fail CHEAP resolution status.
• ▸Pipeline weighted value: total value of projects, weighted by development stage vs. historical norms.
• ▸Blue Card alignment: confirm each project maps to a strategic priority.
• ▸Metric use check: state that each metric improves the system, not motivates people.
• ▸Whole-brain engagement: note how right-brain (15%) and left-brain (85%) are each being served.
• ▸Naysayer plan: who resists and the teaching step to help them understand.

1. 1State the aim first: write a single Constancy of Purpose that names the Meaningful Difference the system exists to deliver, so everyone knows why and where to innovate.
2. 2Reclassify every problem before you assign blame: sort each into Common Cause (systemic, 94%, management's job) or Special Cause (random/fleeting, 6%, employee's job). Default to systemic unless evidence proves otherwise.
3. 3When a problem is Common Cause, direct improvement effort at the system — the training, tools, and leadership coaching — not at the person who was inside the failing system.
4. 4Choose Enable over Control: instead of micromanagement, direct supervision, and overexerted influence, give workers authority to change plus the training, tools, and coaching that make innovating practical, possible, and easy.
5. 5Give people the three prerequisites empowerment alone cannot supply: where to innovate, why to innovate, and how to innovate — authority without these produces no impact.
6. 6Upgrade the existing culture rather than spinning off isolated teams; work with the current leadership and employees so improvements can access shared resources without civil war.
7. 7Protect pride in work: hold to the principle that no one is blamed or penalized for performance they cannot govern, because a bad system beats a good person every time.
8. 8Model 'I will never apologize for learning' — revise the system when evidence changes, and keep at least 10% of the team building UNSHAKABLE belief in their ability to innovate.

The passages contrast two paths using Lockheed's Skunk Works. Skunk Works succeeded because it operated 100% outside the organization — idea through production to sales — as a freestanding business selling to one customer, the military. Doug Hall was for decades a vigorous advocate and coached hundreds of such teams. But he concluded his mindset was wrong: Skunk Works generates the perception of success only because it spends its time on the innovation instead of on the system. Eventually the success vaporizes when the new innovation must access resources inside the parent, triggering an open or passive-aggressive civil war. The system-driven alternative is to upgrade the existing culture by enabling leadership and employees — the only sustainable, reliable path to a never-ending stream of innovations.

• If a problem recurs across people and conditions, then treat it as Common Cause (94%) and fix the system — do not blame the worker.
• If an error is random, isolated, or fleeting, then treat it as Special Cause (6%) and hold the employee responsible, while still asking them to help improve the system.
• If people have authority but no clear where/why/how, then stop — empowerment without direction and method produces no impact.
• If a leader is using micromanagement, direct supervision, or overexerted influence on events better left to the worker, then you are Controlling; switch to Enabling by supplying training, tools, and coaching.
• If an innovation lives outside the organization and must later borrow shared resources, then expect a civil war — upgrade the existing culture instead of isolating the team.

• Blaming workers for systemic failure. Tell: performance reviews and post-mortems point at individuals while the same problem keeps returning.
• Mistaking Control for improvement. Tell: leaders tighten supervision and influence over events they should delegate, and ownership drops on the worker's side.
• Empowering without enabling. Tell: authority is granted but people don't act because they don't know where, why, or how to innovate.
• Relying on Skunk Works / isolated teams. Tell: early perceived success followed by vaporized results and open or passive-aggressive conflict once shared resources are needed.
• Freezing the system to look consistent. Tell: refusing to change teaching or process even when evidence shows a better way — the opposite of 'I will never apologize for learning.'

• ▸Aim / Constancy of Purpose: the one Meaningful Difference this system exists to deliver.
• ▸Problem statement: describe the observed failure in one sentence.
• ▸Cause classification: Common Cause (systemic, ~94%) or Special Cause (random, ~6%)?
• ▸System factor to improve: which training, tool, or coaching gap enabled this?
• ▸Enable vs Control audit: list any micromanagement/supervision to remove.
• ▸Where/Why/How check: do people know where, why, and how to innovate here?
• ▸Owner of the fix: management (system) or employee (special cause).
• ▸Resource-access risk: what shared resources must this touch, and where's the conflict?
• ▸Learning revision: what will you change now that evidence has shifted?

1. 1Start at leadership: only leadership has the bigger-picture understanding of today and tomorrow, so require them to make the strategic choices about which products, services, and markets to invest resources in before any Blue Card is written.
2. 2Write a Blue Card for each strategic priority that states three things employees must know: what to innovate, why to innovate, and how to innovate — the mission, the narrative behind it, and the boundaries.
3. 3Define boundaries explicitly on the card so left-brain logical thinkers (85% of the workforce) get the structure, clarity, and discipline they need; a card with vision but no boundaries leaves the majority disengaged.
4. 4Connect vertically: align every employee project to a specific Blue Card so each project traces up to a leadership strategic priority — no orphan projects.
5. 5Connect horizontally: use the cards to anticipate the needs of other departments, not just customers, so selling, accounting, quality control, and operations each carry definite goals for innovation in their own area.
6. 6Feed aligned projects into the Innovation Pipeline and weight each project's value by where it sits in development versus historical norms; the weighted value of the pipeline becomes the metric that proves alignment is producing future bottom-line value.
7. 7Design the card and pipeline to ENABLE, not control: provide training, tools, and leadership coaching so people know where, why, and how to innovate — empowerment without this knowledge has no impact.

At the P&G Invention Team, Doug's group took products to market with 10% of the staff, in 16% of the time, and at 18% of the cost of a similar project run on the traditional system. The finance department confirmed this by auditing projects of similar complexity. The gain came not from being smarter but from upgrading the system so people could work faster and more effectively toward clear aims. The manager misread it as a 'special gift' and, tellingly, noted Doug needed to 'treat the system with more respect' — the exact failure of alignment where individual creativity is celebrated but not connected to a shared, disciplined system. In Blue Card terms, the missing piece was a strategic priority everyone could align their projects to, so the results were reliable and repeatable rather than credited to one person. Alignment turns a 'special gift' into a documented, weighted pipeline of value.

• If a project cannot be traced to a specific Blue Card strategic priority, then it is not yet aligned — pause or re-scope it before development.
• If a Blue Card states vision but no boundaries, then the 85% of logical left-brain thinkers will disengage or resist — add the boundaries before releasing it.
• If leadership has not made the strategic choices about markets and investment, then don't write cards yet — you'd be asking employees to predict a future only leadership can frame.
• If you are relying on extrinsic rewards to motivate innovators, then stop — bribery and beating increase fear and decrease the intrinsic passion needed to survive innovation's ups and downs.
• If a department only problem-solves when issues arise, then it is merely 'good'; require it to anticipate customer and cross-department needs to become 'great.'

• Treating strong individual output as a 'special gift' rather than a system — the tell is a review praising the person while noting they don't respect the shared system.
• Writing cards as control instruments (micromanagement, direct supervision) instead of enablers — the tell is leaders overexerting influence on events they should leave to the worker.
• Empowering people without telling them where, why, or how to innovate — the tell is authorized employees who produce nothing because they lack direction, tools, and coaching.
• Cards that speak only to right-brain 'let loose' creativity — the tell is the logical 85% disengaging or becoming active resisters because there's no structure or discipline.
• Chasing metrics as motivators instead of outcomes — the tell is pushing pipeline numbers without improving the methods and tools of the underlying work system, so improvement doesn't sustain.

• ▸Strategic Priority Name: the leadership-owned mission this card represents
• ▸What to Innovate: the specific product, service, system, or market target
• ▸Why to Innovate (Narrative): the future customer/department need this anticipates
• ▸How to Innovate: the tools, training, and methods available to the team
• ▸Boundaries: what is in and out of scope, stated so logical thinkers have clarity
• ▸Vertical Link: which employee projects trace up to this priority
• ▸Horizontal Link: which other departments this priority must serve or coordinate with
• ▸Pipeline Weighting: development stage vs. historical norms, and resulting weighted value
• ▸Proactive/Reactive Check: is this work anticipating the future or fighting fires?

1. 1Design education to teach the how-to, not just theory. Reduce each element of innovation to a reliable, reproducible process documented in an operational manual, then have students start by doing exactly what is taught before improvising.
2. 2Engage both thinking styles deliberately. Since 85% of the work population is left-brain logical and 15% is right-brain creative, build stimuli that pair right-brain trends/insights with left-brain technologies/patents so both engage instead of disengage.
3. 3Give projects a clear, motivating strategic mission that states both vision and boundaries, so learners have focus rather than open-ended 'let loose' creativity that alienates logical thinkers.
4. 4Ground every decision in data rather than corporate politics, and use both math and writing as tools to force deeper thinking about each idea.
5. 5Confront feasibility openly: tag the biggest killers as 'Death Threats' and resolve them through disciplined, documented Fail FAST, Fail CHEAP cycles of learning.
6. 6Build capability as a leadership investment, not a departmental one. Leadership funds employee education, tools, and systems so innovation becomes the mission of everyone, everywhere, every day.
7. 7Sustain quality across the movement through licensing agreements, and require that once learners gain confidence in their capability they help the community discover and validate more effective methods.

The passages point to the Innovation Engineering academic partnership with the University of Maine as the operating model for education and tools. There, the material is offered as an undergraduate minor, a graduate certificate, and an off-campus executive education program, with a PhD program in development. Students are taught how Innovation Engineering helps them do three concrete things: get a job, get promoted, and turn their ideas into reality faster and with less risk. The courses enable the personal passion of the student — a history or English major can apply the same how-to methods to their own field. This mirrors the Deming shift the book cites: as Japanese companies enabled frontline employees, gains grew exponentially, with Sumitomo winning the Deming Prize in 1961 and productivity climbing thereafter. The lesson: education scales results when it moves innovation from a small group of 'gurus' to everyone.

• If a program only 'preaches the importance' of a childlike creative spirit, then it reaches only the 15% right-brainers — redesign it to give the 85% structure, clarity, and discipline.
• If a project lacks a clear strategic mission with defined boundaries, then don't spark ideas yet — logical thinkers will disengage or become active resisters without focus.
• If a decision is being made on corporate politics rather than data, then stop and require math and writing to ground the choice.
• If an idea carries a fatal feasibility issue, then tag it a 'Death Threat' and run a Fail FAST, Fail CHEAP learning cycle rather than ignoring it.
• If you only accelerate projects (speed without risk control) or only slow them for endless analysis (risk control without speed), then you've failed the goal — the target is Increased Speed AND Decreased Risk together.

• Building for right-brainers only. The tell: 85% of participants disengage or resist because they're asked to 'let loose,' and no Meaningfully Unique innovation reaches reality without the logical engineering/finance/production work.
• Teaching theory as the product. The tell: no operational manual, no reproducible steps — learners leave inspired but can't execute the how-to.
• Managing innovation as a specialist department. The tell: meetings, miscommunications, and rework pile up and the classic command-and-control system can't keep pace with the accelerated life cycle.
• Ignoring feasibility to keep momentum. The tell: Death Threats go untagged and surface late as failures — consistent with the 5%–15% success rate at large companies.
• Leaders skipping the capability investment. The tell: cost cutting, working harder, or pressuring workers are tried instead of funding employee education, tools, and systems — none of which is the sustainable solution.

• ▸Strategic Mission: state the vision and the boundaries of what this project must and must not touch
• ▸Right-Brain Stimuli: list trends/insights that will spark the creative 15%
• ▸Left-Brain Stimuli: list technologies/patents that will engage the logical 85%
• ▸Data Grounding: name the specific data each key decision will rest on instead of politics
• ▸Math + Writing Prompt: define the calculation and the written statement learners must produce per idea
• ▸Death Threats: list the feasibility issues that could kill the idea, ranked
• ▸Fail FAST/CHEAP Cycle: define the fastest, cheapest test to resolve the top Death Threat
• ▸Speed + Risk Target: state the speed increase sought and the risk to be cut — both required
• ▸Capability Handoff: name what learners must do to validate and improve the method once confident

1. 1Make the innovation system visible before adding subsystems: define its aim, boundaries, stakeholders, one-system metric, and enabling metrics on paper, then build a four- to seven-step flowchart of the bigger-picture phases.
2. 2Staff the enabling structure with Black Belts equal to the square root of your headcount (10 for 100 people, 22 for 500, 100 for 10,000); assign them to enable the system and drive continuous improvement, not to control projects.
3. 3Run the Collaboration Cafe by staffing project teams with separate people in the four key roles so each brings a distinct point of view — front-end team members are passion-driven volunteers who bring diversity of experience, and everyone on the team does real work rather than commenting, criticizing, or controlling.
4. 4Use Merwyn Rapid Research to fuel the DO and STUDY of your Plan-Do-Study-Act cycles: treat each idea as a theory, run fast low-cost testing with the customer (a buyer for products/services; the impacted stakeholders for internal system innovations), and use the result as an aid to judgment, not a replacement for it.
5. 5Apply Patent ROI immediately after ideas validate: run every Meaningfully Unique concept through a step to turn it into a tangible capital asset via patenting, since accelerating innovation without protecting the output is irresponsible.
6. 6Judge every subsystem by intent — design it to enable (provide training, tools, and coaching so people know where, why, and how to innovate) rather than control (micromanagement, direct supervision, overexerted influence).
7. 7Feed the quantitative idea-to-market database and use the system to improve the system: distinguish common-cause (systemic, 94%, management's job) from special-cause (fleeting, 6%, employee's job) variance so you fix the subsystem instead of blaming people.

When the Innovation Engineering Institute developed the 3.0 version of IELabs.com, the board of advisors asked which subsystem had the lowest customer interest so they could cut scope. Merwyn-style customer data was clear: patents had the lowest engagement and interest among executives. The customer data said stop on Patent ROI. Despite that, the CEO overrode the data, arguing it would be irresponsible to accelerate innovation without a system to turn ideas into tangible capital assets through patenting. The most experienced board member, Dave Kilbury, agreed — 'Patents are the new world. We need to lead on this' — accepting they would have to teach executives what patents are and why they matter, which takes patience. The lesson: research is an aid to judgment, not a replacement, so leaders continued building Patent ROI even against clear customer signals.

• If the problem is recurring and systemic (common cause, ~94%), then fix the subsystem with training and tools; if it's random or fleeting (special cause, ~6%), then it's an employee-level issue — never beat people to work harder when the system is at fault.
• If you're designing a subsystem, then test its intent: enabling gives people authority plus the knowledge of where/why/how to innovate; if it relies on supervision and control, redesign it.
• If a project is in DEFINE or DISCOVER, then staff the team with passion-driven volunteers for diversity; if it moves to DEVELOP, then dedicate fewer people full- or half-time rather than spreading many people thin.
• If customer research contradicts a direction you believe is right long-term (like Patent ROI), then treat the data as input to judgment and lead anyway when the strategic case holds — but expect it to require patience and education.
• If someone on a project team only comments, criticizes, or tries to control, then they don't belong on the team; every member must do real work.

• Adding subsystems before making the core system visible — the tell: nobody can state the system's aim, boundaries, or one-system metric, so subsystems float without a framework to serve.
• Running subsystems as control mechanisms (micromanagement, direct supervision) instead of enablers — the tell: employees have empowerment on paper but no idea where, why, or how to innovate, so nothing changes.
• Understaffing Black Belts below the square-root-of-headcount threshold — the tell: change doesn't sustain because there aren't enough navigators improving the system for innovation.
• Treating Rapid Research as a decision-maker rather than an aid to judgment — the tell: you kill or greenlight strategically important work (like Patent ROI) purely on early customer interest scores.
• Loading Collaboration teams with part-time observers who critique instead of doing work — the tell: many people spread thin, slow projects, and diluted accountability instead of dedicated members doing real work.

• ▸System Aim: state the purpose the innovation system exists to serve.
• ▸One-System Metric: name the single primary output the system delivers.
• ▸Subsystem Selected: pick from Collaboration Cafe, Merwyn Rapid Research, or Patent ROI.
• ▸Enable vs. Control Check: describe how this design gives ownership rather than supervising events.
• ▸Training/Tools/Coaching Provided: list what makes innovation practical, possible, and easy here.
• ▸Black Belt Count: compute square root of headcount and confirm coverage.
• ▸Customer for Research: identify the buyer (external) or impacted stakeholder (internal system).
• ▸Common vs. Special Cause: label the variance this subsystem is designed to reduce.
• ▸Judgment Override Note: record any strategic reason to proceed against customer data, with the patience/education plan.

1. 1Stop the brain-drain default: before you generate a single idea, commit to Stimulus Mining as a separate, prior step. Do not sit in a room 'sucking' ideas from your head.
2. 2Mine across the six documented areas: 1) Wisdom Mining (existing knowledge, best practices), 2) Patent Mining (technologies and patented methods), 3) Market Mining (competitive actions, customer problem surveys), 4) Insight Mining (customer problems and firsthand data), 5) Future Mining (trends and where the customer is headed), 6) Unrelated Mining (analogies, visualizations, cultural excursions).
3. 3Gather both related and unrelated stimulus. Related: customer problem survey results, new technologies, competitive actions. Unrelated: analogies, visualizations, cultural excursions — the unexpected inputs that set off a chain reaction across your associations.
4. 4Bring diversity of perspectives to the same stimulus. Each person perceives and interprets a stimulus differently, so having varied people react to the same input multiplies the sparks it produces.
5. 5React to each stimulus rather than judging it. Adopt 'curiosity and change' — ask what fresh idea this input suggests — instead of 'declare and defend' where you defend a pre-held position.
6. 6Capture raw ideas as they spark, then define, edit, and evaluate them. The tertile research shows high-stimulus groups still held 47 Meaningfully Unique ideas after this filtering versus 22 for low-stimulus — so load stimulus heavily up front.
7. 7Reflect out loud or in writing afterward. Speaking an idea so your ears hear it, or writing it in a journal, engages a different part of the brain and surfaces understanding you weren't first conscious of.

On the carbonless paper reinvention project, the team faced regulatory rules that seemed to force product compromise. Rather than brain-draining for a workaround, they mined stimulus — patent-style searching for a new raw material and a new patentable method of production. Within a week they identified both, overcoming the two issues at once instead of patching one. The reinvented product then won 72% to 28% against the old product in paired comparison testing. The project leader's takeaway — 'Reinventing to address what I believe are stupid regulatory rules actually leads us to a better product' — shows stimulus-response producing a genuinely better output, not just an idea. The lesson: treating the constraint as a stimulus to mine, not a wall to accept, sparked the winning combination.

• If you're about to generate ideas with nothing in front of you, then stop — you're brain-draining; go mine stimulus first.
• If the challenge is well-defined and technical, then start with related stimulus (customer surveys, technologies, competitive moves); if ideas feel stale or obvious, then add unrelated stimulus (analogies, cultural excursions).
• If a stimulus provokes a reaction (even discomfort or 'that's irrelevant'), then follow it — reaction is the chain-reaction firing, not noise.
• If you have only one perspective in the room, then recruit diverse people before reacting, because diversity multiplies sparks from the same input.
• If two people interpret the same stimulus differently, then keep both readings — that divergence is where Meaningfully Unique ideas live.

• Running brainstorming as the 'suck method' — the tell is people staring at a blank wall trying to withdraw ideas from memory as if the brain were an idea library.
• Mining only related stimulus and skipping unrelated inputs — the tell is ideas that are all incremental variations on what already exists.
• Treating stimulus as decoration, then defaulting to 'declare and defend' — the tell is participants defending pre-existing pet ideas instead of reacting freshly to inputs.
• Gathering stimulus alone with one viewpoint — the tell is low idea yield because no diversity is multiplying the sparks.
• Killing raw ideas at the moment of sparking instead of after defining and evaluating them — the tell is a thin surviving set, mirroring the low-stimulus group's 22 versus the high-stimulus 47.

• ▸Challenge statement — write the problem in one sentence.
• ▸Wisdom Mining — list known best practices or expert knowledge relevant here.
• ▸Patent/Technology Mining — note technologies or patentable methods that could apply.
• ▸Market Mining — record competitive actions and customer problem survey results.
• ▸Insight Mining — capture firsthand customer problems and data.
• ▸Future Mining — list trends pointing to where the customer is headed.
• ▸Unrelated Mining — collect analogies, visualizations, or cultural excursions.
• ▸Diverse reactors — name the varied people who will react to these stimuli.
• ▸Sparked raw ideas — log each idea and the stimulus that triggered it, for later editing and evaluation.