How to write GTM prompts that actually produce usable output

The most common GTM prompt failure is not a writing problem. It is a specificity problem. Prompts that produce generic output are almost always prompts that ask for something open-ended without telling the model what to do with the result.

"Research this company" returns a Wikipedia-style summary. "Research this company and give me the single most relevant outreach angle in one sentence, based on their most recent hiring activity" returns something you can actually use in an email.

The shift from vague to specific is the entire skill. Everything else — tone, format, length — is secondary. Get the question right first.

Constraint is the most powerful lever in prompt writing. The more tightly you define what you want back, the more consistent and usable the output.

If you want a first line for a cold email, say you want it under 20 words. If you want a lead score, say you want a number from 1 to 10 followed by a one-sentence reason. If you want a meeting summary, say you want three bullet points with a next steps section at the end.

Open-ended outputs require you to do editing and formatting work after the fact. Constrained outputs can flow directly into the next step of your workflow. In a Clay table or an n8n workflow, constrained output is the difference between a column you can use and a column you have to fix.

The test for whether your constraint is tight enough: could you paste the output directly into whatever comes next without editing? If yes, your constraint is working. If no, tighten it.

Starting your prompt with a role description changes the depth and tone of the output more than most people expect. The model adjusts its reasoning based on the identity you give it.

"You are a B2B sales analyst" produces different output than no role at all, even with an identical task. "You are a senior cold email copywriter who specialises in outbound for B2B SaaS companies" produces better output than "you are a sales analyst" for a personalisation task.

The role works because it activates a more specific set of patterns in the model's response. Be specific about the role. "Expert" is not specific. "Sales development representative who has sent over 10,000 cold emails" is specific. The more real the role sounds, the more useful the output tends to be.

If you are running a prompt in Clay, the model does not know what your product does, who your ICP is, or why this specific company is on your list. You have to tell it. Prompts that produce generic output are almost always missing this context.

The information you need to provide: what you sell and to whom, what problem you solve, what makes this specific prospect relevant, and what action you want the prompt to support. Without this, the model defaults to general patterns that could apply to anyone.

In Clay, include this context in the system prompt section rather than the user message. This keeps it consistent across all rows without repeating it. The user message then contains only the row-specific data that changes per prospect.

In n8n, pass the context as part of the system message and use expressions to inject the row-specific data into the user message. The separation between static context and dynamic data makes your prompts easier to maintain and debug.

When a prompt is not working, the instinct is to rewrite the whole thing. That is almost always the wrong move. Add one sentence of additional context and see if that fixes it first.

Nine times out of ten, the problem is that the model does not have enough information to do what you are asking, not that the structure of your prompt is wrong. Before you rewrite, ask yourself: what does the model not know that it would need to know to produce good output here?

Test every prompt on at least five examples before you scale it. The edge cases you find in those five will surface failures you never would have anticipated. A prompt that works perfectly on your first test example will often produce garbage on the sixth or seventh.

When testing in Clay, duplicate three to five rows that represent different types of companies on your list — different sizes, different industries, different data completeness — and run the AI column on those before running the full table. Fix what breaks in the test rows before committing credits to the full enrichment.