Dumb Questions Engine

The most important question in cancer research wasn't asked by a researcher. It was asked by a student: "What if instead of trying to kill cancer cells, we just made them behave like normal cells?"

That question didn't contain an answer. It contained a door. Researchers walked through it and found an entire field (cell reprogramming) that the "smart" questions had been walking past for decades.

Every skill in this stack generates answers. This is the only one that generates questions.

That distinction matters because the quality of your answers is capped by the quality of your questions. A brilliant answer to a mediocre question is still a mediocre outcome. A dumb question that nobody's asking can unlock answers nobody's considered.

The pattern is consistent across every domain: "Why do elevators need to be faster?" opened the door to mirrors. "Why do shoppers need to register?" opened the door to the $300M button. "Why do we try to kill cancer?" opened the door to reprogramming. "Why does the data pipeline need stages?" opened the door to self-executing events. "Why do we punish people to reduce crime?" opened the door to restorative justice.

None of these were answers. They were questions that made the existing answers look like they'd been solving the wrong problem all along.

How It Works

1. Name the territory — What space are we generating questions about?
2. Map the assumptions — What does everyone in this space take for granted?
3. Generate the questions — Produce 15-20 questions nobody is asking
4. Star the dangerous ones — Find the 3-5 that make experts flinch

Step 1: Name the Territory

The territory is not the problem. It's the space the problem lives in.

Go one level wider than the problem. Questions about the problem produce incremental reframes. Questions about the territory produce paradigm shifts.

If the problem is "how do we increase our app's share rate," the territory is "how single-player mobile experiences become social."

If the problem is "how do we reduce hospital readmissions," the territory is "how people navigate the transition from institutional care to home."

If the problem is "how do we improve this codebase," the territory is "how software systems remain comprehensible as they grow."

If the problem is "how do we reduce recidivism," the territory is "how people rebuild identity after institutional confinement."

If the problem is "how do we find novel resistance mechanisms," the territory is "how organisms survive stressors in ways that don't look like resistance."

State the territory in one sentence. That sentence is the only input for the rest of the skill.

Step 2: Map the Assumptions

Every territory has assumptions that everyone inside it treats as facts. These are not controversial opinions. They're the things so obvious that nobody says them out loud because questioning them feels stupid.

That's exactly why they need questioning.

The method:

List 8-12 things that everyone in this territory takes for granted. Not debatable positions. Settled consensus. The stuff that experts would say "well, obviously" about.

Here is what this looks like across domains:

For word puzzle games:

• Players want to solve puzzles
• Harder puzzles are more rewarding
• Daily puzzles create habits
• Sharing results is how puzzle games grow
• The puzzle itself is the product
• Players play alone
• Scores and streaks drive retention

For nonprofit fundraising:

• You need to ask people for money
• Donors give because they care about the cause
• More donors is better than fewer donors
• A good story drives donations
• Events are important fundraising tools

For antibiotic resistance research:

• Resistance is a property of individual organisms
• The way to find resistance is to expose bacteria to antibiotics and see what survives
• Stronger antibiotics are the goal
• Resistance genes are the unit of analysis
• Lab conditions approximate real-world behavior

For urban transportation policy:

• More roads reduce congestion
• People need cars to commute
• Public transit should serve existing demand patterns
• Speed is the primary metric of transportation quality
• Infrastructure investment is the primary lever

For software architecture:

• Systems should be modular
• Complexity should be managed through abstraction
• More tests mean more confidence
• Technical debt is always bad
• Performance and readability trade off

Each assumption is "obvious." Each is a door waiting for a dumb question to open it.

Step 3: Generate the Questions

Take each assumption and generate 1-2 questions that challenge it.

The questions follow three patterns:

Pattern A: "What if the opposite were true?"

Take an assumption and flip it.

Assumption: Players want to solve puzzles. Question: "What if players don't want to solve puzzles — what if they want to watch someone else struggle?"

Assumption: Resistance is a property of individual organisms. Question: "What if the most dangerous adaptations aren't happening in individual bacteria at all, but in the structure of the population?"

Assumption: More roads reduce congestion. Question: "What if every road we build generates the traffic that fills it, and the cities with the least congestion are the ones that stopped building?"

Pattern B: "Why does this have to be this way?"

Take an assumption and ask whether it's a law of nature or just a habit.

Assumption: The puzzle itself is the product. Question: "Why is the puzzle the product? What if the conversation about the puzzle is the product?"

Assumption: Complexity should be managed through abstraction. Question: "Why do we abstract? What if making the complexity visible and navigable is better than hiding it behind interfaces?"

Assumption: Public transit should serve existing demand patterns. Question: "Why do we design routes for where people already go? What if transit should create new patterns by connecting places people don't currently think to travel between?"

Pattern C: "What would a complete outsider find absurd?"

Take an assumption and look at it from the perspective of someone who has never encountered this territory.

Assumption: Sharing results is how puzzle games grow. Question: "If you'd never seen a phone before and someone showed you this game, would 'tell your friends your score' be your first instinct? Or would you say 'can I play this against someone right now?'"

Assumption: Stronger antibiotics are the goal. Question: "If an alien biologist looked at our approach, would they say 'why are you in an arms race with organisms that reproduce a million times faster than you can develop weapons?'"

Assumption: Technical debt is always bad. Question: "If someone from finance looked at how engineers talk about technical debt, would they say 'you realize all debt is a tool, right? The question isn't whether to have it — it's whether the return exceeds the interest.'"

The output

Generate 15-20 questions total. Write each as a single question. No preamble. No explanation. No "this is interesting because..."

The question speaks for itself or it doesn't belong on the list.

Mix all three patterns. Don't label which pattern each comes from. The labels are scaffolding. The questions are the product.

Step 4: Star the Dangerous Ones

Read every question back. Apply the Expert Threat Test:

Would a senior person in this territory hear this question and feel comfortable? If yes, the question is too safe. It's a "good question" that stays inside the existing frame.

Would they feel a flash of defensiveness? Would they say "that's not how it works" or "you don't understand the field" or "we've been over this"?

That defensiveness is the signal. The question touched something structural. Something the expert's career is built on. Something that would have to change if the question were taken seriously.

Star 3-5 questions that produce the most defensiveness. These are the doors worth walking through.

Present the full list of 15-20 questions. Star the dangerous ones. Then pause.

After the list, add a horizontal rule and whitespace, then ask in bold:

Which of the starred questions do you want to walk through? Pick one, pick several, or tell me which ones scare you — those are usually right.

The user must know it's their turn. The list is not the output. The list is a menu. The user picks the doors. Then you open them.

After the Questions

Questions are not the end. They're the beginning.

Each starred question can become:

A reframed problem for generation. "What if the most dangerous adaptations aren't in individual bacteria?" becomes a problem: "Design experiments that measure population-level genomic shifts rather than individual survival." Feed that into the Guilford Engine or Persona Divergence Engine.

An input for the Wrong Problem Detector. A starred question might reveal that the problem the user is solving is the wrong one. Run the detector against the reframe.

A seed for Think Wrong. Take the starred question, assume the answer is yes, and build the counterintuitive position.

A prompt for Strip Down. If the question points at a deeper desire than the one the user started with, Strip Down can extract it.

The Dumb Questions Engine is the only skill in the stack that doesn't produce things to evaluate. It produces things to explore. Every other skill evaluates or generates. This one opens doors and lets the user choose which rooms to enter.

When to Use This Skill

Use it when:

• A space feels stuck and everyone is generating answers to the same set of questions
• A field, industry, or practice does things a certain way "because that's how it's done" and nobody can explain why
• The user says "I don't even know what to ask"
• A problem has been worked on for years by smart people without resolution (the questions are probably stale, not the answers)
• You want to explore a space before committing to a problem definition
• Before running the Wrong Problem Detector (questions can surface problems the five checks might miss)

Don't use it when:

• The user has a clear, confirmed problem and needs solutions now
• The task is execution, not exploration
• Time pressure demands answers, not questions
• The user already has too many open questions and needs focus, not more openings

Relationship to Other Skills

Before Wrong Problem Detector: The Dumb Questions Engine surfaces the questions nobody is asking. The Wrong Problem Detector checks whether the current problem is right. Together they cover both sides: "are we asking the right questions?" and "is the problem we're solving the right one?"

Before Strip Down: A starred question might point at a different desire than the one the user started with. Strip Down can extract it.

Before all generation skills: A dumb question, taken seriously, becomes a problem statement. A problem statement feeds every generator. Questions → problems → ideas.

Complements Think Wrong: Think Wrong challenges consensus answers. Dumb Questions challenges consensus questions. Think Wrong says "the obvious answer is wrong." Dumb Questions says "the obvious question is boring — here's the interesting one."

This is the earliest skill in the stack. It runs before you even know what problem you're solving. It produces the raw material that every other skill refines.