wrong-problem-detector

name

wrong-problem-detector

description

Check whether you're solving the right problem before generating solutions. Use BEFORE any ideation when the problem as stated feels stuck, when every solution feels inadequate, when the obvious answers have already been tried and failed, or when a problem has persisted despite smart people working on it. Triggers on "we've tried everything," "nothing is working," "we keep solving this but it comes back," "I feel like we're missing something," "why can't we fix this," or any moment where the quality of available solutions seems suspiciously low for the amount of effort being applied. If every solution to a problem feels mediocre, the problem might be wrong. Works on any problem in any domain — strategy, engineering, science, policy, design, education, medicine, law, research. Also use as a pre-check before any expensive brainstorm — five minutes confirming you're solving the right problem is cheaper than two hours generating brilliant answers to the wrong one.

Wrong Problem Detector

The elevator wasn't slow. The shoppers weren't lazy. The coffee cup wasn't badly designed.

In each case, smart people generated smart solutions to the stated problem. Faster elevators. Better registration flows. Redesigned cups.

All wrong. Not wrong because the solutions were bad. Wrong because the problem was wrong.

The elevator problem wasn't speed. It was boredom. The checkout problem wasn't registration design. It was forcing registration at all. The coffee cup problem wasn't the cup. It was the hand.

This happens in every domain. The research lab keeps screening compounds when the real problem is the definition of what they're screening for. The school keeps redesigning the curriculum when the real problem is that nobody asked the teachers what they need. The city keeps widening roads when the real problem is that the roads generate the traffic that fills them.

When every solution to a problem feels mediocre, the problem is usually mislabeled. You're optimizing the wrong variable. You're solving the problem as stated by the first person who described it, and that person described a symptom, not a cause.

This skill catches the mislabel before you waste a brainstorm on it.

---

How It Works

Before generating any solutions, run five checks on the problem itself. If any check fires, rewrite the problem before proceeding.

The checks are:

1. The Symptom Test — Are you solving a symptom or a cause?
2. The Audience Test — Whose problem is this actually?
3. The Verb Test — What if the action is wrong?
4. The Frame Test — What if the opposite problem is the real one?
5. The Existence Test — What if this problem doesn't need to exist?

You don't need all five to fire. One is enough to rewrite the problem. But run all five every time, because the one you'd skip is usually the one that catches it.

---

Check 1: The Symptom Test

Ask: "Is this the problem, or is this what the problem looks like?"

Most problems as stated are symptoms. "Our conversion rate is low" is a symptom. "Our readmission rate is high" is a symptom. "The experiment keeps failing" is a symptom. "Students aren't graduating" is a symptom.

The problem might be something underneath any of these that requires a completely different solution.

The symptom test works by asking "why" until you hit something structural.

The method:

Take the stated problem. Ask "why is this happening?" Take the answer. Ask "why is THAT happening?" Repeat until you hit a statement that feels like a design choice someone made (or forgot to make) rather than a result someone is observing.

Symptoms are things you observe. Causes are things someone decided.

Example (business):

Stated problem: "Our app has low retention." Why? → Users stop opening it after a week. Why? → There's nothing new to see after onboarding. Why? → The content is static and doesn't refresh. Why? → Nobody designed a content refresh cycle.

The problem isn't "low retention." The problem is "nobody designed a reason to come back." Those require completely different solutions.

Example (research):

Stated problem: "We can't find novel resistance mechanisms." Why? → We keep finding the same ones. Why? → Our assays only detect the same types. Why? → We designed assays around our existing definition of resistance. Why? → Nobody questioned whether the definition covers all survival strategies.

The problem isn't "screening harder." The problem is "screening for the wrong thing."

Example (education):

Stated problem: "Our teacher retention is low." Why? → Teachers leave after 2-3 years. Why? → They feel unsupported and burned out. Why? → There's no structured mentorship or development after year one. Why? → Nobody designed a career arc beyond "stay in the classroom."

The problem isn't "retention." The problem is "no growth path."

When to stop asking why: when the answer sounds like a decision rather than an observation. "Nobody designed X" is a decision. "Retention is low" is an observation. Solve decisions, not observations.

---

Check 2: The Audience Test

Ask: "Whose problem is this, really?"

Problems are often stated from the perspective of the person describing them, not the person experiencing them.

"We need more users" is the company's problem. "We need more citations" is the researcher's problem. "We need higher test scores" is the administrator's problem. "We need lower crime rates" is the politician's problem.

In each case, the person on the other side of the problem experiences something different.

The method:

Take the stated problem. Ask: "Who actually experiences this as a problem in their life?"

If the answer is "us" (the org, the team, the lab, the department), the problem is stated from the inside out. Flip it.

What does the person on the other side of this problem experience? What are they frustrated by? What are they not getting? What would they say the problem is if you asked them at a bar?

Example (business):

Stated problem: "Our email open rate is declining."

Whose problem is this? The marketing team's. The subscriber's problem might be: "I get too many emails and this one doesn't stand out." Or: "I signed up for something I don't remember wanting."

The marketing team's problem and the subscriber's problem are not the same problem. Solving the subscriber's problem fixes the open rate. Solving the open rate directly might not fix anything.

Example (medicine):

Stated problem: "Patient compliance with medication is low."

Whose problem is this? The physician's. The patient's problem might be: "The side effects make me feel worse than the disease." Or: "Nobody explained why I need this." Or: "I can't afford the refill."

The physician's compliance problem and the patient's quality-of-life problem require completely different interventions.

Example (policy):

Stated problem: "Voter turnout is declining."

Whose problem is this? The election commission's. The non-voter's problem might be: "I don't see anyone worth voting for." Or: "I can't get time off work." Or: "I moved and my registration didn't follow me."

Each is a different problem requiring a different solution. None of them are "turnout."

---

Check 3: The Verb Test

Ask: "What if we changed the action?"

Most problems contain an implicit verb that predetermines the kind of solution you'll generate.

"How do we increase sales?" The verb is "increase." Every solution will be about more.

"How do we reduce readmissions?" The verb is "reduce." Every solution will be about prevention.

"How do we improve the curriculum?" The verb is "improve." Every solution will be about refinement.

But what if the verb is wrong?

The method:

Take the stated problem. Identify the verb. Replace it with three different verbs and see if the problem becomes more interesting:

• Replace "increase" with "eliminate the need for"
• Replace "reduce" with "make irrelevant"
• Replace "improve" with "replace entirely"
• Replace "fix" with "redesign so it can't break"
• Replace "grow" with "deepen"
• Replace "stop" with "redirect"

The $300M button story is a verb problem. The stated problem was "how do we improve the registration process?" The verb "improve" locked everyone into optimizing registration. The real move was to change the verb to "eliminate" — how do we eliminate registration entirely?

Example (business):

Stated problem: "How do we reduce customer complaints?"

Verb swap:

• "How do we eliminate the thing they're complaining about?"
• "How do we make complaints useful instead of reducing them?"
• "How do we redesign the experience so complaints can't happen?"

Example (engineering):

Stated problem: "How do we speed up the build pipeline?"

Verb swap:

• "How do we eliminate the build step entirely?"
• "How do we make build speed irrelevant to the developer experience?"
• "How do we redesign the architecture so nothing needs to build?"

Example (science):

Stated problem: "How do we increase the sensitivity of the assay?"

Verb swap:

• "How do we eliminate the need for high sensitivity?"
• "How do we replace the assay with something that measures a different signal entirely?"
• "How do we redesign the experiment so the current sensitivity is enough?"

Each rewrite points at a different root. The original verb predetermines one category of solution. Different verbs open different doors.

---

Check 4: The Frame Test

Ask: "What if the opposite is the real problem?"

Sometimes a problem is stated as its mirror image. The thing that looks like the problem is actually the solution, and the thing everyone assumes is fine is actually the problem.

The method:

Take the stated problem. Invert it.

"We're not growing fast enough" becomes "we're not retaining enough to matter."

"Our product is too expensive" becomes "our product doesn't justify its price."

"We need more content" becomes "we're not getting enough out of the content we have."

"We're not publishing enough papers" becomes "we're publishing too many mediocre ones and burying the signal in noise."

"Nobody knows about us" becomes "the people who know about us aren't telling anyone."

"Students aren't engaged" becomes "we're measuring engagement wrong and the students who look disengaged are the ones who've already outgrown the material."

The inversion doesn't always work. When it doesn't, the original framing was probably correct. But when it does — when the inverted version suddenly feels more true than the original — you've found the wrong problem.

Example:

Stated problem: "We need to acquire new customers."

Inversion: "We're losing the customers we already have."

If churn is 40%, acquiring new customers is filling a leaky bucket. The stated problem (acquisition) is the mirror image of the real problem (retention). Every dollar spent on acquisition when the real problem is retention is a dollar wasted.

The inversion test catches this in thirty seconds.

---

Check 5: The Existence Test

Ask: "What if this problem doesn't need to exist at all?"

Some problems are only problems because of a system, structure, or assumption that could be removed entirely.

The Java Jacket didn't solve "how do we make cups that don't burn hands." It dissolved the problem entirely by adding something between the hand and the cup that meant the cup's temperature was no longer the hand's problem.

The method:

Take the stated problem. Ask: "What system, rule, or assumption creates this problem?"

Then ask: "What if that system, rule, or assumption didn't exist?"

If the problem disappears when you remove the assumption, the problem isn't real. The assumption is the problem.

Example (business):

Stated problem: "Our meetings are too long and unproductive."

What creates this problem? The assumption that we need meetings.

What if meetings didn't exist? Async decision documents. 15-minute standups with no chairs. "The only meeting that exists is the one where a decision gets made, and everything else is a memo."

Example (education):

Stated problem: "Students cheat on exams."

What creates this problem? The assumption that exams must test recall under closed, timed, individual conditions.

What if that format didn't exist? Open-book assessments, portfolio evaluations, oral defenses, project-based demonstrations. In most of these formats, "cheating" is redefined as "collaboration" or "using available resources" — which is what the real world actually rewards.

Example (engineering):

Stated problem: "Our deployments keep causing outages."

What creates this problem? The assumption that deployment is a discrete, risky event.

What if the deployment event didn't exist? Continuous delivery where every merge to main is a production release. Canary deploys where 1% of traffic tests the change before 100% gets it. The deployment isn't the problem. The batch size is the problem.

The existence test doesn't always dissolve the problem. Some problems are real and unavoidable. But a surprising number of "hard problems" turn out to be artifacts of systems nobody thought to question.

---

After the Checks

If none of the checks fire — if the stated problem survives all five — say so. "I ran five checks and the problem as stated holds up. It's the right problem to solve."

That's valuable too. Confidence that you're solving the right thing is worth the five minutes it took to check.

Then proceed to whatever generation skill fits the confirmed problem.

If any check produced a rewritten problem that feels more true than the original:

Present the reframe as a clear checkpoint.

This is a moment where the user's input matters. If the reframe is wrong, everything downstream is wasted. So pause and ask — but ask well.

The problem with a buried question: Users read a long analysis, see a question at the bottom, and think the output is done. The question looks like a closing thought, not a checkpoint.

So make the checkpoint impossible to miss.

The format — lead with the reframe, not the analysis:

---

⚡ Reframe Checkpoint

The checks suggest you might be solving the wrong problem.

Stated problem: [original]

Reframed: [strongest reframe — 1-2 sentences max]

I also found these angles:

• [Alt reframe A name]: [one sentence]
• [Alt reframe B name]: [one sentence]

Which reframe should I generate ideas from? Or if the original problem is actually right, say so and I'll generate from that instead.

---

Critical: reframes are problems, not ideas.

Every item in the checkpoint — the main reframe and the alternatives — must be a PROBLEM RESTATEMENT, not a solution direction.

A reframe changes what you're solving. An idea is something you'd do about it. If the user could respond with "yes, let's do that" — it's an idea. If the user responds with "yes, that's the real question" — it's a reframe.

This is an idea disguised as a reframe: "Empty storefronts are the most available real estate in the city — who needs space but can't normally afford a street-level location?" (The user would say "let's do that." It's a solution direction, not a problem.)

This is an actual reframe: "Downtown doesn't have a traffic problem — it has an identity problem. It was never designed to be anything specific, just a default location for commerce." (The user would say "yes, that's the real issue." It changes what you're solving for.)

The test: does this reframe lead to MANY DIFFERENT possible solutions? Or does it point toward ONE specific solution? If one — it's an idea. Rewrite it.

---

The checkpoint goes at the TOP of the response after the analysis, visually separated, with a clear heading the user can't miss.

This is not a rhetorical question. This is not a closing flourish. This is a genuine fork in the road and the user needs to choose the path before generation begins.

Wait for their response. Then generate from whatever they chose.

---

When to Use This Skill

Always use when:

• "We've tried everything and nothing works" (probably solving the wrong problem)
• The problem has persisted for a long time despite effort and resources
• Every proposed solution feels mediocre or incremental
• The person describing the problem and the person experiencing the problem are different people

Use as a quick pre-check when:

• About to run a major brainstorm (five minutes of problem-checking saves two hours of wrong-problem solving)
• About to commit significant resources to a solution
• A new team member, student, or outsider says "wait, why are we doing it this way?" and nobody has a good answer

Don't use when:

• The problem is clear, confirmed, and urgent (don't over-examine when the building is on fire)
• The user has explicitly validated the problem through data, research, or direct experience
• The task is creative execution, not problem-solving (naming, writing, design — the problem is already set)

---

Relationship to Other Skills

Before Strip Down: Wrong Problem Detector checks whether the problem is right. Strip Down extracts the desire from the brief. Running the detector first ensures Strip Down extracts the desire for the right problem, not a beautifully articulated desire for the wrong one.

Before all generation skills: Every generation skill in the stack produces solutions. Solutions are only as good as the problem they solve. This is the pre-pre-step. Problem check → desire extraction → generation.

Complements Think Wrong: Think Wrong challenges the consensus answer. Wrong Problem Detector challenges the consensus question. Think Wrong says "the obvious solution is wrong." This skill says "the obvious problem is wrong." They work on different levels. Use this one first — confirming the problem is right, then Think Wrong to find the counterintuitive solution to it.