The Feature Launch Prompt Pack: 20 Prompts

I'm preparing to launch a new feature. Before I write any messaging, I want to get crisp on the underlying problem.

Feature: [name and one-sentence description]
Product: [what your product does, who it's for]
What triggered this feature: [customer complaint, sales blocker, support ticket pattern, founder intuition]

Help me do three things:
1. Restate the problem in the customer's language, not the product team's language. Avoid using the feature name or any internal terminology.
2. Identify the job the customer was trying to do before this feature existed, and what they were using (workarounds, other tools, manual steps) to get it done.
3. Flag any assumptions I seem to be making about the problem that I should validate before writing messaging.

Why this prompt first: Messaging built on a correctly framed problem is always sharper than messaging built on a feature description. Most teams skip this step.

I need to identify the right audience for this launch.

Feature: [name and description]
Current users: [who uses your product today, their role, company size, stage]
Who requested this feature: [persona, company type, use case]

Help me:
1. Describe the primary audience for this launch in specific terms. Not "PMs" but "PMs at 20-100 person SaaS companies who manage a single-squad roadmap."
2. Identify the secondary audience who might benefit but isn't the primary driver.
3. Name who this feature is NOT for, and why that clarity matters for messaging.
4. If there's a mismatch between who built this feature and who will actually use it, flag it.

Why this matters: Messaging written for everyone converts no one. Knowing the "not for" is as useful as knowing the "for."

I want to write the single sentence that captures what this feature does, for whom, and why it matters. This will anchor all other messaging.

Feature: [name and description]
Problem it solves: [from Prompt 1]
Primary audience: [from Prompt 2]
The outcome the customer gets: [what changes in their work or life]

Draft 5 versions of a one-sentence value statement. Each version should:
- Start with the customer outcome, not the feature
- Avoid the words "easy," "simple," "powerful," "robust," "seamless"
- Be specific enough that a competitor couldn't claim it verbatim
- Be short enough to say out loud in one breath

Then tell me which one you'd use and why.

Why one sentence: If you can't say it in one sentence, you can't say it in ten. Start here.

I want to map the concrete before-and-after experience for the customer this feature is built for.

Feature: [name]
Primary audience: [specific persona]
Their workflow before this feature: [describe the steps they took, tools they used, workarounds they relied on]
Their workflow after: [describe what changes with this feature in place]

Give me:
1. A side-by-side before/after table. Rows should be specific workflow steps, not abstractions. "Exported data to CSV, cleaned it in Sheets, pasted into Notion" not "manual process."
2. The single biggest friction point that disappears.
3. The single most visible change the customer will notice in the first week.
4. Any second-order benefits that are real but less obvious.

Use the table directly: This before/after often becomes the backbone of your announcement email, sales deck update, and onboarding copy.

I'm deciding whether to launch this feature now or wait.

Feature: [name, current completion state]
What's working: [what's been tested, any early user feedback]
What's not ready: [known gaps, rough edges]
External pressure to launch: [sales commitments, competitor moves, investor expectations, marketing calendar]
Internal pressure: [engineering wants to ship, team morale, roadmap pressure]

Help me think through:
1. What's the minimum viable launch state for this feature? What must be true before we ship to anyone?
2. What are the real risks of launching now vs. waiting 2-4 weeks?
3. Is there a partial launch (beta, waitlist, limited rollout) that lets us learn faster without a full public commitment?
4. What's the honest cost of delay vs. the honest cost of a rough launch?

Don't optimize for speed. Optimize for what's right for the customer receiving this.

Use this before setting a ship date. Most launch regrets come from timing decisions made under pressure without thinking them through.

I'm launching a feature and I want to be ready to frame it for investors if it comes up.

Feature: [name and description]
Why we built it: [strategic reason, not just customer request]
What it signals about our direction: [what this feature reveals about our thesis or wedge]
Any early signals of traction: [usage, feedback, waitlist, sales conversations]

Help me answer:
1. How does this feature advance the product's strategic position? (Not just "it makes customers happier" but what it means for moat, retention, expansion, or competitive differentiation.)
2. What does building this well demonstrate about the team's judgment?
3. How would I mention this in an investor update in 2 sentences that are interesting, not just informational?
4. What follow-on metrics should I commit to tracking so I can report on this feature's actual impact in 60 days?

PMs rarely think about launch framing for investors. This prompt closes that gap in 10 minutes.

Write a product announcement email for the following feature launch.

Feature: [name and description]
One true sentence: [from Prompt 3]
Before/after: [key points from Prompt 4]
Primary audience: [persona from Prompt 2]
Tone: [pick one: direct and confident / warm and personal / technical and precise]
CTA: [what you want them to do: try the feature, watch a demo, book a call]

Requirements:
- Subject line options: give me 4, each taking a different angle (problem-first, outcome-first, curiosity, direct)
- Email body: under 200 words
- No buzzwords. No "excited to announce." No "we're proud to introduce."
- Open with the problem or the customer, not the company
- One clear CTA at the end
- Optional P.S. line that adds context or creates urgency without being manipulative

My messaging for this feature feels vague. I want to diagnose why and fix it.

Here is my current positioning draft: [paste your draft]
Feature: [name]
Product: [what it does, who it's for]

Do three things:
1. Identify every sentence that could be said by a competitor without changing a word. Mark them as "generic."
2. Find the most specific, differentiated claim in my draft. Expand on it.
3. Rewrite the positioning in 3 sentences that are specific enough to be wrong. (If a claim can't be wrong, it's not saying anything.)

The "specific enough to be wrong" test: If your positioning is unfalsifiable, it's just noise. This prompt cuts through fast.

Write 4 social post variations for this feature launch.

Feature: [name and description]
One true sentence: [from Prompt 3]
Primary audience: [persona]
Key before/after: [one sentence version of the transformation]
Tone: [founder voice / product voice / educational]

Each variation should take a different angle:
1. Lead with the customer problem
2. Lead with the before/after transformation
3. Lead with a contrarian observation about how most teams handle this
4. Lead with a concrete example or mini-story (no fabricated quotes or stats)

Format requirements:
- Under 220 words each
- No hashtag stuffing (0-2 max)
- No "Excited to share" openers
- Each post ends with a CTA or open question that invites response

Write in-app announcement copy for a new feature. This will appear as a modal or tooltip the first time a user encounters it.

Feature: [name and what it does]
Where it appears in the product: [specific location, workflow context]
User context: [what the user was just trying to do when they see this]
One thing we want them to do: [the single action we want them to take]

Write:
1. Headline: under 10 words, outcome-focused
2. Body: 1-2 sentences max. Explain the feature in plain English as if talking to someone in their first week using the product.
3. Primary CTA button: 3-5 words
4. Dismiss link text: something that isn't just "Close" or "No thanks" but doesn't guilt-trip either

Avoid: passive voice, exclamation points, the word "new," any claim that can't be verified in the first 30 seconds of use.

I need to arm my sales team (or myself, if I'm founder-selling) with talking points for this feature in active sales conversations.

Feature: [name and description]
Primary use case: [what it solves for]
Typical buyer persona: [role, company size, context]
Common objection this feature addresses: [e.g., "we already do this in Notion" or "we don't have the bandwidth to set this up"]

Give me:
1. A 30-second verbal summary for a discovery call (not a pitch, a description that opens conversation)
2. 3 qualifying questions a rep can ask to see if this feature matters to the prospect
3. 2-3 objection responses that are honest, not spin
4. One concrete example of a before/after scenario to make this real (use a plausible hypothetical, not a fabricated customer name)

Write a changelog entry for this feature.

Feature: [name]
What it does: [functional description]
Who it's for: [persona]
Any known limitations or edge cases: [be honest]
Link to docs or demo: [optional]

Requirements:
- Lead with what changed for the user, not what the engineering team did
- 3-5 sentences max
- Use plain language. If someone has to know internal terminology to understand it, rewrite it.
- If there are limitations, note them briefly. Customers trust changelogs more when they're honest about edges.
- End with a link or action if relevant

Changelogs are underrated trust-builders. The teams that write honest, readable changelogs get more upgrade conversations than the ones treating it as a legal obligation.

Write a short landing page section (or standalone feature page) for this launch.

Feature: [name]
One true sentence: [from Prompt 3]
Primary audience: [persona from Prompt 2]
Top 3 benefits: [specific outcomes, not feature bullets]
Social proof available: [testimonials, case studies, early adopter quotes -- leave blank if none yet]
CTA: [what happens when they click]

Structure:
1. Headline (under 12 words, outcome or problem-focused)
2. Subhead (1 sentence expanding the headline)
3. 3 benefit statements in parallel structure, each under 20 words
4. Optional: a "before/after" or "how it works" 3-step explanation
5. CTA button text + supporting line under it ("No credit card required" / "Takes 5 minutes to set up" -- only if true)

Do not use: "powerful," "robust," "world-class," "next-generation," or any claim that isn't provable in the product.

I'm preparing to launch a feature. Help me build a launch checklist tailored to our situation.

Team size: [solo / 2-5 / 5-20 / 20+]
Channels we use: [list: email, LinkedIn, X, Product Hunt, changelog, in-app, press, community, sales outreach, investor update]
Launch timeline: [number of days until launch]
Feature complexity: [simple update vs. major new capability]

Generate a pre-launch, launch-day, and post-launch checklist. For each item:
- State what it is
- State who owns it (use role, not name)
- State the minimum viable version of it (what's the simplest version that's good enough)

Flag any items that are commonly skipped but actually matter.

Write an internal brief for this feature launch that I can share with my team before we ship.

Feature: [name]
What it does: [functional description]
Why we built it: [strategic or customer reason]
Primary audience: [persona]
Launch date: [date or "TBD"]
Channels: [where we're announcing]
Owner: [who is responsible for the launch]

The brief should cover:
1. Feature summary (3 sentences, written for someone who hasn't been in every product review)
2. Why now (the timing rationale)
3. What success looks like in 30 days (name the metric, not the vibe)
4. What each team needs to do differently once this is live (support, sales, customer success)
5. Known limitations and the honest thing to say when a customer hits one
6. Who owns launch day and how to reach them

Keep it under one page. Write it for someone who will skim it once, on a Monday, between two other meetings.

Why this matters: The internal brief is the cheapest alignment tool you have. Most launches go sideways because support heard about the feature from a customer.

Help me get ahead of the questions this launch will generate.

Feature: [name and what it does]
Who gets access: [all users / a segment / opt-in]
What changes for existing users: [describe, including anything that moves, breaks, or looks different]
Known limitations: [list what it does not do yet]
Pricing impact: [none / included / paid add-on]

Give me:
1. The 10 questions users are most likely to ask in the first week, ordered by how often you expect them.
2. A plain answer to each, written for a support reply, not a marketing page. No hedging.
3. The 3 questions we do not have a good answer to yet. Those are the ones I need to decide on before launch, not during.
4. The questions most likely to be asked angrily rather than curiously, and what the underlying concern actually is.

Why this matters: Every question you answer in advance is a support ticket that never happens and a user who never got stuck.

Help me design the rollout for this feature and decide in advance what would make us stop.

Feature: [name and description]
Risk profile: [what breaks if this goes wrong: data, billing, a core workflow, cosmetic only]
User base size: [rough number]
Ability to roll back: [instant flag / requires a deploy / one-way migration]
Monitoring in place: [what you can actually see in real time]

1. Recommend a rollout sequence for my risk profile (internal, alpha group, percentage ramp, full release) with a rough duration for each stage.
2. For each stage, what specifically am I watching, and what number tells me to proceed rather than a general feeling that it seems fine?
3. Define the kill criteria in numbers: what result at what threshold means we pause or roll back, no meeting required?
4. Name the failure mode I am least likely to catch with the monitoring I described.
5. If rollback is not clean for this feature, tell me what to do differently before I start the ramp at all.

Why this matters: Kill criteria written before launch are a decision. Written during an incident, they are a negotiation with your own ego.

Run a pre-mortem on this launch.

Feature: [name and description]
Launch plan: [paste the checklist, the rollout plan, and the channels]
Team size and who is involved: [describe]
What we are assuming has to go right: [list what you know of]

It is 30 days after launch. The launch failed. Not dramatically, just quietly: low adoption, no momentum, nobody talks about it again.

1. Write the 5 most plausible explanations for why. Be specific to my plan, not generic launch advice.
2. For each one, tell me what signal would have warned me in advance, and whether my current plan would catch it.
3. Which of these five is the most likely, and which is the most expensive?
4. What is the cheapest change I can make to the plan this week that reduces the odds of the most likely one?
5. Tell me the uncomfortable one: is there a version of this failure where the feature is fine and the problem is that nobody needed it?

Why this matters: A pre-mortem gives people permission to say the doubt they already have. That doubt is usually correct and usually unsaid.

Help me write the section of my investor update covering this launch.

Feature: [name and what it does]
Why we built it: [the strategic reason]
Results so far: [paste real numbers: adoption, activation, retention, revenue impact, qualitative feedback. Include the disappointing ones.]
Time since launch: [days or weeks]
What we learned: [anything you already know]

1. Write the update in 150 words or less. Lead with what we learned, not what we shipped.
2. Present the numbers honestly, including the weak ones. Do not editorialize a flat metric into a promising signal.
3. Connect this launch to the thesis we told investors last time. If it does not connect, say so plainly rather than inventing a link.
4. Anticipate the two questions a sharp investor will ask about these numbers, and tell me whether I have the answers.
5. Flag anything in my draft that sounds like traction but is actually just activity.

Why this matters: Investors track the gap between what you claimed and what happened. Reporting a weak result accurately buys you more credibility than a good result spun well.

Help me run the debrief on this launch so the next one is better.

Feature: [name]
What we predicted would happen: [the success criteria you wrote before launch]
What actually happened: [the real numbers and the real reactions]
What we did: [the plan you ran, the channels, the sequence]
What surprised us: [anything you did not see coming, good or bad]

1. Where was the gap between prediction and reality largest? What does that gap say about how we think, rather than about this feature?
2. Which parts of the plan actually moved the outcome, and which were motion we would not miss if we skipped them next time?
3. If the launch went well, tell me why, specifically enough to repeat it. "Good execution" is not an answer.
4. Write the 3 lessons as instructions to our future selves, phrased so someone could follow them without having been here.
5. Name the one thing we will do differently next launch. One. Not a list nobody reads.

Why this matters: Teams debrief failures and celebrate wins. The wins are where the repeatable process hides, and nobody writes it down.