Ideas are cheap. Invention is not.
AI can generate ideas forever. How do you decide which ones survive?
Recently, my five-year-old wanted to build a pillow fort.
But he’d decided it couldn’t just be any old pillow fort. It needed to be different. It needed to be more interesting than “put the cushions against the sofa and throw a blanket over it”.
He wanted me to suggest things.
A cave? No.
A spaceship? No.
An igloo? No.
A pirate ship? No.
And at a certain point, I hit the limits of my imagination. I was tired, and I think he’d just decided to say “no” to everything. He was a challenging client. So I said “why don’t we ask ChatGPT?”.
It gave me ten ideas immediately. Some of them I’d already suggested. But he latched on to the idea of building an animal hospital, and he was off and building.
AI is a good machine for getting unstuck - it doesn’t run out of ideas.
But if there’s a machine that can generate ideas indefinitely, ideas stop being a scarce resource. The scarce resource becomes something else: selection, validation, even taste.
It’s less “can I think of something?”
It’s more “which of these ideas deserves to survive?”
Everyone with access to an LLM has their own brainstorming machine.
Brainstorming fills up a page. It can be energizing. It produces a list of things. But the old refrain of “no bad ideas in a brainstorm” only lasts as long as the brainstorm does. There’s nothing to say that those ideas will turn into something people would use, pay for, or trust.
Idea generation is not invention.
Building a pipeline, not a prompt
I created a set of invention skills that, together, are a structured opportunity discovery and invention suite.
Discover → Generate → Stress-test → Validate → Brief
I need the sequence.
Too much AI ideation starts in the middle. Product ideas. New features. Startup concepts. Ten improvements.
We need to start before that.
What’s the opportunity? Who has the pain? What workarounds exist? What would make someone want to use this? What pushes them away from current solutions, or keeps them attached to what they already have?
Once there’s a problem worth exploring, the suite generates concepts that go through multiple methods.
This isn’t free association. This is structured invention.
The suite applies SIT patterns. Uses TRIZ-style contradictions. De Bono provocations. It will collide problems with another domain entirely. It’ll map a solution space morphologically, and build a Zwicky box of parameters and combinations.
And when it’s expanded the problem into potentially hundreds of combinations of ideas, it gets less generous.
Ideas are scored. Stress tested. It compares competing hypotheses against the evidence. Validation planning asks which experiments reduce uncertainty. We do a Mom Test.
We apply kill criteria.
And then the pipeline produces a brief.
One page that states the opportunity, the proposed solution, and the evidence that supports it - provenance is vital. What’s still uncertain? How will we validate? When do we stop?
If you can’t give an elevator pitch for your invention then it’s not finished.
That doesn’t mean it isn’t useful. But it’s not work yet.
Pressure, not abundance
Different methods apply different pressures.
The opportunity scan will ask if there’s a real problem underneath an imagined solution.
SIT asks what happens if you remove something, divide it, give it new tasks, or add dependencies.
Collision takes a domain and forces it into contact with another. Sometimes that second domain might be ancient. Sometimes it’s ordinary. Sometimes it’s weird. The point is not to deliberately get exotic. The point is to apply distance and structure.
Morphological analysis maps the problem to configurations that might have been entirely overlooked.
Hypothesis testing weighs ideas against supporting and contradictory evidence.
Scoring forces those criteria into the open. It attempts to apply some objectivity, and to expose that judgment.
Validation planning asks what the world needs to show us for this idea to earn more confidence.
And the final brief ensures that the idea survives to the point of clear explanation.
The suite isn’t magic prompts.
It’s a set of instrumentation, where each instrument marks and deforms the problem in different ways.
Collision rather than metaphor
The skill I have the most fun, for me, is collision.
In a recent piece, I wrote about how old institutions can be repositories of hard-won judgement. Guilds, courts, religious orders, astronomers and scribes. Not because they’re quaint, but because they solved problems around trust, readiness, drift and dissent centuries ago.
My invention suite entrenches that instinct. But it’s not limited to ancient history.
Collision uses anything structurally rich.
DJs building mix decks manage transition, mood and energy. Air traffic controllers sequence risk. Emergency rooms triage scarce attention and resources. I’ve collided ideas and inventions with sources ranging from prehistoric petroglyphs to jazz improvisation to standup comedy.
The source domain has to be useful.
Pure analogy is decoration. “The dashboard is like a city.” Great. Maybe. But something operational needs to flow from that comparison. Metaphors can give the impression of depth without making anything better.
My collision skill tries to avoid that trap by mapping domains structurally.
Who are the roles? What are the processes? What are the constraints? What feedback loops exist? How does the system fail?
After that mapping, it looks for isomorphisms: places where the bones of those structures match up.
I don’t want to know if one idea reminds me of another.
I want to know if one domain has used a mechanism to solve a problem, and whether I can apply that mechanism to a different domain.
Collision should provide functionality.
Making a better dashboard
I’ve been building an internal product flywheel. An AI-and-human pipeline turning customer signals into prioritized work. Scanning sources, routing work, and giving a product manager a draft queue to review.
There’s a dashboard, so that the product manager can see what the flywheel did.
It provided status, trust tracks, run history, signal counts, sizing. It showed what was under the flywheel’s hood.
But the question I was asking of the dashboard was a simple one:
Do I need to do anything?
My dashboard had the problem many dashboards have. It shows you everything you already know. It expects you to infer what matters.
I ran the invention suite against a question: what should the next version of the dashboard look like?
The invention suite came back with a cluster of solutions.
Pattern-driven concepts from SIT. Possible configurations from the morphological pass.
The collider put the dashboard into contact with petroglyphs and twelfth-century administrative registers. That sounds ridiculous - until it produces useful artifacts.
The collision focused on an idea missing from normal critique. Spatial hierarchy is semantic encoding.
If something urgent is visually subordinate, that’s confusing.
That wasn’t the whole answer. But it was an additional pressure brought to bear.
And the same recommendation began to coalesce. A headline-first dashboard, with an action queue separated from the observatory.
That’s a good idea. It might even seem an obvious idea. And the important piece isn’t that the AI produced it. It’s important that multiple methods converged on it.
SIT liked that there was no need to parse the deck first. Morphological analysis had already identified “headline plus detail” as a strong configuration. Collision liked it because spatial hierarchy encodes priority.
It was solving a problem painful enough to justify work. And the hypothesis testing didn’t come back with contradiction.
And so the suite of skills concluded with a brief.
Build a headline-first dashboard with a plain-English status sentence at the top, and in the browser tab title. Put a queue of actions immediately underneath it. Don’t remove all the existing dashboard, but put it below the fold - for observation rather than action.
With a set of validation tests.
Do PMs close the dashboard quickly if it’s all-clear? Do action items get resolved? Does the headline produce false “all-clear” messages?
Scoring, challenging, briefing and validating is invention.
The Machine God isn’t omniscient
This doesn’t make the machine wiser.
The invention suite can still produce nonsense. Scoring can be subjective, with a veneer of precision. Validation plans are useless unless someone runs the experiments.
But the suite provides a foundation for better judgement.
I don’t want any single method to be authoritative. I want it to disagree. I want it to consider a null hypothesis (”don’t do anything”). I want kill criteria.
Curiosity is a good reason to explore something.
The invention suite is intended to help us turn that curiosity into trust.
Back at the pillow fort
My son didn’t need the invention suite for his pillow fort.
He just wanted ten ideas, fast, from a machine that thought faster than a tired dad.
After that, it was just a source of childhood play. The big list of possibilities is great when the cost of choosing is just having to pick up some of the cushions.
That’s not most work.
Product ideas have cost. Engineering work has cost. A strategic choice has cost. AI-generated recommendations entering the workflow have cost.
And as AI becomes increasingly powerful at generating ideas, our judgement of those ideas becomes increasingly important.
AI makes ideation trivial.
That exposes how much of invention was never ideation in the first place.
Invention is about killing the idea you really wanted to like. Then turning the surviving thing into a brief that’s clear enough for someone else to decide what to do next.
Invention is not cheap.
Further reading:
Why I want my AI projects blessed by Jesuits - on teaching AI what others learned centuries ago.
Lohr, S. Can A.I. Invent? New York Times, Jun 2023.
Schultz, B. N. N. Morphological Box (Zwicky Box): Guide with CCA & Example. Service Innovation Labs, Feb 2026.
Rodriguez, G. R. SIT: Israel’s Answer To Design Thinking? Forbes, Apr 2015.
Article photo by History in HD on Unsplash.
