foundation

why your Claude outputs feel off — and the one shift that fixes it

by chaz johnson · method with ai

most people write to AI the way they'd type a search query. a few words. maybe a sentence. then they're surprised when what comes back feels generic.
the problem isn't the tool. it's the input — and it's completely fixable.

the search engine habit

for twenty years, we've been trained to communicate with machines in fragments. "best pizza near me." "how to fix a leaky faucet." "symptoms of dehydration." short, keyword-dense, stripped of everything a human would actually say to another human.

that training is working against you when you open Claude.

Claude isn't a search engine. it doesn't rank results based on keywords. it responds to meaning — to the full picture of what you're trying to do, who you are, what you've already tried, and what good looks like to you. when you strip all of that out and type a fragment, Claude fills in the blanks by guessing. and its guesses are going to be generic, because generic is the statistical center of all the things you might have meant.

"when you give Claude a fragment, it gives you a best guess. when you give Claude context, it gives you a collaborator."


what context actually means

context isn't just background information. it's the difference between Claude understanding the surface of your request and understanding what you're actually trying to accomplish.

context includes:

who you are — your role, your level of expertise, the kind of language you use. a marketing director and a first-year intern asking the same question should get very different answers.

what you're working on — the specific project, document, situation, or goal. the more specific you are, the more specific Claude can be.

what you've already tried — if you've drafted something and it's not working, show Claude what you have. it can work with raw material far better than it can work from nothing.

what good looks like — this is the part most people skip entirely. what does a useful response actually look like for this specific request? how long? what tone? what format? what should it definitely not include?


the same request, two ways

here's a concrete example. same underlying need, two very different inputs.

without context
"write me a follow-up email"
with context
"i'm a freelance web designer and i had a discovery call last tuesday with a small landscaping company in michigan. they seemed interested but haven't responded to my proposal. i want to follow up without being pushy — they're a small local business and i don't want to come across as salesy. keep it short, one paragraph, casual but professional. don't use the phrase 'just checking in.'"

the first input produces a generic follow-up email template you could find anywhere. the second produces something you could actually send. same feature, completely different outcome — and the only thing that changed was what you told Claude about your situation.


the collaborator shift

the mental shift that changes everything is this: stop thinking of Claude as a tool you query and start thinking of it as a collaborator you brief.

when you bring a collaborator up to speed, you don't just tell them the task. you tell them the goal behind the task, the constraints you're working within, what you've already tried, and what success looks like. you share context because you want them to make good decisions on your behalf — not just execute instructions blindly.

Claude works the same way. the more you brief it, the better it performs. this isn't about writing longer prompts for the sake of length. it's about giving Claude what it needs to actually understand what you're trying to do.

"a good brief isn't longer. it's more complete. there's a difference."


a simple framework to start with

before you write any message to Claude, run through four quick questions:

who am i in this situation? — your role, expertise, context. Claude should know who it's helping.

what am i actually trying to accomplish? — not just the task, but the goal behind it. why does this matter? what happens if it goes well?

what constraints matter? — tone, format, length, things to avoid, things that must be included. the guardrails that separate a useful output from a generic one.

what does a useful response look like? — be specific. "a short email i could send as-is" is more useful than "an email." "a bullet list of three options with trade-offs" is more useful than "some ideas."

you don't have to answer all four every time. but running through them for ten seconds before you type will change the quality of what comes back.


when it still feels off

even with better inputs, Claude will occasionally miss the mark. this is normal and it's not a failure — it's information. when the output isn't right, don't start over. tell Claude what's wrong with it.

"this is too formal" is useful. "make the second paragraph shorter and remove the bullet points" is more useful. "this isn't quite right — i need it to sound more like something i'd actually say, less polished, more direct" is even better.

refinement is part of the process. Claude holds everything you've said in the conversation and can adjust based on feedback. the first output is a draft, not a verdict.

the shift from tool to collaborator is also the shift from one-shot to iterative.
brief it. review it. refine it.
that's how the best results happen.

go deeper

the full method.
in your inbox.

get the four-layer framework and early access to the full archive.

no spam. just the method.