Weak vs. Strong Prompt Examples
A practical comparison guide
This document shows the same request written as a weak prompt and a strong prompt. The purpose is not to show extreme opposites — the weak versions here are the kind of thing a thoughtful person might actually write. The strong versions show what adding audience, context, goal, and constraints actually looks like.
Example 1: Blog post
Weak:
Write a blog post about customer onboarding.
Strong:
Write a 700-word blog post for a B2B SaaS company. Audience: customer success managers who work at software companies. Topic: reducing churn during the first 30 days of onboarding. Tone: direct and practical — no hype, no fluff. Assume the reader has tried basic onboarding tips before and wants more specific, actionable ideas. Avoid generic advice like "check in frequently." Give concrete examples where possible.
What changed: Audience named. Goal defined (reduce churn). Tone set. Generic advice explicitly excluded. Expertise level assumed.
Example 2: Email
Weak:
Write an announcement email about our new feature.
Strong:
Write a short announcement email for existing customers about a new bulk export feature we just launched. These customers have been asking for this feature for months — it lets them download multiple reports at once. Audience: power users who are familiar with the product. Tone: direct and friendly — not hypey. Under 150 words. Subject line should be specific and clear, not promotional. Avoid phrases like "exciting news" or "we are thrilled."
What changed: Audience narrowed. Feature described. Tone and style guided. Length capped. Specific phrases excluded.
Example 3: Meeting summary
Weak:
Summarize these meeting notes.
Strong:
Summarize these meeting notes into a brief internal update for team members who did not attend. Focus on: decisions made, action items with owners, and open questions that still need resolution. Format: three labeled sections. Tone: direct and factual — no narrative. Under 250 words. [Notes pasted below]
What changed: Audience defined (non-attendees). Specific capture goals named. Format structured. Length limited.
Example 4: Job description
Weak:
Write a job description for a marketing manager.
Strong:
Write a job description for a senior content marketing manager at a B2B software company with a remote-first team of 25 people. We want someone with 5+ years of experience who can own content strategy independently. The tone should be direct and reflect our no-BS culture — skip inflated corporate language. Include sections for: role overview, key responsibilities (5 bullets max), required qualifications, and why this role is interesting. Avoid language that implies we want someone junior. Under 500 words.
What changed: Company context added. Experience level specified. Culture guidance included. Sections defined. Anti-junior signal given. Length capped.
Example 5: Research summary
Weak:
Summarize this research on remote work productivity.
Strong:
Summarize this research on remote work productivity for the leadership team at a 200-person software company. They are deciding whether to introduce an optional return-to-office policy. Focus only on findings that speak to productivity and collaboration — skip methodology, academic framing, and anything about employee wellness (covered separately). Format: three to five clear findings as bullet points, each with a one-sentence "implication for our decision." Under 400 words. [Research pasted below]
What changed: Audience defined. Decision context given. Focus area narrowed. Exclusions named. Actionable framing added. Length set.
Example 6: Project update
Weak:
Write an update for the stakeholders about the project.
Strong:
Write a brief stakeholder update about a software release that has been delayed by two weeks due to QA findings. Audience: internal leadership team. They are supportive but want clear facts and the new timeline. Tone: candid and confident — not apologetic or defensive. Format: three short paragraphs — what happened, what we found, what the updated plan is. Under 200 words. Avoid hedging language like "it seems" or "we believe we can."
What changed: Situation explained. Audience understanding noted. Tone characterized in positive and negative terms. Structure specified. Hedging explicitly excluded.
Example 7: Explanation for a non-technical audience
Weak:
Explain what an API is.
Strong:
Explain what an API is to a non-technical marketing manager who needs to understand it well enough to participate in a meeting with an engineering team. Focus on what APIs do at a practical level — not how they work technically. Use an analogy if it helps. No jargon. Two short paragraphs at most.
What changed: Specific audience role given. Purpose of the explanation named. Level of depth defined. Technical depth explicitly excluded. Length capped.
Example 8: Strategy memo
Weak:
Write a memo recommending we move to a tiered support model.
Strong:
Write a one-page decision memo recommending we shift from a generalist support model to a tiered specialization model. Audience: founding team who will approve or reject the change at the next all-hands. They care about customer impact, operational feasibility, and whether the timing is right. Structure: current state, key limitation, recommendation, why now, and the specific decision being asked for. Tone: direct and confident — no hedging. Under 400 words.
What changed: Decision context built in. Audience decision criteria named. Structure prescribed. Action ask required. Hedging excluded.
Pattern summary
| What was added | Why it matters |
|---|---|
| Specific audience role | Changes vocabulary, depth, tone, and framing |
| Clear goal or outcome | Focuses the document on a purpose, not just a format |
| Tone description (what it should/should not feel like) | Prevents generic corporate writing |
| Format instruction | Avoids AI inventing structure that does not fit the situation |
| Length limit | Forces prioritization, prevents padding |
| Exclusion instructions | Eliminates the most common unwanted AI defaults |
| Context (project, situation, decision) | Grounds the output in something real instead of generic |