Don’t Ask Claude for Ideas Until You Know What Problem You’re Solving
AI makes ideas almost free, which makes the problem statement the part worth spending your effort on, and this article shows how to build one before you ask for options.
You type: Give me ideas to increase engagement in my community.
Within seconds there is a list. A weekly challenge. A member spotlight. A live Q&A. A points system. A themed month. Every item is plausible. Several are even good. You read down the list nodding, and then you realize you have no idea which one to pick, or whether any of them will fix what is bothering you.
So you ask for more ideas. Now there are more things to nod at and still no way to choose.
This is a distinctly modern kind of stuck. Not “I have no ideas,” but “I have too many and no way to judge them.”
Ideas are cheap now, and cheap things pile up
Generating options used to take effort, and that effort acted as a filter. You spent time on an idea, so you thought carefully about whether it was worth the time.
With Claude, a long list costs almost nothing. That is useful, but it removes the filter. Each idea is still a small claim on your attention: you have to read it, assess it, and either act on it or consciously set it aside. Cheap to generate does not mean cheap to evaluate.
The effect is that the bottleneck moves. It is no longer finding ideas. It is knowing which ones matter, and that depends entirely on something the idea list cannot supply: what problem you are actually trying to solve.
An idea is a guess about a solution
Here is the distinction worth holding onto. An idea is a guess about how to change something. A solved problem is a situation that has actually changed.
An idea becomes a solution only if two conditions hold: it addresses the real problem, and it works in your real circumstances. Neither can be judged from the idea itself. You need something to hold it up against.
That something is the problem statement. Without one, there is no way to say whether the weekly challenge is a good idea or merely a pleasant one. Every idea on the list is a guess, and you have not said what the guesses are about.
I will call the habit that fixes this Problem Before Possibilities: define the problem well enough to reject ideas against it, and only then ask for the ideas.
What “engagement” hides
Back to the community. “Increase engagement” sounds like a problem. It is closer to a label. Consider what could be sitting under it:
- New members join and never post.
- Longtime members have drifted away.
- A few people do all the talking and everyone else reads silently.
- People engage in private messages but not in the group.
- Nothing is wrong, and someone else’s dashboard says the number should be higher.
Each of these calls for different ideas. A points system might help the first and irritate the second. A live Q&A may suit the third and do nothing for the fourth. When you ask for ideas to increase engagement, Claude has to choose which of these it is solving, and it will choose for you, usually the most common one. You will get ideas for the average community, not yours.
The same pattern appears in other requests. “Ideas to grow my newsletter,” “ideas for a product launch,” and “ideas to improve onboarding” are all labels that cover several different problems.
What a usable problem statement contains
A problem statement does not need to be formal. It needs a few things:
Who is stuck. The specific people affected, not “users.”
What they are trying to do. The goal that is being blocked.
What is happening instead. What you have actually observed, kept separate from what you suspect. “Most new members read for a few weeks and never post” is an observation. “They feel intimidated” is a guess.
The decision or constraint that frames it. What you are actually deciding, and what limits the answer: time, budget, tone, things you will not do.
Get Suzaan Sayed’s stories in your inbox
Join Medium for free to get updates from this writer.
What would count as solved. How you will recognize that the situation has changed.
Here is a quick test for whether the statement is good enough: If I showed you an idea, could you tell whether it addresses the problem? If you can reject ideas against it, it is doing its job. If every idea still seems vaguely fine, the statement is still a label.
Use Claude to challenge the problem first
Most people stop at writing the statement. A more useful move is to ask Claude to test it before you commit.
Here is how I currently describe the problem. Do not suggest solutions yet. Tell me: what assumptions does this statement make? What other explanations could fit the same observations? Is any part of it a symptom rather than a cause? What would I need to find out to tell these apart?
This is a different job from generating ideas. You are asking for suspicion, not creativity.
A few cautions keep it useful. Claude cannot see your community, your customers, or your numbers. What it offers are alternative explanations, and each one is a hypothesis, not a finding. The point is to widen what you consider, then check it against real evidence: what members actually said, what the data shows, what you have seen yourself. Claude can also drift toward agreeing with your framing, so ask it directly to argue against it.
An illustrative example
Here is a constructed example, not a real case. A person runs a paid community for freelance designers.
The original request: “Give me ideas to increase engagement.”
The problem statement, written out:
Who: People who joined in the last few months.
Trying to do: Get feedback on their work and meet peers.
What I observe: Most read the main channel for a while and never post. I have not asked them why.
Deciding: What small change to try this month. I have limited time and do not want to add a weekly event I cannot sustain.
Solved looks like: More new members post at least once in their first weeks.
The challenge. Claude points out that “never post” could have several explanations: they do not know what is welcome, they feel the group is too advanced, they get what they need by reading, or the main channel is too busy to enter. The statement also assumes that posting is the goal, when some members may be getting value silently. Most of this is guesswork, and the person decides to ask a few new members directly before choosing anything.
Only then, the ideas. With the observation now clearer, the person asks for options that match: ways to make a first post easier, ways to show newcomers what is welcome, and ways to learn why people stay quiet. The ideas are fewer and far easier to judge, because each can be held against the statement.
The ideas were not smarter. They were aimed.
Then generate options, with the problem attached
When you do ask for ideas, bring the problem statement with you and give the request some shape:
Using the problem statement above, suggest several different approaches. Make them genuinely different from each other, not variations of one idea. Include one that is very cheap to test and one that I might be overlooking. For each, tell me which assumption it depends on and how I could test it. Do not rank them.
Asking for approaches that differ from one another counters a common weakness of AI lists, which is that they cluster around the most familiar answers. Asking what each idea depends on turns a list into a set of things you can check.
When the options arrive, evaluate them against the statement, not against how appealing they sound. Then choose the smallest test, since the aim is to learn whether the idea fixes the problem, not to commit everything to it.
Where this can go wrong
Sometimes ideas first is right. If you are exploring and genuinely do not know what the problem is, a broad list can help you discover it. Reading it can show you which ideas you find yourself rejecting, which tells you something about what you actually want. The trouble is treating that exploration as if it were a decision.
Over-defining can narrow your view too early. A statement that is too tight can rule out options you would have welcomed. Treat it as a working version that you revise.
The statement can be wrong. A clean, confident problem statement built on a mistaken observation produces tidy answers to the wrong question. Ground the observation in something you have actually seen.
Do not polish forever. Refining the statement can become avoidance. Once you can reject ideas against it, it is good enough to proceed.
Ideas still need checking. Anything consequential, such as figures, legal points, or claims about what works, deserves independent verification before you act on it.
One thing to do today
Find the last time you asked Claude for ideas. Write the problem statement you did not write: who is stuck, what they are trying to do, what you actually observed, what you are deciding, and what solved would look like.
If you cannot fill in a line, that line is the real work. Do that before you ask for another list.
The principle underneath
Ideas are cheap now. Knowing what they are for is where the work moved.
Define the problem well enough to say no to a good idea, and the list stops being a pile.
