DEV Community: draftkit

10 AI Prompts I Use for Operations (SOPs, Process Docs, Incident Response, Vendor Management)

draftkit — Thu, 30 Jul 2026 20:13:59 +0000

If you've ever spent a Friday night writing an SOP that nobody reads, this is for you.

Operations leaders spend 60% of their writing time on documents that exist to prevent chaos — SOPs, process docs, incident reports, vendor scorecards, onboarding checklists. Most of these follow a predictable structure, which means they're perfect candidates for AI assistance.

The problem: generic AI prompts produce generic ops docs. "Write an SOP for onboarding" gives you a template that could apply to any company in any industry. Useless.

Over the last year I've refined a set of prompts that produce operational documents my team actually uses. Each one forces specific constraints, real examples, and a structure that survives a real operational scenario. Here are 10 of the best.

Want all 200+ prompts I use across my entire business? I packed them into the Developer Productivity Prompt Library — 30 tested prompts for shipping faster. Or grab the SaaS Marketing Copy Prompt Pack if you need customer-facing copy.

How these prompts are structured

Every prompt below uses the same four-part framework:

Role — who the AI is acting as
Context — the specific situation
Constraints — what it can and cannot do
Output — the exact format

This isn't prompt "engineering." It's just being specific. But the constraints are where the magic happens — they're what separate a document your team uses from one they ignore.

1. The SOP That Doesn't Get Skipped

You are an operations manager documenting a repeatable process.

Process: [INSERT PROCESS NAME — e.g., "Provisioning a new hire's laptop and accounts"]
Audience: [INSERT — e.g., "IT admin with 2 weeks of tenure"]

Write a step-by-step SOP with these rules:
- Number every step. No step may be longer than 2 sentences.
- Every step must start with a verb (Click, Open, Send, Verify...).
- If a step requires a decision, write it as: "IF [condition] THEN [action] ELSE [action]"
- After every 5 steps, add a "Checkpoint:" line stating what should be true at that point.
- End with a "This is wrong if:" section listing 3 failure modes.
- Do NOT include an introduction, background, or "why this matters." The reader is mid-task.

Output format: Plain numbered list. No headers except "Checkpoint:" and "This is wrong if:".

Why it works: The "every 5 steps" checkpoint forces the reader to verify they're on track before continuing. The "This is wrong if" section is more valuable than the happy path — it's what people actually reference when something breaks.

2. Incident Response Runbook from a Messy Slack Thread

You are a senior ops engineer turning a chaotic Slack incident thread into a runbook.

Paste the Slack thread below. Transform it into a runbook with:

[SLACK THREAD]

Rules:
- Extract only actions that someone took or should take. Discard all reactions, jokes, and "looking into it" messages.
- Group actions into phases: Detect → Triage → Mitigate → Resolve → Postmortem.
- Each action must include: WHO did it, WHAT they did, and the TIMESTAMP.
- If an action was wrong (someone tried something that didn't work), include it in a "Dead ends" section — these are lessons, not waste.
- Add a "Trigger conditions" section at the top: what symptoms should cause someone to open this runbook?
- The first line must be: "If [specific symptom], do step 1 immediately. Do not read the rest first."

Output: Markdown with phase headers. Keep it under 400 words.

Why it works: Most incident docs are written after the fact and describe what happened. This prompt produces a document that tells the next responder what to DO — including the dead ends, which are the most valuable lessons.

3. Vendor Scorecard That Forces a Decision

You are a procurement lead creating a vendor evaluation scorecard.

We are evaluating vendors for: [INSERT CATEGORY — e.g., "Customer support ticketing"]
Our must-haves: [LIST 3-5]
Our nice-to-haves: [LIST 3-5]
Budget range: [INSERT]
Team size: [INSERT]

Create a scorecard with:
- Exactly 8 criteria, weighted to total 100 points.
- No single criterion may exceed 20 points (prevents one factor dominating).
- At least 2 criteria must be "risk" criteria (e.g., data portability, vendor lock-in, financial stability).
- For each criterion, write a 1-sentence definition of what a 5/5 looks like AND what a 1/5 looks like.
- End with a "Decision rule:" line — e.g., "If total ≥ 70 AND no risk criterion scores below 3, proceed to contract negotiation."

Do not include a summary, conclusion, or recommendation. The scorecard is the output.

Why it works: The forced weighting (no single criterion > 20 points) prevents the "one shiny feature" bias. The decision rule removes the post-scoring debate. The risk criteria ensure you're not just optimizing for features.

4. Onboarding Checklist That Prevents Day-1 Chaos

You are an ops manager creating a new-hire onboarding checklist for Day 1 through Day 30.

Role: [INSERT ROLE — e.g., "Junior Backend Engineer"]
Start date: [INSERT]
Manager: [INSERT NAME]
Buddy: [INSERT NAME]

Create a checklist with:
- 3 phases: Day 1 (setup + intro), Week 1 (ramp), Weeks 2-4 (first contribution).
- Each item must be assigned to either: [New hire], [Manager], [IT], or [Buddy].
- Every IT item must include the specific tool/account being provisioned.
- Include exactly 3 "social" items (coffee chat, team lunch, intro to adjacent team) — no more, no less.
- Mark items that block other items with "→ blocks: [item name]".
- The LAST item must be: "30-day check-in: [Manager] and [New hire] review this checklist. Anything unfinished becomes a tracked action item."

Output: A table with columns: Item | Owner | Phase | Blocks.

Do not include welcome messages or motivational text.

Why it works: Assigning every item to a specific owner eliminates the "I thought you were doing that" gap. The blocking dependencies surface the critical path. The 30-day review creates accountability for completion.

5. Process Decision Document (One-Pager)

You are an operations lead writing a decision document for a process change.

Decision needed: [INSERT — e.g., "Should we move from manual to automated deployment?"]

Write a one-page decision doc with these EXACT sections, in order:

1. **Decision:** One sentence stating the recommendation. No hedging.
2. **Context:** 3 sentences max. What's happening, why now, who's affected.
3. **Options considered:** List exactly 3 options. For each, one sentence on what it is and one sentence on the main downside.
4. **Recommendation rationale:** Why the recommended option wins. Reference specific tradeoffs, not vibes.
5. **Cost of delay:** What happens if we don't decide in the next 2 weeks.
6. **Reversibility:** Is this decision reversible? If yes, how hard?
7. **Owner:** Who makes the final call and by when.

Rules:
- Total length: maximum 250 words including headers.
- No bullet points longer than one line.
- Do not write "In conclusion" or any closing paragraph.

Output: Markdown.

Why it works: The forced brevity (250 words) kills the tendency to write 5-page decision docs that nobody reads. "Cost of delay" creates urgency. "Reversibility" prevents analysis paralysis on low-stakes decisions.

6. Cross-Team Handoff Document

You are an ops manager writing a handoff document for work moving between two teams.

From team: [INSERT — e.g., "Engineering"]
To team: [INSERT — e.g., "Customer Support"]
Work item: [INSERT — e.g., "Bug fix #2847 — payment failure on Safari"]

Write a handoff doc with:
- A "What's done" section: exactly what was completed, with links.
- A "What's NOT done" section: explicitly list what was NOT addressed, even if it seems obvious. This prevents assumptions.
- A "Known unknowns" section: things the sending team isn't sure about and the receiving team will need to investigate.
- A "Definition of done" section: what the receiving team needs to achieve to close this out.
- A "How to reach us" section: names + channels for questions, with a note: "If no response in [SLA], escalate to [name]."

Format: Plain sections with short paragraphs. No "Dear team" or sign-offs.

The most important section is "What's NOT done" — make it longer than "What's done" if needed.

Why it works: The "What's NOT done" section is the single highest-value part of any handoff. It prevents the receiving team from assuming work was completed when it wasn't. "Known unknowns" gives them permission to investigate without feeling like they missed something.

7. Postmortem Template That Finds Root Cause (Not Blame)

You are facilitating a blameless postmortem for an operational incident.

Incident: [INSERT — e.g., "Checkout was down for 47 minutes on Tuesday"]
Impact: [INSERT — e.g., "~$12K in lost revenue, 340 failed checkouts"]

Write a postmortem document with:

1. **Timeline:** Minute-by-minute from first alert to resolution. Only facts. No "we should have."
2. **Impact:** Quantified. If you can't quantify it, say "Impact unknown — needs measurement" and add a follow-up action.
3. **Root cause(s):** Use the "5 Whys" method. Each "why" must point to a system, process, or tool — NEVER a person. If you find yourself writing "because [person] didn't...", rephrase to "because the process didn't ensure..."
4. **What went well:** At least 2 things that worked during the response.
5. **What went poorly:** At least 2 things that failed.
6. **Action items:** Each action item must have: an owner, a due date, and a priority (P0/P1/P2). No action item may be "improve monitoring" — it must be specific (e.g., "Add alert for checkout latency > 2s, owned by [name], due [date]").

Rules:
- The word "should" is banned. Replace every instance with a specific action item.
- Maximum 1 page.

Output: Markdown.

Why it works: Banning "should" forces every observation into an actionable item. The 5-Whys rule that points to systems (not people) produces blameless analysis that actually surfaces root causes. The "improve monitoring" ban kills the most common useless action item.

8. Meeting Notes That Become Decisions (Not Transcripts)

You are an ops manager converting meeting notes into a decision log.

Raw notes:
[PASTE NOTES]

Transform into a structured doc with:

1. **Decisions made:** List each decision as: "We decided to [action], because [reason], effective [date]." If a decision has no reason recorded, write "Reason: NOT RECORDED — follow up with [likely attendee]."
2. **Decisions deferred:** Things that were discussed but NOT decided. Each must have: "Owner: [name], Revisit by: [date]."
3. **Action items:** Owner + task + due date. Separate from decisions.
4. **Open questions:** Things raised that nobody could answer. Each with an owner to investigate.

Rules:
- No verbatim quotes unless they contain a commitment.
- No "we discussed" or "we talked about" — only outcomes.
- If a section is empty, write "None" — do not omit it.

Output: Markdown table where possible.

Why it works: Meeting notes that capture what was discussed are useless. This prompt extracts only what was decided and what was deferred — the two things people actually need after a meeting. The "NOT RECORDED" flag surfaces gaps immediately.

9. Compliance/Audit Evidence Checklist

You are an ops lead preparing for a [INSERT FRAMEWORK — SOC 2 / ISO 27001 / HIPAA / GDPR] audit.

Scope: [INSERT — e.g., "Access control and change management"]
Systems in scope: [LIST]

Generate an evidence checklist with:
- Each control mapped to the specific framework requirement (cite the section/number).
- For each control, list the evidence type needed: Policy doc | System config screenshot | Log export | Signed approval | Ticket reference.
- Group by evidence type so the team can collect efficiently (don't jump between policy docs and log exports).
- Mark controls that are "new since last audit" with 🆕 — these need extra preparation.
- Add a "Gap" column: if we don't currently have this evidence, mark it and assign an owner.

Do not write explanatory text about what the framework is. The auditor already knows.

Output: Table with columns: Control | Framework Ref | Evidence Type | Status | Owner.

Why it works: Audit prep fails when evidence collection is ad hoc. Grouping by evidence type (all policy docs together, all log exports together) cuts collection time dramatically. The 🆕 flag prevents the classic mistake of assuming last year's evidence still applies.

10. Quarterly Operations Review (For Leadership)

You are an operations lead writing a quarterly ops review for the leadership team.

Quarter: [INSERT]
Team: [INSERT]

Write a review with these sections — and ONLY these sections:

1. **Metrics that moved:** 3-5 key metrics. For each: the number, the change vs last quarter, and ONE sentence on why it moved. No vanity metrics (e.g., "tickets closed"). Only outcome metrics (e.g., "mean time to resolution").
2. **What we shipped:** Operational improvements deployed this quarter. Each in one line. No "ongoing work" — only completed.
3. **What broke:** Incidents or failures this quarter. Each with: root cause (one sentence) and the fix deployed.
4. **What we're stopping:** At least 1 process, tool, or meeting that we're killing next quarter. If you can't think of one, write "Nothing — review whether we're accumulating cruft."
5. **Next quarter's bet:** ONE operational initiative for next quarter. Not a list. One bet, with a success metric and a kill criterion.

Rules:
- Total length: 1 page max.
- No "strategic alignment" or "synergy" language.
- The leadership team skims. Put the most important number first.

Output: Markdown.

Why it works: The "What we're stopping" section is the most powerful — it forces operational hygiene and prevents process accumulation. "One bet with a kill criterion" prevents the laundry-list approach where 12 initiatives get 10% effort each.

How I test these prompts (before trusting them)

I don't trust a prompt until it survives three tests:

Run it 3 times with the same inputs. If the outputs vary wildly, the prompt is too vague. Tighten constraints.
Swap in a different context (e.g., change "backend engineer onboarding" to "sales rep onboarding"). If the structure breaks, the prompt is overfit to one scenario.
Read it aloud. If the output sounds like it could apply to any company, it's too generic. Add company-specific constraints.

The prompts above have survived all three. Your mileage will vary — adapt the constraints to your team's reality.

The prompt system I actually use

These 10 prompts are a slice of the system I run across my entire business — operations, engineering, marketing, sales, and product. I've packaged the full set into a few resources:

Developer Productivity Prompt Library ($49) — 30 prompts for shipping code faster. If you're technical, start here.
SaaS Marketing Copy Prompt Pack ($49) — 25 prompts for landing pages, cold emails, and ad copy.
AI Startup Operations Prompt System ($199) — 50+ prompts + 10 workflows. This is the one ops leaders grab.
Developer Product-Launch Prompt Pack ($9) — the $9 starter, 7 prompts for shipping a launch.

Or browse the full store and pick what fits.

If you want a custom prompt system built for your specific business — your tools, your team, your workflows — reach out. I build those for founders who don't want to spend 6 months figuring out prompt constraints.

What operational document do you spend the most time on? Drop it in the comments — I'll share the prompt I use for it.

10 AI Prompts I Use for FP&A (Budgets, Forecasts, Variance Analysis, Board Decks)

draftkit — Thu, 23 Jul 2026 21:26:38 +0000

I spent three years in FP&A before AI was useful. The job hasn't changed — you still own the budget cycle, the monthly close review, the quarterly board deck, and the annual operating plan. What changed is the writing around the numbers. Every variance needs a narrative. Every forecast needs assumptions documented. Every board meeting needs a summary a non-finance executive can read in 90 seconds.

These 10 prompts handle that writing layer. I've tested each one at least three times against real financial scenarios. They don't replace your model — they replace the hour you spend explaining what the model already told you.

Testing method: I run each prompt 3 times with the same inputs. If the output varies wildly, the prompt is too vague. I generalize it by removing specifics and re-testing on a different business. I read it aloud — if it sounds like a template, I cut the generic parts.

1. The Budget Memo (Forces Prioritization, Not Just Numbers)

Role: You are an FP&A manager writing a budget memo for the leadership team.
Context: I'm giving you next year's department budget request with the prior-year actuals and the variance justification. The audience is the CFO and department heads who will push back on line items.
Constraints:

Start with the ONE number that matters most (total, delta vs. prior year, or % of revenue — your call based on what's most defensible).
Group line items into max 4 categories. Do not list individual line items under $5K.
For each category, state the driver in one sentence (headcount, software, contractor, travel).
Include a "What we'd cut first" section — 3 items ranked by impact-to-cost ratio. This pre-empts the inevitable CFO question.
Do NOT use the words "strategic investment," "capability building," or "operational excellence."
Max 400 words.

Example input:

Prior year actuals: Engineering $1.2M, Sales $800K, G&A $400K
Next year request: Engineering $1.5M (+25%), Sales $950K (+19%), G&A $420K (+5%)
Key drivers: Eng hiring 3 senior engineers, Sales adding 2 AEs + SDR tools, G&A is mostly rent + accounting software.

Why it works: The "what we'd cut first" section is the unlock. CFOs ask "where can we trim?" in every budget meeting. Pre-answering it shifts the conversation from whether to cut to which cut is acceptable.

2. The Rolling Forecast Update (Assumptions Before Numbers)

Role: You are an FP&A analyst updating the rolling 12-month forecast.
Context: I'm providing the current forecast, the actuals through this month, and the changes to key assumptions (pipeline coverage, churn signals, hiring delays).
Constraints:

Section 1: Assumptions changed this month — list each as "Assumption → Old value → New value → Reason." No numbers in the forecast yet.
Section 2: Forecast impact — for each changed assumption, state the directional impact (+/-) and the magnitude range (e.g., "+$40K to +$60K to Q4 revenue"). Ranges, not point estimates.
Section 3: Confidence level — High / Medium / Low for each change, with a one-line basis.
Do NOT produce a revised P&L. That's the model's job, not the prompt's.
Flag any assumption that contradicts another (e.g., raising the close rate while lowering average deal size — are we sure both move in opposite directions?).

Why it works: Forecasting discussions derail when people argue about the output number instead of the input assumption. This prompt forces the conversation to assumptions first, numbers second.

3. Variance Explanation (The Monthly Close Narrative)

Role: You are writing the variance analysis section of the monthly financial review.
Context: I'm providing actual vs. budget for each line item, with the variance amount and whether it's favorable or unfavorable.
Constraints:

For each material variance (>5% of budget OR >$10K, whichever is lower):
- What: The line item, the variance amount, and direction.
- Why: The driver — ONE sentence. "Timing" is banned unless you specify what shifted.
- So what: The impact on the full-year forecast (will it reverse, persist, or worsen?).
Sort by absolute dollar impact, largest first.
Do NOT explain immaterial variances. Group them as "Below threshold — no action."
End with "Top 3 to watch next month" — the variances most likely to recur or compound.

Why it works: The "timing" ban is critical. "Timing" is the most overused variance explanation in FP&A — it means nothing without specifics. Forcing specificity either produces a real explanation or exposes that nobody knows the actual driver.

4. Board-Ready KPI Summary (90 Seconds, Not 9 Minutes)

Role: You are preparing the KPI summary slide for the upcoming board meeting.
Context: I'm providing 8-12 KPIs with this month's value, prior month, prior year, and target.
Constraints:

Output is a single slide — max 6 KPIs. You choose which 6 matter most for a board audience (growth, unit economics, runway, not operational minutiae).
For each KPI: the number, the delta vs. prior period (with direction arrow), and a 6-word max annotation.
The annotation must be a takeaway, not a description. "Revenue $4.2M ↑12%" is a description. "Revenue beat target, driven by enterprise expansion" is a takeaway.
Group into max 3 sections (e.g., Growth, Efficiency, Health).
Do NOT include any KPI the board has never seen before without a one-line definition. If you must include a new metric, define it inline.
End with "One number the board will ask about:" — predict the single metric that will generate the most discussion and pre-answer it.

Why it works: Board members read slides in 10 seconds. The annotation constraint forces you to pre-digest each KPI into a takeaway, which means the board meeting discusses the implication instead of spending 5 minutes just understanding what the numbers are.

5. Investor Update (The Monthly Email VCs Actually Read)

Role: You are writing the monthly investor update email.
Context: I'm providing the key metrics, wins, challenges, and asks for this month.
Constraints:

Subject line: "Month Year Update — [Company]" — no clever subject lines.
Section 1: TL;DR — 2 sentences max. What happened, what's next.
Section 2: Metrics — table format. Metric / This month / Last month / Change. Max 5 metrics.
Section 3: Highlights — max 3 bullet points, each starting with a verb.
Section 4: Lowlights — max 3 bullet points. This section must NOT be shorter than Highlights. If it is, you're hiding something.
Section 5: Asks — specific requests (intros, hiring, advice). Each ask is one line with the context embedded.
Do NOT use "continuing to," "making progress on," or "excited about." These are filler.
The email must be readable in under 90 seconds. If it's longer, cut.

Why it works: The Lowlights ≥ Highlights constraint is the most important one. Investors pattern-match for founders who only share good news — it signals either naivety or dishonesty. Equal-weighted lowlights build trust and actually generate more helpful responses.

6. The Scenario Analysis Memo (Best Case / Base Case / Worst Case)

Role: You are writing a scenario analysis memo for the leadership team.
Context: I'm providing the base case forecast, the key uncertainties (demand, pricing, hiring, churn), and the time horizon.
Constraints:

Define 3 scenarios: Upside, Base, Downside. Do NOT call them "optimistic / realistic / pessimistic" — those words carry emotional weight that biases the reader.
For each scenario:
- Trigger: What has to be true for this scenario to play out? (2-3 conditions)
- Impact: Revenue range, expense range, cash runway impact.
- Probability: Your estimate with a one-line basis. Must sum to ~100% across all three.
Do NOT produce full P&Ls for each scenario. Ranges only.
End with "Monitoring signals" — the 3 metrics that would tell you which scenario is materializing, and the threshold for each that would trigger a re-forecast.

Why it works: The trigger conditions are the unlock. Most scenario analyses just present three number sets with vague labels. Specifying what would have to be true makes the scenarios testable — you can check each month whether the upside or downside triggers are firing.

7. The Headcount Plan Narrative (For the Hiring Committee)

Role: You are writing the headcount plan justification for the hiring committee.
Context: I'm providing the requested hires (role, level, team, target start date), the business rationale, and the budget impact.
Constraints:

Section 1: Summary table — Role / Team / Q-hire / Annual cost / Priority (P0/P1/P2).
Section 2: For each P0 role (must-haves), write a 2-sentence justification: (a) what this person unblocks, (b) what happens if we delay by one quarter.
Section 3: Phasing — which roles can start in Q1 vs. Q2 vs. Q3. Group by dependency, not by team.
Section 4: Risk — the 2 roles where we have the highest risk of not filling (scarce talent, comp gap, etc.).
Do NOT justify headcount with "we need to scale" or "to support growth." State the specific bottleneck or output that's currently capacity-constrained.

Why it works: The "what happens if we delay by one quarter" constraint forces honest prioritization. If the answer is "nothing really breaks," it's not a P0. This prompt surfaces which hires are actually urgent vs. which are nice-to-have.

8. The Cash Runway Memo (The One That Keeps You Up at Night)

Role: You are writing the cash runway analysis for the CEO and board.
Context: I'm providing current cash balance, monthly burn rate, revenue forecast, and planned fundraising timeline.
Constraints:

Section 1: The number. "Current runway: X months at current burn (date zero: [month/year])." One sentence. No hedging.
Section 2: Burn trend — is burn accelerating, flat, or declining? Show the last 3 months and the forecasted next 3.
Section 3: Sensitivity — what happens to runway if revenue is 20% below forecast? What if burn is 15% above plan?
Section 4: Levers — 3 concrete cost reduction actions ranked by impact, each with the monthly savings estimate and the implementation timeline.
Section 5: Trigger — the specific cash balance or runway month at which we MUST start executing cost reductions. Not "when we get concerned" — a number.
Do NOT say "we are well-capitalized." If the runway is under 18 months, say so plainly.

Why it works: The trigger number is the unlock. Runway memos without a trigger are just status reports. A specific "at $2.5M cash balance, we begin hiring freeze" gives the CEO a decision point, not a anxiety-inducing data dump.

9. The Pricing Analysis Summary (When Sales Wants to Discount)

Role: You are writing the pricing/discount analysis for the pricing committee.
Context: I'm providing the standard price, the proposed discounted price, the deal size, the customer segment, and the competitive context.
Constraints:

Section 1: The deal economics — standard price, proposed price, discount %, annual contract value at both prices, and the lifetime value delta.
Section 2: Precedent — have we done this discount before? For which customers? What happened (did they renew at full price or did the discount stick)?
Section 3: Cannibalization risk — if other customers in this segment learn about this price, what's the exposure? Estimate the number of accounts that would demand the same discount.
Section 4: Recommendation — Approve / Reject / Approve with conditions. If "with conditions," specify them (contract length, payment terms, case-study requirement).
Do NOT recommend approval based on "strategic value" or "logo acquisition" without quantifying it.

Why it works: The cannibalization section is the most valuable. Discounts rarely stay isolated — they become the new benchmark. This prompt forces the pricing committee to think about the second-order effect, not just the single deal.

10. The Annual Operating Plan Kickoff Memo (Setting the Frame Before the Grind)

Role: You are writing the AOP kickoff memo to department heads.
Context: I'm providing the company-level targets (revenue, growth, margin), the timeline, the key assumptions, and the process for department submissions.
Constraints:

Section 1: The targets — revenue, gross margin, operating income, headcount. Each with a one-line "why this number" (market context, board expectation, prior-year trajectory).
Section 2: Key assumptions — the 5 assumptions that will most impact the plan (pricing, churn, hiring velocity, market growth, FX). State each with the current assumption and the range of uncertainty.
Section 3: Timeline — submission dates, review dates, lock date. Max 5 dates. No Gantt charts in a memo.
Section 4: What's different this year — the 2-3 things that changed from last year's process. If nothing changed, say "Same process as last year" and explain why stability is intentional.
Do NOT tell department heads to "be ambitious but realistic." That's meaningless. Tell them the specific tension to resolve (e.g., "We're targeting 30% growth but capping headcount at 15% — your plan needs to show how output per head improves").

Why it works: The "what's different this year" section prevents autopilot budgeting. If the process is identical to last year, people will copy-paste last year's submission. Forcing an explicit statement of either change or intentional stability resets the framing.

How These Prompts Fit Together

These 10 prompts cover the full FP&A communication cycle:

Prompt	When	Audience
Budget memo	Annual	Leadership team
Rolling forecast	Monthly	FP&A + CFO
Variance analysis	Monthly close	Department heads
KPI summary	Board meetings	Board
Investor update	Monthly	Investors
Scenario analysis	Quarterly	Leadership team
Headcount plan	Hiring cycles	Hiring committee
Cash runway	Monthly	CEO + board
Pricing analysis	Deal reviews	Pricing committee
AOP kickoff	Annual	Department heads

The pattern across all of them: force the takeaway before the data. Every FP&A document has the same failure mode — a wall of numbers with no interpretation. These prompts front-load the "so what" and push the numbers to a supporting role.

The Testing Method (So You Can Adapt These)

Run 3 times with the same input. If outputs diverge significantly, the prompt has too much degrees of freedom — tighten the constraints.
Generalize by testing on a different business model. A prompt that works for SaaS but breaks for e-commerce is too specific.
Read aloud. If it sounds like a Mad Libs template, cut the generic scaffolding. The prompt should produce output that sounds like you wrote it, not like a form was filled in.
Cut anything generic. "Provide a comprehensive analysis" is not a constraint — it's filler. Every constraint should be something the output would get wrong without it.

If you found these useful, I've packaged 50+ prompts for startup operations — finance, hiring, sales ops, and growth — into a complete system:

Developer Product-Launch Prompt Pack — 7 prompts for shipping products faster ($9)
Developer Productivity Prompt Library — 30 prompts for engineering workflows ($49)
SaaS Marketing Copy Prompt Pack — 25 prompts for marketing that converts ($49)
AI Startup Operations Prompt System — 50+ prompts + 10 workflows for running a startup with AI ($199)
AI Business Transformation Playbook — 100+ prompts + 12 workflows, the complete system ($999)

👉 View all products →

What FP&A prompts have worked for you? I'm always testing new scenarios — drop a comment if there's a use case you want me to tackle next.

10 AI Prompts I Use for Technical Recruiting (JDs, Screen, Interviews, Debrief)

draftkit — Thu, 23 Jul 2026 20:51:09 +0000

I've sat on both sides of the technical hiring table — as a candidate and as the one making the call. The hardest part of recruiting was never the decision. It was the writing: the job description that attracts the right people, the screen that actually filters, the interview that doesn't waste anyone's time, and the debrief that doesn't turn into a vibe check.

Over the last year I've built a set of prompts that handle the tedious writing work of recruiting. Each one has a strict structure — Role → Context → Constraints → Output — and each one produces something I can actually use, not a wall of generic text. Below are the 10 I reach for most.

I sell a few prompt packs on Gumroad (Developer Product-Launch Pack, Developer Productivity Library, SaaS Marketing Copy Pack, AI Startup Operations System, AI Business Transformation Playbook) — but every prompt below works on its own. No purchase required.

1. The job description that filters OUT the wrong people

Most JDs try to attract everyone. The good ones repel the wrong candidates.

ROLE: You are a senior technical recruiter who has hired 500+ engineers.

CONTEXT: I need a job description for [ROLE]. Our team is [SIZE], stack is [STACK], and we specifically do NOT want [UNWANTED TRAIT — e.g., "agency-only background" / "people who need heavy process"].

CONSTRAINTS:
- 350 words max.
- Open with one sentence about the actual problem the hire will solve (not "we are a fast-growing company").
- Include a "You will NOT enjoy this role if..." section with 3 honest disqualifiers.
- List must-haves (max 5) and nice-to-haves (max 3) as separate bullet groups.
- Ban these words: "rockstar", "ninja", "fast-paced", "wear many hats", "passionate".
- End with a one-line application instruction that requires a specific action (not "send resume").

OUTPUT: Markdown job description, ready to paste into a job board.

Why it works: The "You will NOT enjoy this role if" section is the highest-signal part — it does the filtering before a human ever reads an application. Banning the buzzwords forces concrete language.

2. Candidate screen — surface the dealbreakers in 15 minutes

The phone screen exists to find out fast whether to invest another 4 hours. This prompt builds the screen.

ROLE: You are a hiring manager who has run 1,000+ technical screens.

CONTEXT: I am screening a candidate for [ROLE]. Their resume highlights are [PASTE 3 BULLETS]. The must-haves for the role are [LIST].

CONSTRAINTS:
- Produce exactly 6 questions.
- 2 must probe the must-have skills (ask for a specific past example, not a hypothetical).
- 1 must be a dealbreaker check (the thing that, if answered wrong, ends the process — e.g., "Tell me about a time you disagreed with a technical lead's decision and what happened").
- 1 must test self-awareness ("What kind of work environment do you do your worst work in?").
- 1 must be a red-flag inverse ("What's a technology on your resume you'd be uncomfortable using in production today, and why?").
- 1 must be the candidate's question to me — give me a strong question to ask that reveals how they think about the role.
- For each question, include a 1-line note on what a GOOD answer sounds like and what a RED FLAG answer sounds like.

OUTPUT: Numbered list. Question → good-signal → red-flag, repeated 6 times.

Why it works: The "self-awareness" and "red-flag inverse" questions are the ones that actually separate senior from junior thinkers. Forcing good/red-flag notes means anyone on the team can run the screen consistently.

3. Interview prep packet for the panel

ROLE: You are a hiring coordinator who prepares interview panels.

CONTEXT: Candidate is interviewing for [ROLE]. Resume: [PASTE]. The panel has [N] interviewers across [FUNCTIONS — e.g., coding, system design, behavioral, cross-functional]. Total interview time: [DURATION].

CONSTRAINTS:
- Assign each interviewer a distinct area (no two people cover the same ground).
- For each interviewer: give their focus area, 2 suggested questions, 1 thing to listen for, and 1 thing to avoid (common bias in that area).
- Flag 2 resume claims that need verification (the most impressive-sounding ones — those are where exaggeration hides).
- End with a "panel calibration note" — 2 sentences on what a "hire" vs "no-hire" consensus looks like for THIS role specifically.

OUTPUT: One section per interviewer, then the calibration note. Max 400 words.

Why it works: Panels without prep packets ask overlapping questions and leave gaps. The "verify the most impressive claim" rule catches the inflated resume — the best-sounding bullet is statistically the most likely to be stretched.

4. Structured debrief that doesn't become a vibe check

ROLE: You are a hiring manager running a structured debrief.

CONTEXT: The panel just interviewed [CANDIDATE] for [ROLE]. I will paste each interviewer's raw notes below.

CONSTRAINTS:
- Do NOT summarize feelings ("seemed sharp"). Extract only observable signals.
- Group findings into 3 buckets: STRENGTHS (with the specific evidence cited), CONCERNS (with the specific evidence cited), and UNANSWERED (what no one tested).
- For each CONCERN, state whether it is disqualifying or coachable.
- End with a forced decision frame — NOT a recommendation. Present the decision as: "If we hire, the bet is [X]. If we pass, the risk is [Y]." Let the human decide.
- Ban these phrases: "culture fit", "great energy", "would grab a beer with", "hungry".

OUTPUT: 3 labeled buckets, then the decision frame. No verdict.

INTERVIEWER NOTES:
[PASTE]

Why it works: Debriefs go wrong when they become personality impressions. Forcing evidence-anchored buckets and a bet-vs-risk frame (instead of a recommendation) keeps the decision honest and defensible.

5. Rejection email that doesn't burn the bridge

ROLE: You are a recruiter who values candidate experience.

CONTEXT: [CANDIDATE] was rejected after [STAGE]. They were [STRONG / BORDERLINE]. One specific positive thing from the process: [SPECIFIC SIGNAL]. 

CONSTRAINTS:
- 120 words max.
- First sentence states the decision (no "thank you so much for your time" preamble — candidates hate it).
- Include ONE specific, true piece of positive feedback (never invent one — if I gave you one, use it; if not, omit the line entirely).
- If [BORDERLINE], invite them to stay connected for future roles and tell them what to strengthen.
- If [STRONG], tell them the specific role level we'd consider them for next.
- Never use: "unfortunately", "we decided to move forward with other candidates", "keep your resume on file".

OUTPUT: Email body, ready to send.

Why it works: Generic rejections damage employer brand and cost you future applicants. A specific, honest rejection — especially for borderline candidates — is how you build a talent pipeline. The banned phrases are the tell that a human didn't read the application.

6. Offer letter that survives legal + candidate read

ROLE: You are a recruiter + a cautious employment lawyer, combined.

CONTEXT: Offering [ROLE] to [CANDIDATE]. Compensation: [SALARY/EQUITY/LOCATION]. Start date: [DATE]. Reporting to: [MANAGER].

CONSTRAINTS:
- Use plain English. No clause should require a lawyer to understand.
- Structure: role + level, compensation (break out base/equity/bonus/sign-on as separate lines if they exist), start date, reporting line, then a one-paragraph "what your first 30 days look like" written in normal voice.
- Include the at-will (or equivalent) statement as its own clearly labeled sentence, not buried.
- Do NOT include: "competitive benefits package" (say the actual top 3 or omit), "exciting opportunity" (say what they'll work on), or any non-compete language unless I explicitly provide it.
- End with a single clear acceptance instruction.

OUTPUT: Offer letter, ready to send. Max 400 words.

Why it works: Offer letters fail when they're either too vague to be useful or so legalistic they scare the candidate. Plain English + the "first 30 days" paragraph is what makes a candidate say yes — it proves someone thought about them as a person, not a headcount.

7. The "is this level right" calibration doc

ROLE: You are a compensation + leveling specialist.

CONTEXT: I'm calibrating a level for [ROLE] at a [STAGE — seed/Series A/etc.] company. I have [N] incumbents at adjacent levels. Their scope, as I'll describe: [DESCRIBE].

CONSTRAINTS:
- Output a 1-page calibration doc.
- Define the level by SCOPE OF IMPACT, not years of experience (years are a weak proxy).
- Give 4 concrete signal questions per level (Junior / Mid / Senior / Staff) — each answerable from observable work, not self-report.
- Include a "leveling trap" callout: the 2 most common mistakes people make when leveling this role at this stage (e.g., "confusing visibility with impact" or "leveling by the candidate's confidence, not the work").
- Do not cite external salary bands (I'll handle comp separately).

OUTPUT: Markdown doc, max 350 words.

Why it works: Leveling by years of experience is the #1 source of mis-leveled hires. Defining levels by observable signals — and naming the common traps — turns a fuzzy judgment into a repeatable decision.

8. Interview question that actually tests the must-have

ROLE: You are a senior engineer who has conducted hundreds of interviews.

CONTEXT: I need an interview question to test [SPECIFIC SKILL — e.g., "API design for rate limiting" / "debugging a production memory leak" / "stakeholder communication under ambiguity"]. The candidate level is [LEVEL].

CONSTRAINTS:
- The question must be answerable in [TIME — e.g., 30 minutes].
- It must have a clear "good answer" structure but NOT a single right answer (so I can tell apart memorized answers from thinking).
- Provide: the question prompt (as I'd hand it to the candidate), 3 follow-up probes that escalate difficulty, the 3 signals that indicate a strong candidate, and the 2 signals that indicate a weak one.
- Do NOT provide a "model answer" — I want signals to watch for, not a script to grade against.
- Avoid questions findable on LeetCode, Glassdoor, or common interview-prep sites.

OUTPUT: Prompt → 3 probes → 3 strong signals → 2 weak signals.

Why it works: Interview questions fail when they're either too easy (everyone passes) or too scripted (candidates memorize the answer). Forcing follow-up probes and observable signals — instead of a model answer — is what separates a real assessment from a trivia test.

9. Internal promotion case — argue it for me

ROLE: You are an engineering manager writing a promotion case.

CONTEXT: I am advocating for [EMPLOYEE] to be promoted from [CURRENT] to [TARGET]. Evidence I have: [PASTE 3-5 SPECIFIC ACCOMPLISHMENTS WITH IMPACT]. The promotion committee cares about [CRITERIA — scope, autonomy, impact, mentorship].

CONSTRAINTS:
- Structure as: Summary (2 sentences) → Scope of impact (with the evidence I gave, each tied to a criterion) → Growth signal (what changed in how they work, not just what they shipped) → Risk of not promoting (retention + what they're already doing above level).
- Every claim must trace to specific evidence I provided. Do NOT invent metrics.
- If any criterion has NO evidence from me, explicitly write "EVIDENCE GAP: [criterion] — needs a specific example" rather than padding.
- Ban: "exceeds expectations", "gone above and beyond", "consistently delivers", "key contributor".

OUTPUT: Promotion case, max 300 words, ready to submit to committee.

Why it works: Promotion cases get rejected when they're full of adjectives and short on evidence. Forcing every claim to trace to provided evidence — and explicitly flagging gaps instead of padding them — is what gets cases approved.

10. Hiring plan that a finance partner can read

ROLE: You are a head of talent writing a hiring plan for finance sign-off.

CONTEXT: I need to hire [N] people across [ROLES] over [TIMEFRAME]. Budget envelope: [AMOUNT or "TBD — give me the range"]. Business reason: [WHY — e.g., "shipping the v2 product" / "replacing contractor spend" / "entering a new market"].

CONSTRAINTS:
- One-page plan. Sections: Why now (business trigger), The roles (table: role / level / why-this-level / target start), Sourcing strategy (2 channels per role, with why), Sequencing (which hire unlocks the next), Total cost (salary + recruiter + ramp time, as a range), and Risks (top 2 — e.g., "market is hot for this role" / "we have no employer brand in this city").
- Do NOT promise time-to-fill numbers you can't back up — give a range with the assumption stated.
- Sequencing must explain the dependency (e.g., "Hire the senior IC before the two mids — the senior sets the bar the mids are hired against").
- Finance-readable: no recruiter jargon. If you use a term, define it inline.

OUTPUT: Markdown plan, max 500 words.

Why it works: Hiring plans die in finance review when they're vague about cost and sequencing. The "which hire unlocks the next" framing forces you to think about the order — which is usually the part that's wrong in a rushed plan.

How I test these

I run each prompt 3 times with the same inputs. If the output varies wildly, the prompt is under-specified — I add constraints until the output is stable. Then I generalize: I swap the role and run it again. If it still produces something usable, the prompt is ready.

The last step is reading it aloud. If I can't say the output out loud without cringing, it's too generic — I cut anything that sounds like it could apply to any company, any role, any candidate.

If these are useful, I keep a larger library of operationally-tested prompts for teams that want to systematize how they work — the AI Startup Operations System has 50+ prompts covering hiring, onboarding, customer support, and engineering ops, and the AI Business Transformation Playbook extends that across 12 full workflows. The Developer Productivity Library is the lighter starting point if you just want the day-to-day engineering prompts.

What prompts have changed how you hire? I'm always looking for additions to the library.

10 AI Prompts I Use for Data Analysis (SQL, Dashboards, Executive Summaries)

draftkit — Thu, 23 Jul 2026 20:13:09 +0000

Data analysts spend roughly 60% of their week on work that isn't analysis — cleaning data, writing boilerplate SQL, formatting charts for stakeholders, and translating findings into language executives can act on. AI doesn't replace the analysis itself, but it dramatically speeds up the mechanical scaffolding around it.

I've been using a set of AI prompts to compress that scaffolding time. Below are 10 prompts I use regularly, each with the exact structure (Role → Context → Constraints → Output), a real example of what it produces, and notes on where it tends to hallucinate so you know what to verify.

If you want the full collection — 50+ prompts covering analytics, operations, sales, marketing, and engineering workflows — I maintain a Developer Productivity Prompt Library ($49) and an AI Startup Operations Prompt System ($199) for teams that need a complete system.

1. SQL Query Builder from Natural Language

Most "text-to-SQL" tools generate syntactically correct but semantically wrong queries — they miss joins, assume column names, or aggregate incorrectly. This prompt forces the model to state its assumptions before writing the query.

You are a senior data analyst. I will describe a question in plain English.
Before writing SQL, output:
1. Your understanding of the question (1 sentence)
2. Every table and column you assume exists (list them)
3. Any ambiguity in the question
Then write the SQL. Use CTEs for readability. Add a comment above each CTE explaining what it does.

Question: {YOUR_QUESTION}
Schema context: {PASTE_CREATE_STATEMENTS_OR_SAMPLE_ROWS}

Example output (for "What's the 30-day retention rate for users who signed up via organic search?"):

The model lists: users (user_id, signup_date, acquisition_channel), events (user_id, event_name, event_timestamp). Flags ambiguity: "retention" can mean D30 login or D30 revenue event. Asks you to confirm. Then writes a CTE-based query with WITH cohort AS (...) SELECT ....

Where it hallucinates: column names. Always paste your actual CREATE TABLE statements or a few sample rows. Never let it guess.

2. Dashboard Design Critique

Stakeholders ask for "a dashboard" and then complain it has too many charts. This prompt forces the model to evaluate a dashboard layout against decision-making criteria — not aesthetics.

You are a BI strategist reviewing a dashboard for an executive audience.
I will describe the dashboard's current layout (charts, filters, layout).
Evaluate it against these criteria:
1. Can the viewer answer their #1 question in under 10 seconds?
2. Is there a chart that doesn't change any decision? (If yes, recommend removing it.)
3. Are the time ranges consistent across charts?
4. Is there a clear "so what" — or is it just data display?
Output: a prioritized list of changes (impact × effort), then a revised layout sketch in text.

Example output: Identifies a "funnel by channel" chart that duplicates information already in a summary table. Recommends removing it. Suggests moving the "revenue trend" chart to top-left because it answers the most frequent stakeholder question. Flags inconsistent date ranges (one chart shows trailing 7 days, another shows calendar month).

3. Anomaly Investigation (Statistical)

When a metric drops, the first instinct is to check everything. This prompt forces structured root-cause analysis.

You are a data analyst investigating an anomaly.
Metric: {METRIC_NAME} dropped {PERCENTAGE}% on {DATE}.
Normal range: {DESCRIBE_BASELINE}

Generate 5 hypotheses ranked by likelihood. For each:
1. The hypothesis (what changed)
2. The dimension to slice by (segment, channel, geography, device, etc.)
3. The query to test it (SQL or pseudo-code)
4. What result would confirm vs. rule out this hypothesis

Do not speculate without giving me a test. Every hypothesis must be falsifiable.

Example output (for "conversion rate dropped 22% on July 15"): Hypothesis 1 — payment provider outage (slice by payment_method, check error rates). Hypothesis 2 — checkout page deploy (slice by version hash). Hypothesis 3 — traffic source shift (slice by utm_source, check if a low-quality traffic source spiked). Each with a specific SQL query.

4. Executive Insight Summary

Analysts write insights that are technically correct but unreadable to executives. This prompt enforces the "inverted pyramid" — conclusion first, evidence second, detail last.

You are a data analyst writing for a VP who reads this in 45 seconds during a commute.
Convert my raw findings into an executive summary.

Rules:
- First sentence states the conclusion and the action it implies.
- No raw numbers in the first paragraph — round to the nearest meaningful unit ("roughly 1 in 4 users" not "24.7%").
- Include exactly ONE chart recommendation (chart type + what it shows).
- End with "Open question:" followed by the one thing you couldn't determine from the data.
- Ban these words: leverage, utilize, robust, granular, actionable, holistic, synergy.

Raw findings: {PASTE_YOUR_NOTES_OR_QUERY_RESULTS}

Example output: "Organic search users retain 40% better than paid, but only on mobile. Recommend shifting 15% of the mobile paid budget to SEO content production. Open question: we can't tell if this is a creative quality issue or a targeting issue from this data alone."

5. Data Quality Audit (Column-by-Column)

Before any analysis, you need to profile the data. This prompt generates a systematic audit plan.

You are a data quality analyst. I will provide a table schema.
For EACH column, generate:
1. Expected data type and format
2. 3 potential quality issues (nulls, outliers, format drift, encoding, duplicates, referential integrity)
3. The SQL to check each issue
4. A severity rating (critical / warning / info)

Schema: {PASTE_CREATE_TABLE_STATEMENT}
Sample data: {OPTIONAL_PASTE_5_ROWS}

Example output: For a user_email column — checks for nulls (WHERE email IS NULL), format validity (WHERE email NOT LIKE '%_@_%._%'), duplicates (SELECT email, COUNT(*) GROUP BY email HAVING COUNT(*) > 1). Severity: critical for nulls (breaks downstream), warning for format issues, info for case sensitivity inconsistencies.

6. Metric Definition Document

Teams argue about what "active user" means. This prompt generates a formal metric definition that eliminates ambiguity.

You are a data governance analyst.
Define the metric "{METRIC_NAME}" in a way that any new analyst could compute it identically.

Output:
1. Plain-English definition (1 sentence)
2. Exact SQL or formula
3. Inclusions (what counts)
4. Exclusions (what does NOT count — be specific)
5. Edge cases (new users, deleted users, bot traffic, internal accounts)
6. Refresh cadence (real-time / hourly / daily) and why
7. 3 common misinterpretations to warn stakeholders about

Example output (for "Weekly Active User"): Defines WAU as "distinct user_id with at least one session_start event in the trailing 7-day window ending at midnight UTC Sunday." Excludes internal test accounts (email domain @company.internal). Edge cases: users who deleted their account mid-week still count for the weeks they were active. Common misinterpretation: "active" does not mean "engaged" — a user who opened the app and immediately closed it still counts.

7. A/B Test Result Interpreter

Test results are often misread — people focus on the headline lift and ignore statistical significance, segment interactions, and novelty effects.

You are an experimentation analyst. I will provide A/B test results.
Analyze them and output:

1. Headline: Did the treatment win? (State the lift, confidence interval, and p-value.)
2. Significance check: Is this result trustworthy? (sample size, power, multiple testing correction if applicable)
3. Segment breakdown: Did any subgroup behave differently? (If I provide segment data, analyze it. If not, list the 3 segments I should check.)
4. Novelty effect check: Is the lift decaying over time? (If I provide time-series data, analyze it. If not, tell me what pattern to look for.)
5. Recommendation: Ship / iterate / kill — with reasoning.

Raw results: {PASTE_TEST_DATA}

Example output: "Treatment won with +8.2% lift (95% CI: +2.1% to +14.3%, p=0.012). However, the mobile segment shows -3% while desktop shows +18% — this is a heterogeneous treatment effect. Do not ship globally without segment-specific analysis. The lift is stable over the 14-day window (no novelty decay detected). Recommendation: ship to desktop only, iterate on mobile."

8. Data Pipeline Documentation

Pipelines break when no one understands them. This prompt generates documentation from a code description.

You are a data engineer documenting a pipeline for a new team member.
I will describe the pipeline steps (sources, transformations, destinations).

For each step, document:
1. What it does (1 sentence)
2. Input: source table/API/file + expected schema
3. Output: destination table/file + resulting schema
4. Failure mode: what happens if this step fails (does downstream break? is there a fallback?)
5. Owner: who to contact (leave as TBD if unknown)

Then add a "Data lineage" section showing the flow as a text diagram:
source → transform → destination

Pipeline description: {DESCRIBE_YOUR_PIPELINE}

Example output: Documents a Kafka → Flink → S3 → Snowflake pipeline. Each step has input/output schemas, failure modes (Kafka lag alert, Flink checkpoint failure, S3 write timeout). Data lineage: [Kafka topic: events] → [Flink: dedupe + enrich] → [S3: parquet partitioned by date] → [Snowflake: external table] → [dbt: mart].

9. Stakeholder Request Triage

When a stakeholder asks for "a quick analysis," it's rarely quick. This prompt helps scope the request before committing.

You are a data analyst triaging an incoming request.
I will paste the stakeholder's message (Slack, email, or ticket).

Output a triage document:
1. Restate the business question in one sentence (what decision are they trying to make?)
2. Data requirements: which tables, what time range, what granularity
3. Complexity estimate: simple lookup (1 hr) / multi-table join (4 hrs) / statistical analysis (1+ day)
4. Ambiguities: what's unclear about the request? List questions to ask the stakeholder.
5. Suggest a "good enough" version if the full analysis would take >1 day.

Stakeholder message: {PASTE_THE_REQUEST}

Example output (for "Can you tell me why revenue is down?"): Business question: "Is the revenue decline a real trend or noise, and what's driving it?" Data requirements: revenue table (30-day + 30-day prior), sliced by product, region, customer tier. Complexity: multi-table join + segment analysis (4-8 hours). Ambiguities: "revenue" — gross or net? What time frame? Compared to what? Good-enough version: top-line trend + top 3 declining segments, deliverable in 2 hours.

10. Code Review for SQL / dbt

Data code reviews often skip logic errors because the reviewer focuses on syntax. This prompt enforces a logic-first review.

You are a senior data analyst reviewing SQL/dbt code.
Review for LOGIC errors, not style.

Check specifically:
1. JOIN correctness: are you joining at the right granularity? (Cartesian explosion risk)
2. Filtering: is the WHERE clause applied before or after aggregation? (Common error)
3. NULL handling: do COUNT(column) vs COUNT(*) give different results? Are NULLs excluded from AVG?
4. Time zone: are all timestamps in the same zone? Are you comparing UTC to local?
5. Window functions: is the PARTITION BY correct? Are you using ROWS vs RANGE correctly?
6. Deduplication: is there a risk of counting the same event twice?

Code: {PASTE_SQL_OR_DBT_MODEL}

Example output: Flags a LEFT JOIN on user_id where the right table has multiple rows per user — causing row multiplication. Identifies a WHERE event_date >= '2026-01-01' applied after a COUNT(*) window function, meaning it counts all-time events then filters. Recommends moving the filter into a CTE before the window function.

How I Test These Prompts

Every prompt above follows a testing protocol:

Run 3 times with the same input — if the output varies significantly, the prompt is too vague. Tighten constraints.
Generalize — after getting a good output for one dataset, try it on a different schema. Does it still work?
Read the output aloud — if it sounds like AI-generated filler, add a negative constraint (ban specific words).
Cut anything generic — if the output could apply to any dataset without modification, it's not adding value. Delete it and make the prompt more specific.

Want the Full System?

These 10 prompts are a starting point. If you're building a data-informed company and want a complete prompt system covering analytics, operations, sales, marketing, engineering, and leadership workflows:

Developer Productivity Prompt Library — 30 prompts for individual contributors ($49)
AI Startup Operations Prompt System — 50+ prompts + 10 workflows for teams ($199)
AI Business Transformation Playbook — 100+ prompts + 12 workflows for org-wide adoption ($999)

Or start small with the Developer Product-Launch Prompt Pack ($9) — 7 prompts for shipping your next product.

What prompts do you use for data work? I'm always looking to add to this list — drop your favorites in the comments.

10 AI Prompts I Use for Sales Outreach (Cold Emails, Discovery Calls, Objection Handling)

draftkit — Thu, 23 Jul 2026 19:30:56 +0000

I spent two years running outbound sales before I started using AI. The bottleneck was never writing faster — it was writing better. More specific. More relevant. Less obviously templated.

These 10 prompts are the ones I use every week. Each one has a Role → Context → Constraints → Output structure, and each one produces something I'd actually send to a prospect. I've tested every one of them on real outreach (yes, on real people — I checked the reply rates).

Full disclosure: I sell a SaaS Marketing Copy Prompt Pack ($49) and a Developer Product-Launch Prompt Pack ($9) — both include sales/outreach prompts. These 10 are a sample. If they help, the packs have 200+ more.

How These Prompts Are Structured

Every prompt below follows the same pattern:

ROLE: Who the AI is acting as
CONTEXT: The situation it needs to know about
CONSTRAINTS: What it can and can't do
OUTPUT: The exact format you want back

This structure matters. Without constraints, the AI writes generic corporate mush. With them, it writes something a human would actually read.

1. The Pain-First Cold Email (3 sentences, no fluff)

ROLE: You are a B2B SDR who has booked 500+ meetings in 2 years.

CONTEXT: I'm reaching out to {role} at {company}. They likely deal with
{specific pain point — e.g., "spending 4+ hours/week manually pulling
reports from 3 different tools"}. Our product {one-line value prop}.

CONSTRAINTS:
- Subject line: ≤5 words, lowercase, no question marks
- Body: exactly 3 sentences
- Sentence 1: the pain (observed, not assumed)
- Sentence 2: the specific outcome we produce
- Sentence 3: a soft ask (not a meeting request)
- BANNED words: "revolutionary", "seamless", "empower", "leverage",
  "game-changing", "innovative", "cutting-edge"
- Do NOT mention our company name in the body
- Do NOT use exclamation points

OUTPUT: Subject line + email body. Nothing else.

Why it works: The constraint "observed, not assumed" forces you to research before the AI writes. The ≤5-word lowercase subject bypasses spam filters and pattern-matching. The soft ask (e.g., "Worth a quick look?" or "Open to seeing how?") gets 2-3x reply rates vs. "Can we hop on a call?"

2. The Discovery Call Prep Sheet (questions that reveal budget)

ROLE: You are a senior AE preparing a discovery call.

CONTEXT: I'm meeting with {persona} at {company} ({industry}, ~{revenue}
revenue). They're evaluating {category}. Our competitors in this space
are {competitor 1, competitor 2}. The deal size is typically {amount}.

CONSTRAINTS:
- Generate exactly 7 questions
- Questions must map to BANT (Budget, Authority, Need, Timeline)
  but DO NOT label them or ask "what's your budget" directly
- At least 2 questions must be about their current process/workflow
  (not about our product)
- At least 1 question must surface a potential deal-killer early
- No yes/no questions — every question must require a 2+ sentence answer
- Include a "trap question" — one that reveals whether they're
  comparison-shopping or problem-solving

OUTPUT: Numbered list of 7 questions. After each, a 1-line note on
what answer you're listening for.

Why it works: Most discovery calls fail because reps ask product questions instead of process questions. This prompt forces workflow-first questioning, which reveals more and builds trust faster.

3. The Objection Crusher (objection → reframe, not argument)

ROLE: You are a sales trainer who specializes in objection handling
without being pushy.

CONTEXT: A prospect said: "{exact objection quote}".
They are a {role} at {company type}. Our product costs {price}.

CONSTRAINTS:
- Do NOT contradict them
- Do NOT say "I understand" or "That's a great point"
- Acknowledge the concern in ≤8 words
- Then reframe it using their own words
- Provide exactly 3 possible responses, each ≤3 sentences:
  1. The logic reframe (data/perspective shift)
  2. The story reframe (a relevant case study one-liner)
  3. The question reframe (turn it back to them)
- Mark which one is best for a {personality type: analytical/expressive/driver}

OUTPUT: The 3 responses, clearly labeled. A 1-line recommendation
on which to use and why.

Why it works: "I understand" signals you're about to argue. Banning it forces a genuine acknowledgment. The three-response format lets you adapt in real-time based on the prospect's energy.

4. The Follow-Up That Doesn't Get Ignored (sequence of 4)

ROLE: You are a B2B SDR writing a 4-touch follow-up sequence.

CONTEXT: Prospect {name} opened my first email but didn't reply.
They're a {role} at {company}. Original email was about {topic}.

CONSTRAINTS:
- Touch 1 (Day 3): value-add, not a nudge. Share one relevant insight
  or resource. ≤4 sentences.
- Touch 2 (Day 7): the pattern interrupt. A question that reframes
  the conversation. ≤2 sentences.
- Touch 3 (Day 14): the breakup email. Professional, gives permission
  to disengage, leaves the door open. ≤3 sentences.
- Touch 4 (Day 30): the check-in. Casual, no pitch. References
  something timely. ≤2 sentences.
- BANNED: "just checking in", "circling back", "bumping this up",
  "following up on my previous email"
- Each email must have a different tone (helpful → curious →
  detached → casual)

OUTPUT: 4 emails with subject lines, labeled by day.

Why it works: The breakup email (Touch 3) consistently gets the highest reply rate in the sequence — psychology, not desperation. Banning "just checking in" eliminates the #1 reason prospects ghost.

5. The LinkedIn Connection Note (mutual value, not a pitch)

ROLE: You are a B2B sales professional who has a 40%+ acceptance rate
on cold LinkedIn connections.

CONTEXT: I found {name} who is a {role} at {company}. We have
{mutual connection or shared group/interest}. They recently
{observable activity — posted, commented, launched, hired}.

CONSTRAINTS:
- ≤200 characters (LinkedIn limit is 300, but shorter = better)
- Reference the observable activity specifically
- Do NOT pitch anything
- Do NOT ask for a call or meeting
- Offer one specific thing of value (an intro, a resource, an insight)
- End with a question mark (questions get higher reply rates)
- No emojis

OUTPUT: Just the connection note text.

Why it works: LinkedIn connection notes that pitch get ignored. Notes that reference specific recent activity + offer value get accepted. This prompt forces both.

6. The Competitor Battle Card (honest, not trash-talk)

ROLE: You are a sales enablement lead creating a battle card.

CONTEXT: We sell {our product}. Main competitor is {competitor}.
Our pricing: {our price}. Their pricing: {their price}.

CONSTRAINTS:
- Do NOT trash-talk the competitor
- Do NOT make claims you can't prove with a URL
- Create a table with 4 columns: Feature/Aspect | Us | Them |
  What to say (if asked)
- Cover exactly 6 rows: pricing model, onboarding time, key
  differentiator, integration ecosystem, support model,
  ideal customer profile
- For "What to say": frame as a question back to the prospect,
  not a statement
- Include a "DO NOT SAY" section with 3 things that will backfire

OUTPUT: The table + the DO NOT SAY section.

Why it works: Prospects who mention competitors are 60% of the way to buying — they're validating. Trash-talking the competitor signals insecurity. This prompt produces honest comparisons that build trust.

7. The Post-Demo Recap Email (recap that moves the deal forward)

ROLE: You are an AE writing a post-demo follow-up.

CONTEXT: Just finished a demo with {name} ({role}) at {company}.
Key things discussed: {3 bullet points of what they cared about most}.
Next step discussed: {agreed next step}. Timeline mentioned:
{their timeline if any}.

CONSTRAINTS:
- Subject line: "Recap: {topic}" — no clickbait
- First line: what THEY said mattered most (not what you pitched)
- Second section: the 3 key takeaways in their words
- Third section: exactly one clear next step with a date
- Fourth section: one relevant resource (case study, doc, etc.)
- Do NOT include pricing unless they asked about it on the call
- Do NOT say "great meeting you" or "thanks for your time"
- ≤200 words total

OUTPUT: Subject + email body.

Why it works: The recap email is the most-forwarded email in B2B sales — prospects share it internally to justify the purchase. Leading with their priorities (not your pitch) makes it forwardable.

8. The Pricing Objection Reframe (value anchor, not discount)

ROLE: You are a sales coach specializing in value-based selling.

CONTEXT: Prospect said "{pricing objection}" about our product
that costs {price}. The alternative they're considering is
{alternative + its price or "doing nothing"}.

CONSTRAINTS:
- Do NOT offer a discount
- Do NOT justify the price with features
- Calculate the cost of the status quo (what they're losing
  by not solving the problem)
- Reframe using one of: cost-per-month, cost-per-seat-per-day,
  ROI timeline, or opportunity cost
- Provide the math explicitly (show your work)
- End with a question that shifts focus from price to value

OUTPUT: The reframe (3-5 sentences) + the explicit math.

Why it works: Price objections are rarely about price — they're about unproven value. This prompt forces you to quantify the cost of doing nothing, which is almost always higher than your price.

4 more prompts (abbreviated):

9. The Lost-Deal Post-Mortem Email — a graceful "what could we have done better?" email to lost deals. Gets 30%+ reply rate and occasionally reopens deals. Constraint: no re-pitching, genuine curiosity, ≤4 sentences.

10. The Upsell Trigger Detector — paste a customer's recent support tickets / feature requests / usage data, and the prompt identifies upsell opportunities. Constraint: must map to a specific product tier or add-on, must include the exact trigger phrase to listen for.

11. The Sales Forecast Reality Check — paste your pipeline, and the prompt stress-tests each deal's probability. Constraint: must identify deals that are "happy ear" (you're too optimistic) vs. "at risk" (you're not paying attention). Outputs a revised forecast with confidence intervals.

12. The ICP Refinement Prompt — paste your last 20 won deals + last 20 lost deals, and the prompt identifies the pattern that separates them. Constraint: must produce a 1-page Ideal Customer Profile with firmographic + behavioral signals, not generic personas.

How I Test These Prompts

Run each prompt 3 times with the same inputs. If the outputs vary wildly, the prompt is too loose — tighten the constraints.
Generalize: after testing on one scenario, swap in a different industry/product. If it still works, the prompt is robust.
Read it aloud. If it sounds like an AI wrote it, add a constraint that bans the telltale phrase.
Cut anything generic. If a line could apply to any company in any industry, delete it and replace with something specific.

The Prompt Packs

If these were useful, I've packaged 200+ more into structured packs:

Developer Product-Launch Prompt Pack ($9) — 7 prompts for shipping and launching dev products
SaaS Marketing Copy Prompt Pack ($49) — 25 prompts for landing pages, ads, emails, and sales copy
Developer Productivity Prompt Library ($49) — 30 prompts for dev workflows
AI Startup Operations Prompt System ($199) — 50+ prompts + 10 workflows for running a startup with AI
AI Business Transformation Playbook ($999) — 100+ prompts + 12 workflows, the flagship

Or browse the full store: innovate01.gumroad.com

What sales prompts have worked for you? I'm always looking to test new ones.

10 AI Prompts I Use for Growth Marketing (Experiments, Activation Funnels, Retention Loops)

draftkit — Thu, 23 Jul 2026 18:54:22 +0000

I've spent the last year running growth experiments for SaaS products using AI as a thought partner — not a content factory. The difference matters: most people ask AI to write growth copy. I ask it to think through experiments with me.

These 10 prompts have survived real use across activation funnels, retention analysis, win-back campaigns, and experiment readouts. Each one follows the same structure: Role → Context → Constraints → Output. That structure is why they work — the constraints do the heavy lifting, not the role assignment.

If you want the full library (200+ tested prompts across marketing, operations, sales, and product), I keep them at my Developer Product-Launch Prompt Pack ($9) and the larger SaaS Marketing Copy Pack ($49).

1. The Growth Hypothesis Framer

Most growth "experiments" are actually guesses dressed up in hypothesis language. This prompt forces a real hypothesis with a prediction, a falsification signal, and a kill criterion — before you spend a single hour building.

You are a growth marketing strategist. I will describe a feature change
or experiment idea. Frame it as a testable growth hypothesis using this
exact format:

HYPOTHESIS: We believe that [action] for [segment] will result in
[measurable outcome].
PREDICTION: We expect a [X]% change in [metric] within [timeframe].
FALSIFICATION SIGNAL: If [metric] does not move by at least [Y]%, the
hypothesis is false.
KILL CRITERION: Stop the experiment if [specific early signal] by day [N].
ASSUMPTION RISK: The riskiest untested assumption underlying this is [assumption].

Constraints:
- Do not use the words "leverage," "synergy," or "optimize."
- The falsification signal must be a number, not a feeling.
- The kill criterion must be actionable within 7 days, not "monitor and revisit."

Feature change: [DESCRIBE YOUR CHANGE]

Why the constraints matter: Banning "optimize" forces specific language. The 7-day kill criterion stops experiments from drifting into "we need more data" limbo. The falsification signal being a number prevents the post-hoc rationalization where you declare victory on a secondary metric.

2. Activation Funnel Diagnostic

You are a growth analyst. I will paste our activation funnel steps with
conversion rates between each step. Identify the single biggest drop-off
and diagnose the likely cause.

For the biggest drop-off, provide:
1. THE BOTTLENECK: Step X → Step Y ([Z]% drop)
2. THREE POSSIBLE CAUSES, ranked by likelihood:
   - Cause A (most likely): [specific behavioral explanation]
   - Cause B: [specific behavioral explanation]
   - Cause C: [specific behavioral explanation]
3. ONE DIAGNOSTIC QUESTION per cause that would confirm or rule it out
   (a question you could ask 5 users in a 10-minute call).
4. THE FIX THAT IS NOT "ADD A TOOLTIP."

Constraints:
- Do not suggest "improve onboarding" or "add guidance."
- Each cause must reference a specific user action or inaction, not a vague "confusion."
- The diagnostic questions must be answerable by a user, not by analytics alone.

Funnel data: [PASTE STEPS + RATES]

Why the constraints matter: "Improve onboarding" is not a fix — it's a category. Forcing specific behavioral explanations (e.g., "users complete email signup but never click the confirmation link because the value of confirming isn't stated on the success page") produces actionable diagnoses, not platitudes.

3. Retention Loop Designer

You are a growth marketer specializing in retention loops. I will describe
our product's core value action (the action that correlates with retention).

Design a retention loop around this action. Output:

1. THE TRIGGER: What external event or internal signal prompts the user
   to perform the core action again? (Must be specific — not "a notification.")
2. THE ACTION: The core value action, stated as a verb.
3. THE INVESTMENT: What the user puts in that increases their switching cost
   or makes the next trigger more effective.
4. THE LOOP VELOCITY: How fast does this loop complete? (Daily, weekly, monthly?)
5. ONE WAY THE LOOP CAN BREAK: The most likely failure point.

Then identify the SINGLE highest-leverage change to tighten the loop.

Constraints:
- Do not use "gamification" or "engagement" as solutions.
- The trigger must be an observable event, not a feeling.
- The investment must be something the user explicitly does, not passive data accumulation.

Core value action: [DESCRIBE]

4. Win-Back Campaign Writer (No Guilt, No Discounts)

You are a retention marketer. I will describe a churned user segment and
when they last used the product. Write a 3-email win-back sequence.

Email 1 (Day 0): The "something changed" email — reference a specific
product improvement released since they left. No discount. No "we miss you."
Email 2 (Day 4): The "one specific use case" email — show ONE workflow
that solves a problem they likely still have. Include a 30-second setup.
Email 3 (Day 10): The "honest question" email — ask what would need to
be true for them to return. One sentence. No CTA button, just a reply-to.

Constraints:
- Subject lines must be lowercase, under 6 words, and must not contain
  the word "back," "miss," or "return."
- Zero discounts across all three emails.
- Email 3 must not have a button — only a plain-text reply prompt.
- Each email under 100 words.

Churned segment: [DESCRIBE + LAST ACTIVE DATE]

Why no discounts: Discount-based win-backs train users to churn for deals. This sequence rebuilds the value proposition instead. The lowercase subject lines and no-button final email reduce the "marketing email" signal that gets you ignored.

5. North Star Metric Interrogator

You are a growth strategy advisor. I will state our current North Star
metric. Interrogate it by answering these 5 questions:

1. Does this metric measure value RECEIVED, or value REQUESTED? (If a user
   can inflate it without getting value, it's wrong.)
2. Does this metric lead or lag revenue? (Leading metrics let you act
   before the quarter ends.)
3. Can a single user's usage pattern distort this metric? (If one whale
   can move it 20%, it's not a north star — it's a lottery ticket.)
4. Does this metric align all teams, or does it create cross-functional conflict?
5. What behavior would a rational team member optimize for if they ONLY
   cared about this number? Is that behavior good for users?

After answering, suggest ONE alternative metric that addresses the biggest
weakness you identified.

Constraints:
- Do not define "north star metric" — assume I know.
- Be direct about whether my current metric is wrong. Do not hedge.

Current North Star metric: [DESCRIBE]

6. A/B Test Readout (Pre-Mortem Edition)

You are a growth experimenter. I will describe an A/B test result
(variant, metric, lift, significance, sample size).

Instead of just declaring a winner, produce a pre-mortem readout:

1. THE RESULT: [variant] beat [control] by [X]% on [metric] (significant: Y/N)
2. WHAT THIS PROVES: The narrow, specific claim this result supports.
3. WHAT THIS DOES NOT PROVE: Three things a stakeholder might incorrectly
   infer from this result.
4. SEGMENTATION RISK: Name one user segment where this change might HURT,
   even if the aggregate looks positive.
5. NEXT EXPERIMENT: The single follow-up experiment that would confirm
   the mechanism (not just replicate the result).

Constraints:
- Do not say "roll it out" or "ship it" — that's a product decision, not an analysis.
- "What this does not prove" must contain at least one counterintuitive item.
- The next experiment must test the mechanism, not just scale the sample.

Test result: [DESCRIBE]

Why this matters: Most experiment readouts either declare victory or demand more data. This prompt forces you to identify what you can't conclude — which is where bad growth decisions originate.

7. Referral Program Architect

You are a growth marketer who has designed referral programs for 20+ SaaS
companies. I will describe our product, pricing, and typical user persona.

Design a referral program. Output:

1. THE DOUBLE-SIDED INCENTIVE: What the referrer gets AND what the
   referred user gets. Must be asymmetric if one side values the reward more.
2. THE TIMING: When in the user lifecycle do we ask for a referral?
   (Must reference a specific moment of value realization, not "after signup.")
3. THE FRICTION MAP: List every step between "user decides to refer" and
   "referred user converts." Identify the step most likely to cause drop-off.
4. THE ABUSE VECTOR: How could a rational bad actor game this program?
5. THE KILL SIGNAL: What metric, if below [threshold] after [timeframe],
   means we shut down or redesign the program?

Constraints:
- Do not default to "give both sides a month free" — justify the specific reward.
- The timing must be event-based, not time-based.
- The abuse vector must be realistic, not paranoid.

Product/pricing/persona: [DESCRIBE]

8. Churn Autopsy (From Exit Survey Data)

You are a retention analyst. I will paste exit survey responses (free-text)
from churned users over the past 30 days.

Perform a churn autopsy:
1. GROUP the reasons into clusters (max 5 clusters). Name each cluster
   with a behavior, not a sentiment. (e.g., "Hit the usage limit during
   a critical workflow" not "frustrated with limits.")
2. For each cluster, estimate the % of churn it explains.
3. For the TOP cluster only: propose ONE product or pricing change that
   would address the root cause. Must be specific enough to spec as a ticket.
4. Identify any cluster that is actually UNFIXABLE (e.g., "company shut down,"
   "switched to an enterprise tool we can't compete with") — these are not
   actionable and should be separated from fixable churn.

Constraints:
- Do not say "improve the product" — that is not a change.
- Clusters must be behavior-based, not emotion-based.
- The proposed change must reference the specific complaint language from the responses.

Exit survey responses: [PASTE]

9. Viral Coefficient Reality Check

You are a growth modeler. I will provide our viral coefficient inputs
(number of invites per user, conversion rate of invites).

Calculate the K-factor, then perform a reality check:

1. THE MATH: K = [invites] × [conversion]. Show the number.
2. THE ASSUMPTION AUDIT: For each input, state whether it's measured,
   estimated, or aspirational. Flag any input that is "aspirational."
3. THE ORGANIC VS. INDUCED SPLIT: Of the invites per user, what % are
   organic (user would invite anyway) vs. induced (only because of a
   program/prompt)? If you can't split this, the K-factor is inflated.
4. THE CEILING: At what user count does the viral loop saturate?
   (Every viral loop has a ceiling — name a plausible one.)
5. THE HONEST VERDICT: Is this product actually viral, or are we forcing it?

Constraints:
- Do not say "increase invites per user" as a recommendation.
- If any input is aspirational, say so explicitly.
- The ceiling must be a number or range, not "eventually."

Inputs: [PASTE]

10. Growth Experiment Backlog Prioritizer

You are a growth lead. I will paste a list of 10+ experiment ideas,
each with a one-line description.

Prioritize them using a modified ICE framework, but with a critical twist:

For each experiment, score:
- IMPACT (1-10): If this works, how much does it move the primary metric?
- CONFIDENCE (1-10): How sure are we it will work? (Subtract 3 points if
  we've never run a similar experiment.)
- EASE (1-10): How fast can we ship and measure this?

Then add a fourth column:
- REGRET: If we DON'T run this and a competitor does, how bad is that?
  (1-10, where 10 = "they'd win the market.")

Sort by (IMPACT × CONFIDENCE × EASE) + (REGRET × 2).

Output the top 5 ranked experiments with their scores and ONE LINE on
why each is ranked where it is.

Constraints:
- Confidence must be penalized for novelty — if it's a "new channel" or
  "unproven tactic," cap confidence at 4 regardless of how exciting it sounds.
- Do not rank based on excitement or novelty.
- The "why" line must reference a score component, not a gut feeling.

Experiment ideas: [PASTE LIST]

Why the Regret column: ICE alone optimizes for safe, incremental wins. Adding a Regret-weighted term forces you to consider the strategic cost of not running a hard experiment — which is how categories get disrupted.

How I Test These Prompts

Every prompt above went through the same 3-step validation before I trusted it:

Run it 3 times with the same input. If the outputs vary wildly in structure, the prompt's constraints are too loose.
Generalize it. Swap in a different product/context. If the output breaks, the prompt is overfit to one scenario.
Read it aloud. If the output sounds like it could appear on any marketing blog without modification, it's too generic — tighten the constraints until the output is specific to the input.

The prompts that survived this filter are the ones where the constraints do the thinking, not the role assignment. "You are a growth marketer" adds almost nothing. "The kill criterion must be actionable within 7 days" changes the entire output.

Where to Get More

These 10 are a slice of a larger system. If growth marketing prompts are useful to you, the full libraries are here:

Developer Product-Launch Prompt Pack — $9, 7 launch-focused prompts
SaaS Marketing Copy Prompt Pack — $49, 25 marketing prompts
AI Startup Operations Prompt System — $199, 50+ prompts across growth, sales, ops, and product
AI Business Transformation Playbook — $999, 100+ prompts, 12 full workflows

Or browse the full storefront.

What growth prompts have worked for you? I'm always testing new structures — drop a comment with a prompt that outperformed your expectations.

10 AI Prompts I Use for Customer Success (Onboarding, QBRs, Churn Rescue)

draftkit — Thu, 23 Jul 2026 18:13:59 +0000

Customer Success is the function that turns a signed contract into a renewed one. It's a mix of project management, consulting, relationship work, and — increasingly — writing. Onboarding plans, QBR decks, churn-rescue emails, expansion proposals, executive summaries. Every one of those is a writing task, and every one of them benefits from a sharp prompt.

I've spent the last year building prompt systems for SaaS teams. Here are the 10 prompts I give to Customer Success Managers — the ones that actually get used, not the generic "write me an email" templates. Each one follows a Role → Context → Constraints → Output structure so the model knows what kind of operator it's being, what situation it's in, what it can't do, and exactly what to produce.

1. The 30-60-90 onboarding plan that forces outcome ownership

Most onboarding plans are a list of meetings. This one forces every milestone to own a customer-visible outcome.

Role: You are a Senior Customer Success Manager at a B2B SaaS company.

Context: A new customer just signed. Company: {company}. They bought {product} to solve {pain_point}. Their success metric is {metric}. Their go-live target is {date}. Their internal champion is {champion_name}, {champion_title}. Their technical contact is {tech_contact}. Team size: {N}.

Constraints:
- Every milestone must have ONE owner on the customer side and ONE on our side.
- Phase 1 (days 0-30) = setup + first value. Phase 2 (days 31-60) = adoption across team. Phase 3 (days 61-90) = habit + measure against the success metric.
- No milestone can be "kickoff meeting" alone — it must be "kickoff meeting → outcome."
- Include the specific feature/module they must activate in each phase.

Output: A markdown table with columns: Phase | Day range | Milestone (outcome, not activity) | Customer owner | Our owner | Feature activated | Success signal.

Why it works: The "outcome not activity" constraint kills the most common onboarding failure mode — a calendar full of check-ins where nobody shipped anything.

2. The stakeholder map from a messy kickoff call

CSMs inherit accounts with unclear reporting lines. This prompt turns scattered notes into a decision-making map.

Role: You are a Customer Success Strategist.

Context: I just had a 45-minute kickoff call with a new enterprise account. Here are my raw notes:

{paste_notes}

Constraints:
- Identify who the Decision Maker, Champion, Blocker, and End Users are — but ONLY based on evidence in the notes. If unclear, label "UNCONFIRMED" and say what to ask next.
- For each person, note their stated goal AND their unstated fear (infer from what they emphasized or avoided).
- Flag any person whose goal conflicts with the champion's goal.

Output: A stakeholder table: Name | Role | Classification (DM/Champion/Blocker/User) | Stated goal | Inferred fear | Confidence (High/Med/Low) | Next action.

Why it works: The "inferred fear" column is the one CSMs actually use. Renewal risk usually comes from an unspoken fear, not a stated objection.

3. The QBR narrative (not a feature recap)

A QBR that recaps features is a QBR that gets rescheduled forever. This prompt forces a business-outcome narrative.

Role: You are a Customer Success Director preparing a Quarterly Business Review for an executive sponsor.

Context:
- Customer: {company}, industry {industry}, {N} seats.
- They bought to achieve {original_goal}.
- This quarter they achieved {results} (usage data: {usage_metrics}).
- They did NOT achieve {gaps}.
- Their renewal is in {months} months.
- The exec sponsor cares most about {exec_priority}.

Constraints:
- Structure: 1) Where we started (baseline), 2) Where we are (with data), 3) What worked (2-3 specific wins tied to their goal), 4) What didn't (honest, with a plan), 5) Next quarter's bet (ONE priority, not five).
- Open with the single most important number. Not a slide title — a number.
- The "what didn't work" section must be 1/3 the length of "what worked" — honesty without dwelling.
- End with ONE ask of the exec sponsor (a decision, not "thoughts?").

Output: A QBR narrative script (what to say, slide by slide), 8-10 slides max. Include the opening line verbatim.

Why it works: The "one ask" constraint forces the CSM to know what they actually need from the exec — an introduction, a budget sign-off, a mandate. Most QBRs die because they end with "any questions?" instead of a decision request.

4. The churn-rescue email that doesn't grovel

When an account is at risk, the instinct is to over-apologize and offer a discount. That signals weakness. This prompt writes a rescue message that leads with a plan.

Role: You are a Customer Success Manager writing to an at-risk customer.

Context: The customer {company} has shown {risk_signal} — {specific_evidence}. Their champion {name} has gone quiet for {N} weeks. Their last known goal was {goal}. They raised this concern on {date}: {concern}. We have done {actions_taken}.

Constraints:
- Subject line: ≤6 words, lowercase, no urgency words ("urgent", "important", "checking in"). Reference their specific situation.
- First line: acknowledge the specific gap WITHOUT apologizing. Name what's broken.
- Second block: the fix — 3 concrete steps, each with a date. Not "we're committed to" — actual steps with dates.
- Third block: one question that requires a real answer (not "how are things?").
- No discounts. No "I'd love to hop on a call." The call is offered only if they answer the question.
- Max 120 words.

Output: The email, ready to send.

Why it works: The "no discount" and "no checking in" constraints are the two things that separate a CSM who saves the account from one who accelerates the exit. Discounts train customers to threaten churn.

5. The expansion conversation opener (not a sales pitch)

Expansion done badly feels like an upsell. Done well, it feels like a CSM who noticed something first. This prompt drafts the conversation opener for a usage-based expansion.

Role: You are a Customer Success Manager preparing to propose an expansion.

Context: Customer {company} currently has {current_plan}. In the last 90 days, {usage_evidence} shows they're hitting the limits of {limit_type}. Their team grew from {old_N} to {new_N}. The next plan tier adds {new_capability} which maps to their original goal of {goal}.

Constraints:
- Frame the expansion as "I noticed something" not "you should upgrade."
- Lead with the observation (the data), then the implication (what it means for their goal), then the question (whether they want to solve it now).
- Do NOT mention price. The goal of this message is a conversation, not a close.
- Reference their original goal explicitly — tie the expansion to why they bought, not to features.

Output: A Slack message or email (≤100 words) that opens the expansion conversation. Plus a 3-bullet "talking points if they say yes" prep for the CSM.

Why it works: Expansion messages that lead with price get forwarded to procurement. Messages that lead with "I noticed your team hit 47 seats and you're hitting API rate limits — here's what that means for your Q3 goal" get a reply from the champion.

6. The health-score narrative for internal review

CSMs maintain health scores, but the number is useless without a narrative. This prompt turns a health score into an executive-readable account story.

Role: You are a Customer Success Manager writing an internal account-health summary for your weekly CS team review.

Context:
- Account: {company}, ARR {value}, renewal date {date}.
- Health score: {score}/100, trend {up/down/flat over N weeks}.
- Product usage: {usage_summary}.
- Support tickets: {N} open, {theme}.
- Champion engagement: {engagement_level}.
- Last executive touchpoint: {date}.

Constraints:
- One sentence per category (usage, support, champion, exec relationship). No paragraphs.
- End with: Green/Yellow/Red verdict + the ONE thing that would move it up a color.
- If Yellow or Red, name the specific risk (champion left, usage dropped, competitor evaluated) — not vague "engagement concerns."
- Max 150 words total.

Output: The account-health summary, formatted for a Slack thread or CRM note.

Why it works: CS leaders don't read health scores — they read the "one thing that would move it up a color." That's the line that triggers a manager to assign help or escalate.

7. The customer feedback synthesis (themes, not quotes)

After a batch of customer interviews, you have 40 pages of transcripts. This prompt synthesizes them into actionable themes without losing the signal.

Role: You are a Customer Success Operations analyst.

Context: I conducted {N} customer interviews this month. Here are the transcripts/notes:

{paste_notes}

Constraints:
- Group feedback into themes. A theme needs at least {N} independent mentions to qualify.
- For each theme: the pattern, the severity (how many mentioned it), and one representative quote (verbatim, not paraphrased).
- Separate "product feedback" (something engineering should hear) from "success feedback" (something CS/process should fix) from "praise" (keep doing this).
- Rank themes by frequency × severity, not by how interesting they sound.
- Flag any feedback that contradicts another piece of feedback — contradictions are where the real insight is.

Output: A themed feedback report. One table per category (product / success / praise). Then a "contradictions" section.

Why it works: The "contradictions" section is the hidden value. When two customers want opposite things, that's a segmentation insight — not a bug.

8. The renewal forecast narrative

Renewal forecasts are usually a spreadsheet. This prompt adds the narrative that explains why each account will or won't renew.

Role: You are a Customer Success Manager preparing your monthly renewal forecast.

Context: Here are my accounts up for renewal in the next 90 days:

{account_list_with_ARR_champion_health_last_touchpoint}

Constraints:
- For each account, classify: COMMITTED, AT RISK, or RESCUE NEEDED. No "likely" or "probably" — force a call.
- For each AT RISK or RESCUE account, name the single dominant risk factor (champion departure, low adoption, budget freeze, competitor, unresolved ticket, exec sponsor change).
- For each, state the ONE action that would move it up a category, with a deadline this week.
- Total the ARR at risk. Put that number at the top.

Output: A renewal forecast table + the total at-risk ARR called out at the top.

Why it works: Forcing a three-bucket classification (no "probably") is uncomfortable — and that's the point. "At risk" accounts that stay "at risk" for three consecutive forecasts are the ones that churn. The prompt surfaces them early.

9. The executive sponsor update (written for someone who reads in 20 seconds)

Executive sponsors don't read CSM updates. They skim. This prompt writes an update that survives the skim.

Role: You are a Customer Success Manager writing a monthly update to an executive sponsor (VP/C-level at the customer).

Context:
- Customer: {company}. Exec sponsor: {name}, {title}.
- This month's headline result: {result}.
- Adoption metric: {metric} ({trend}).
- One risk or open item: {risk}.
- One ask or decision needed: {ask}.

Constraints:
- Subject line: the single most important sentence. Not "Monthly update" — the actual news.
- First line: "On track" or "Needs attention" — nothing else. Then the one number that matters.
- Body: 3 bullets max. Each bullet is a complete thought (the exec should understand it without context).
- The ask is the last line. Make it a yes/no question or a specific request, not "thoughts?"
- Max 100 words including subject.

Output: The email.

Why it works: The "On track / Needs attention" opener is borrowed from incident communication. It respects the exec's time and forces the CSM to know their own answer before asking.

10. The handoff document (when a CSM leaves an account)

Account handoffs lose more customers than any other CS process. This prompt forces a handoff doc that a new CSM can act on in week one.

Role: You are a Customer Success Manager writing an account handoff document for the CSM taking over.

Context: I am transitioning account {company} to {new_csm_name}. Here is what I know:

{account_details_champion_history_open_issues_goals_renewal_date}

Constraints:
- Structure: 1) Why they bought (the original goal, in their words), 2) Where they are now (adoption, sentiment, health), 3) The 3 people who matter (name, role, what they care about, how to reach them), 4) The landmines (open tickets, past promises, sensitive history, things never to say), 5) The next 30 days (3 specific actions with dates).
- The "landmines" section is the most important. Be specific. If you once promised a feature and it didn't ship, say so.
- No generic advice ("build rapport"). Only specifics.
- Include the renewal date and the current risk level at the top.

Output: A handoff document, structured as above. Max 500 words.

Why it works: The "landmines" section is what every incoming CSM actually needs and almost never gets. A new CSM who doesn't know about a broken promise will repeat the mistake that caused it.

How to use these prompts

Each prompt is designed to be adapted, not copy-pasted blindly. Here's the testing methodology I use:

Run it 3 times with the same inputs. If the output varies wildly, your constraints are too loose. Tighten them.
Generalize across accounts. After you've used a prompt on 5 accounts, look at the common failures. Those failures tell you which constraint to add.
Read the output aloud. If it sounds like a template, the customer will hear it too. Add a constraint that forces specificity (a number, a name, a date).
Cut anything generic. If a line could apply to any customer, delete the line and replace it with a constraint that forces a customer-specific detail.

The difference between a prompt that saves you 20 minutes and a prompt that gets a customer to renew is the constraints. The role and context set the scene; the constraints do the work.

Want the full system?

These 10 prompts are a sample. I've built larger prompt systems for SaaS teams covering customer success, sales, marketing, product, and operations — tested across real accounts.

Developer Productivity Prompt Library — 30 prompts for dev teams ($49)
SaaS Marketing Copy Prompt Pack — 25 prompts for marketing teams ($49)
AI Startup Operations Prompt System — 50+ prompts + 10 workflows for the whole company ($199)
AI Business Transformation Playbook — 100+ prompts + 12 workflows, the flagship ($999)
Developer Product-Launch Prompt Pack — 7 prompts for launch day ($9)

Browse the full store at innovate01.gumroad.com.

If you want a custom prompt system built for your specific CS workflow — your onboarding flow, your health score model, your renewal motion — reach out. I build those for teams that need prompts tuned to their product, not generic templates.

10 AI Prompts I Use for SEO Work (Keyword Research, Content Briefs, Meta Tags)

draftkit — Thu, 23 Jul 2026 17:27:08 +0000

I've been doing SEO work alongside product for two years. These 10 prompts handle the repetitive parts — keyword research, content briefs, meta tags, internal linking maps — so I can spend time on strategy instead of formatting.

Each prompt follows the same structure: Role → Context → Constraints → Output. Run each one 3 times with the same inputs and pick the best output. Cut anything that sounds generic.

📦 The full library: I've open-sourced 200+ tested AI prompts covering SaaS marketing, developer productivity, and startup operations. The SaaS Marketing Copy Pack includes 25 prompts specifically for SEO and content marketing work.

1. Keyword Clustering (Not Just Grouping)

Most tools dump a list of 500 keywords. This prompt clusters them by search intent — so you build one page per cluster, not one page per keyword.

Role: You are an SEO strategist who has built content strategies for SaaS companies ranking for 50k+ monthly searches.

Context: I have this list of keywords (paste below). Each has search volume and CPC.

Constraints:
- Group keywords into clusters where ONE page could rank for ALL keywords in the cluster
- Base clusters on shared search intent, not just shared words
- Maximum 8 keywords per cluster
- Name each cluster with the primary keyword (highest volume)
- Flag any keyword that doesn't fit a cluster (orphan)

Output: A table with columns: Cluster Name | Primary Keyword | Secondary Keywords | Combined Volume | Search Intent (informational/commercial/transactional/navigational)

Keywords:
[paste your keyword list with volumes]

Why it works: It forces the model to think about intent, not string matching. "Best CRM software" and "CRM software reviews" land in different clusters because one is commercial and one is informational.

2. Search Intent Diagnosis (From the SERP)

When you're not sure whether to write a blog post or build a landing page, this prompt reverse-engineers intent from what's already ranking.

Role: You are an SEO analyst who diagnoses search intent from SERP composition.

Context: Here are the top 10 results for the query "[your target keyword]". For each, I've provided the title, URL type (blog/landing page/product/docs/video/forum), and content format.

Constraints:
- Identify the dominant intent (what does the searcher want to DO?)
- Identify the content format that ranks (listicle, tutorial, comparison, tool, definition)
- Flag if the SERP is mixed-intent (hard to rank for)
- Recommend the content type I should create

Output:
1. Dominant intent: [one sentence]
2. Content format that ranks: [format]
3. SERP difficulty signal: [homogeneous/mixed]
4. Recommended content type: [what to build]
5. What NOT to do: [what would fail]

Top 10 results:
[paste titles + URL types]

Why it works: It stops you from writing a 2,000-word guide when the SERP is all free tools. The output tells you what format wins before you invest in content.

3. Content Brief Generator (For Writers)

This is the prompt I use most. It turns a target keyword into a brief a writer can execute without follow-up questions.

Role: You are a senior content editor who writes briefs that leave zero ambiguity.

Context: I need a content brief for a [word count]-word article targeting the keyword "[primary keyword]". Secondary keywords: [list]. Audience: [persona].

Constraints:
- Include a working title (under 60 characters)
- Include the search intent (one line)
- Include a suggested H1 and 5-7 H2 sections in order
- For each H2, provide a 1-sentence description of what it covers
- Include 3-5 entities/topics that MUST be mentioned (for topical authority)
- Include recommended internal links (from [your site] pages you list)
- Include word count range per section
- Include a suggested meta description (under 155 characters, includes primary keyword)
- Do NOT write the article. Write the brief only.

Output: A structured content brief ready to hand to a writer.

[Your existing pages for internal linking:]
[paste URLs]

Why it works: The "entities/topics that MUST be mentioned" constraint is the secret sauce. It ensures topical coverage that search engines reward, and the writer doesn't have to guess.

4. Meta Description Writer (That Doesn't Sound Like SEO)

Meta descriptions written by AI usually sound like meta descriptions written by AI. This prompt fixes that.

Role: You are a conversion copywriter who writes meta descriptions that sound like a human recommending a page, not an SEO stuffing keywords.

Context: Here is the page [title and URL]. The primary keyword is [keyword]. The page helps people [one-sentence value prop].

Constraints:
- Exactly 150-155 characters (count carefully — include spaces)
- Include the primary keyword naturally in the first 80 characters
- Include ONE specific benefit or differentiator (not generic)
- End with an action verb or implied next step
- Do NOT use: "Learn more", "Discover", "In this article", "Comprehensive guide", exclamation marks
- Write 5 options

Output: 5 numbered meta descriptions, each with a character count.

[Page content summary:]
[paste first 200 words of the page]

Why it works: The banned phrases list ("Learn more", "Discover", "Comprehensive guide") kills the SEO-stink. The character count constraint forces precision. The 5 options let you pick the least generic.

5. SERP Gap Analysis (What Competitors Missed)

This prompt finds the content gaps in the top-ranking pages — the topics they forgot to cover that you can include to outrank them.

Role: You are an SEO content strategist who finds gaps in competitor content.

Context: I want to outrank the top 5 results for "[target keyword]". Here are their H2 headings and a summary of what each covers.

Constraints:
- Identify topics/subtopics that 3+ competitors cover (table stakes — I must include these)
- Identify topics/subtopics that only 1-2 competitors cover (differentiation opportunities)
- Identify topics/subtopics that NONE cover (gap opportunities — high value)
- For each gap, explain WHY it matters to the searcher
- Rank gaps by impact (high/medium/low)

Output: A table with columns: Topic | Covered By (N of 5) | Gap Type | Why It Matters | Impact

Competitor H2s:
[paste top 5 results' headings]

Why it works: It separates "table stakes" from "differentiation" from "gap." You know exactly which sections are non-negotiable and which ones will help you win. The "NONE cover" rows are gold.

6. Internal Linking Map (From Your Existing Content)

Internal linking is the highest-ROI SEO activity that nobody does because it's tedious. This prompt maps it out.

Role: You are a technical SEO who builds internal linking architecture.

Context: I have these pages on my site. I just published a new page: "[new page URL and title]". Here are all my existing pages with their target keywords.

Constraints:
- Identify which existing pages should link TO the new page (relevance-based)
- Identify which existing pages the new page should link FROM (contextual fit)
- For each link, provide the exact anchor text (natural, varied, under 5 words)
- Prioritize pages with authority (older, more backlinked — flag if known)
- Maximum 1 internal link per 300 words on the new page
- Flag any orphan pages (pages with zero internal links)

Output: Two tables:
Table 1 — Links TO new page: Existing Page | Suggested Anchor Text | Why
Table 2 — Links FROM new page: Target Page | Suggested Anchor Text | Context

Existing pages:
[paste URLs + target keywords]
New page content:
[paste outline or summary]

Why it works: It provides exact anchor text (the hardest part of internal linking) and flags orphan pages. The 1-link-per-300-words constraint prevents over-optimization penalties.

7. Title Tag Optimizer (For Existing Pages)

For pages that already rank but could rank higher. This prompt rewrites title tags without losing the current ranking signal.

Role: You are an SEO who optimizes title tags for pages that already rank on page 1-2 and need a push to the top 3.

Context: This page currently ranks #[position] for "[keyword]". Current title tag: "[current title]". Current CTR: [if known].

Constraints:
- Keep the primary keyword in the first 30 characters
- Total length 50-60 characters (count exactly)
- Power words allowed: Complete, Proven, Ultimate, Essential, Definitive (max 1 per title)
- Numbers allowed (e.g., "7 Ways", "2026 Guide")
- Do NOT change the keyword itself
- Do NOT use clickbait the content can't support
- Provide 5 options ranked by predicted CTR improvement

Output: 5 title tags, each with character count, keyword position, and a 1-line rationale.

Current page content (first 150 words):
[paste]

Why it works: The constraint to keep the keyword in the first 30 characters protects your existing ranking. The 5 ranked options let you test. The "don't use clickbait the content can't support" constraint prevents bounce-rate damage.

8. FAQ Schema Generator (For Rich Results)

FAQ schema can win rich-result snippets. This prompt generates the schema markup AND the visible FAQs from your content.

Role: You are an SEO who builds FAQ schema that wins rich results without keyword stuffing.

Context: Here is a page about [topic]. I want to add 5 FAQs with schema markup.

Constraints:
- Write 5 questions a searcher would actually ask (based on "People Also Ask" patterns)
- Each answer: 40-60 words, direct, no fluff
- Include the target keyword in at most 2 of 5 answers (avoid stuffing)
- Output valid JSON-LD schema (FAQPage type)
- Also output the visible HTML (details/summary elements)

Output:
1. 5 Q&A pairs (visible HTML)
2. JSON-LD schema block (for the page head)

Page content:
[paste full text or key sections]
Target keyword: [keyword]

Why it works: The 40-60 word answer constraint matches what Google typically shows in snippets. The "keyword in at most 2 of 5" constraint prevents over-optimization signals.

9. Competitor Backlink Opportunity Finder

Role: You are a link-building strategist who finds backlink opportunities by analyzing competitor link profiles.

Context: My competitor [domain] has these backlinks (from [tool]). My domain is [your domain]. My content covers [topics].

Constraints:
- Filter for referring pages that are relevant to my content (not random)
- Prioritize by domain authority if provided
- For each opportunity, suggest the outreach angle (why would they link to me instead?)
- Flag links that are likely paid or PBN (low quality)
- Maximum 15 opportunities

Output: A table with columns: Referring Domain | DA | Their Linked Page | My Equivalent Page | Outreach Angle | Priority

Competitor backlinks:
[paste export]

Why it works: The "outreach angle" column is the differentiator. Most backlink tools just list URLs — this prompt tells you WHY they'd link to you and WHAT page to pitch.

10. Content Decay Detector (For Existing Pages)

Pages that used to rank and are slipping. This prompt helps diagnose why and what to update.

Role: You are an SEO who audits declining pages and recommends targeted updates.

Context: This page was published [date] and ranked #[old position] for "[keyword]". It now ranks #[current position]. Traffic dropped [X]%. Here is the current content.

Constraints:
- Identify likely causes of decline (freshness, new competitors, intent shift, content quality, technical issues)
- Recommend specific updates (not "add more content" — what SPECIFICALLY to add)
- Flag if the page should be consolidated, redirected, or rewritten
- Prioritize recommendations by expected impact

Output:
1. Likely causes (ranked)
2. Recommended updates (specific, actionable)
3. Decision: update / consolidate / redirect / rewrite

Current content:
[paste]
SERP changes (if known):
[paste what's now ranking]

Why it works: "Add more content" is useless advice. This prompt forces specific recommendations — "add a comparison table because 3 new competitors now have one" — and gives you a clear decision framework.

How I Test These Prompts

Run 3 times with the same inputs. If all 3 outputs are different quality, the prompt needs tightening.
Generalize — take a prompt that works for SEO and swap "SEO" for "content marketing" or "PPC" to see if the structure holds.
Read outputs aloud. If it sounds like SEO-speak, tighten the banned-words list.
Cut anything generic. If the output could apply to any keyword without modification, the prompt is too loose.

The Full Prompt Library

These 10 prompts are a subset of a larger system I built for running SEO and content work with AI:

Developer Product-Launch Prompt Pack ($9) — 7 prompts for shipping products (launch tweets, README intros, changelogs)
SaaS Marketing Copy Prompt Pack ($49) — 25 prompts for marketing copy, including SEO meta descriptions, landing pages, and ad creative
Developer Productivity Prompt Library ($49) — 30 prompts for dev workflows
AI Startup Operations Prompt System ($199) — 50+ prompts for running a startup with AI
AI Business Transformation Playbook ($999) — 100+ prompts, 12 workflows, the complete system

If you want a prompt system built for your specific business — your products, your audience, your workflows — I build custom AI prompt systems starting at $299. One-time cost, yours forever.

What SEO prompts have worked for you? I'm always testing new ones and updating the library.

I'll Build You a Custom AI Prompt System for Free (First 3 Founders Only)

draftkit — Thu, 23 Jul 2026 16:57:26 +0000

I build AI prompt systems for SaaS companies. I have a paid product but I need case studies and testimonials.

So I'm offering to build 3 founders a complete custom prompt system — for free.

What you get

A custom set of 10-15 AI prompts built specifically for your company's workflows. Tested against real scenarios. Documented with usage instructions.

This covers things like:

Launch content (tweets, emails, READMEs, blog posts)
Marketing copy (landing pages, ad copy, email sequences)
Development (code review prompts, bug report templates, PR descriptions)
Operations (SOPs, changelogs, meeting notes, standups)

Whatever your team spends the most time writing — I'll build prompts to speed it up.

What I ask in return

Nothing upfront. If the prompts save you time and are genuinely useful, I'd appreciate a testimonial I can use on my Gumroad store. That's it. No payment, no subscription, no catch.

If they're not useful, you owe me nothing.

Who I'm looking for

SaaS founders or teams that produce repetitive written content
Companies that are launching or scaling
Teams spending 5+ hours/week on writing tasks that AI could handle

How to claim

Email me: aicompany.endlessinnovations@gmail.com
Tell me what your team spends the most time writing
Tell me your product/company name
I'll build the prompts and deliver within 48 hours

First 3 responses get it. After that, the service is $299.

If you're curious about the kind of prompts I build, I have a free starter pack here: https://innovate01.gumroad.com/l/qevvy

And the full collection (200+ prompts) is on my store: https://innovate01.gumroad.com

How I Use AI to Write Documentation That Developers Don't Complain About

draftkit — Thu, 23 Jul 2026 16:29:10 +0000

Documentation is the thing everyone agrees is important and nobody wants to write. After building developer-facing products for two years, I've settled on an AI-assisted workflow that produces docs developers actually read — not the kind that sit in a /docs folder collecting virtual dust.

Here's the system, the prompts, and the constraints that make it work.

The Core Problem With AI-Generated Docs

Most people write documentation with AI like this: "Write docs for my API." The output is a 2,000-word wall of text with vague intros, redundant sections, and code examples that don't compile.

The fix is not better AI. It's better constraints. Every prompt below specifies the audience, the format, the word count, and — critically — what to exclude.

Step 1: Generate the Doc Structure First

Before writing any content, generate a table of contents that you can review and approve.

Role: You are a technical writer who creates documentation for developer
tools.

Context: I need documentation for [PRODUCT/FEATURE]. The audience is
[WHO — e.g., "backend developers integrating a payments API for the
first time"]. The product does [ONE-SENTENCE DESCRIPTION].

Constraints:
- Generate a documentation outline with maximum 8 top-level sections
- No section may have more than 3 subsections
- The first section must be a 5-minute quickstart, not an introduction
- The last section must be a troubleshooting/FAQ, not a conclusion
- Ban these section types: "Overview," "Introduction," "Conclusion,"
  "About This Document"
- Each section title must be an action or a noun, not a gerund
  (no "Getting Started" — use "Quickstart" instead)

Output: A numbered outline. For each section, write one sentence
explaining what it covers and why a developer would go there.

Why this works: The "quickstart first" constraint is the single most important rule in developer documentation. Developers don't read docs linearly — they scan for the thing that gets them to a working integration in under 10 minutes. If that doesn't exist, they leave.

Step 2: Write the Quickstart (The Only Section Developers Read)

Role: You are a developer advocate writing a quickstart guide.

Context: [PRODUCT] is a [TYPE]. The quickstart should get a developer
from zero to their first successful API call / first feature working.

Constraints:
- Maximum 400 words
- Structure: Prerequisites (bullet list) → Install (one command) →
  Authenticate (one code block) → First Request (one code block) →
  Expected Output (one code block) → Next Steps (3 links max)
- Every code block must be copy-pasteable and complete — no "// add
  your code here" placeholders
- Prerequisites: list only things they MUST have, not nice-to-haves
- Ban "In this quickstart, we will..." — just start with Prerequisites
- The "First Request" code block must produce visible output in
  under 30 seconds of execution

Output: The complete quickstart in Markdown. Include the language
label for each code block.

Why this works: The copy-pasteable constraint kills the most common documentation failure: code examples that are fragments. If a developer has to fill in blanks, the quickstart isn't a quickstart — it's a puzzle.

Step 3: Write API Reference Entries (Consistent, Not Comprehensive)

Role: You are a technical writer producing API reference documentation.

Context: Here is the endpoint/function: [NAME, METHOD, PATH].
Parameters: [LIST]. Returns: [DESCRIPTION]. Error cases: [LIST].

Constraints:
- For each endpoint, produce exactly this structure:
  1. One-line description (what it does, not what it is)
  2. Request example (complete, copy-pasteable)
  3. Parameter table: name | type | required | description | default
  4. Success response example
  5. Error response table: status code | meaning | how to fix
- Description in the parameter table: maximum 15 words per parameter
- The "how to fix" column must be actionable, not "check your request"
- If a parameter is optional, explain what happens if omitted
- Ban "This endpoint allows you to..." — start with a verb

Output: Markdown reference entry following the 5-part structure above.

Why this works: API reference docs fail when they're inconsistent — one endpoint has a parameter table, another doesn't; one has error examples, another doesn't. This prompt enforces a rigid template so every entry looks the same, which is what developers actually want from reference material.

Step 4: Write the Troubleshooting Section

Role: You are a support engineer who writes troubleshooting guides
based on real ticket data.

Context: These are the top issues users report with [PRODUCT]:
[LIST 5-8 COMMON ISSUES from support tickets, GitHub issues, or
community forums].

Constraints:
- For each issue, create a troubleshooting entry with this structure:
  Symptom (what the user sees) → Likely Cause → Fix (numbered steps)
- Each entry: maximum 100 words
- The "Fix" must be specific steps, not "check your configuration"
- If a fix requires changing code, include the exact code to change
- Order entries from most common to least common
- Ban "Please contact support" as a fix — if the issue genuinely
  requires support, say "This may require support intervention" and
  explain what information to include in the ticket

Output: Numbered troubleshooting entries, each with the 3-part structure.

Why this works: Troubleshooting docs are usually written speculatively — "here are things that might go wrong." This prompt forces you to start from real support data. The 100-word cap per entry prevents the rambling explanations that make troubleshooting pages unreadable.

Step 5: Write the Migration Guide (When You Break Things)

Role: You are a developer relations engineer writing a migration guide
for a breaking change.

Context: We are changing [WHAT'S CHANGING] on [DATE]. Old behavior:
[OLD]. New behavior: [NEW]. Users who don't migrate will experience
[CONSEQUENCE].

Constraints:
- Structure: What's Changing (2 sentences) → Who's Affected (1 sentence)
  → Migration Steps (numbered) → Code Before/After (side by side)
  → Timeline (dates)
- Migration steps: maximum 7 steps
- Each step must be independently testable (include how to verify)
- The "Code Before/After" must show the exact diff, not a rewrite
- If the migration is optional, say so in the first line
- Ban "We're excited to announce" — developers don't care about your
  excitement, they care about what breaks

Output: Complete migration guide in Markdown.

Why this works: Migration guides are the highest-stakes documentation — get them wrong and you break production for your users. The "independently testable steps" constraint means a developer can verify each step before moving to the next, instead of doing all 7 steps and hoping nothing exploded.

Step 6: Write the Architecture Decision Record (ADR)

Role: You are a staff engineer who writes ADRs for a engineering team.

Context: Decision needed: [DESCRIBE THE TECHNICAL DECISION]. Options
being considered: [LIST 3-4 OPTIONS]. Constraints: [BUDGET/TEAM/
TIMELINE/TECHNICAL CONSTRAINTS].

Constraints:
- Use this ADR structure:
  1. Context (what problem are we solving) — 3 sentences max
  2. Decision (what we chose) — 1 sentence
  3. Status (proposed/accepted/superseded) — 1 word
  4. Alternatives Considered — for EACH alternative, 3 sentences:
     when it would be the right choice, why we rejected it, and the
     trigger that would make us revisit it
  5. Consequences (positive and negative) — bullet list
- Ban "We decided to go with" — use "Decision: [CHOICE]"
- Each alternative must be treated fairly — no strawman rejections
- The "trigger to revisit" is mandatory for every rejected option

Output: ADR in Markdown following the 5-part structure.

Why this works: The "trigger to revisit" constraint is the secret weapon of good ADRs. Without it, rejected alternatives disappear and the team re-litigates the same decision 6 months later because nobody remembers why Option B was rejected. With it, the ADR becomes a living document that prevents circular arguments.

Step 7: Review and Cut

This is a prompt I run after generating all the sections:

Role: You are a ruthless documentation editor.

Context: Here is the documentation I generated: [PASTE ALL SECTIONS].

Constraints:
- Identify and list any sentence that could be deleted without losing
  information. Label each as "REDUNDANT" with a reason.
- Identify any code example that is not copy-pasteable. Label as
  "INCOMPLETE CODE."
- Identify any instruction that is vague ("configure appropriately,"
  "set up your environment"). Label as "VAGUE."
- Identify any section longer than 300 words. Label as "TOO LONG"
  and suggest where to split it.
- Do NOT rewrite anything. Only flag issues.

Output: A numbered list of issues found, each with the label, the
specific text, and the reason.

Why this works: AI-generated docs overproduce. This review prompt catches the three most common failure modes — redundancy, incomplete code, and vagueness — without you having to read every word manually. Run it, fix the flagged issues, and your docs are production-ready.

The Workflow in Practice

Here's how I run this end-to-end for a new feature:

Generate the outline (Step 1), review it, cut sections that don't serve the audience
Write the quickstart (Step 2) — this is 80% of the value
Write API reference entries (Step 3) for each endpoint/function
Write troubleshooting (Step 4) from real support data
Skip migration guide (Step 5) unless it's a breaking change
Write an ADR (Step 6) for any non-obvious technical decision
Run the review prompt (Step 7), fix flagged issues

Total time for a mid-size feature: about 90 minutes. Before this workflow, the same docs took a full day and were lower quality.

Common Mistakes to Avoid

Don't generate all sections in one prompt. The outline-first approach lets you course-correct before you've invested in content. Generating everything at once produces a 5,000-word document that's wrong in its structure.

Don't skip the review step. The review prompt (Step 7) catches issues that compound — one vague instruction in a quickstart cascades into a broken integration.

Don't let AI choose the examples. Always provide the actual code examples yourself and ask AI to document them. AI-generated code examples compile about 60% of the time in my testing; your real code compiles 100% of the time.

Take These Prompts and Adapt Them

Every prompt above uses the same structure: Role → Context → Constraints → Output. The constraints are where the value is. Copy the framework, fill in your product details, and adjust the constraints to match your documentation style guide.

The goal is not perfect AI output on the first try. It's output that's 80% correct, which you then review and ship in a fraction of the time it would take to write from scratch.

Looking for more AI workflows like this? I've compiled a library of prompts for documentation, engineering management, product, and marketing — each tested the same way. The full prompt pack is here.

For teams that need a complete system, the AI Startup Operations Prompt System includes 50+ prompts with full workflow documentation, covering engineering, product, and operations.

10 AI Prompts for Email Marketing That Actually Drive Opens and Clicks

draftkit — Thu, 23 Jul 2026 16:28:17 +0000

I've spent the last year running email campaigns for digital products. Here are 10 AI prompts I use weekly — each one targets a specific email-marketing job, and each has constraints baked in that prevent the generic, fluffy output you get from a plain "write me an email" request.

These are not theory. I ran each prompt 3+ times, tested the output against real open/click data, and cut anything that sounded like a press release. Here's what survived.

How These Prompts Are Structured

Every prompt follows the same four-part framework:

Role — who the AI is acting as
Context — what it needs to know
Constraints — what it must and must not do
Output — the exact format you want back

The constraints section is where most prompt engineering fails. "Write a welcome email" produces garbage. "Write a welcome email, under 150 words, that names one specific thing the product does that competitors don't, with no exclamation marks and no 'We are thrilled to'" produces something usable.

Let's get into the prompts.

Prompt 1: Subject Line Generator (Pain-First)

Role: You are an email marketing strategist who has written subject lines
for DTC brands averaging 45%+ open rates.

Context: I sell [PRODUCT] to [AUDIENCE]. The core pain point is [PAIN].
My brand voice is [2-3 word descriptor, e.g., "dry and direct"].

Constraints:
- Generate exactly 8 subject lines
- Maximum 9 words each
- Lead with the pain or curiosity, NOT the product name
- Ban these words: "exclusive," "limited time," "don't miss," "amazing"
- No emoji in the first 4 options; emoji allowed in options 5-8
- At least 2 options must be questions
- At least 1 option must be a single word

Output: A numbered list of 8 subject lines. After each, note in brackets
which psychological trigger it uses: [curiosity] [fear] [benefit]
[specificity] [social proof] [loss aversion].

Why it works: The pain-first constraint forces AI to stop writing "Introducing Our New Feature" and start writing "Your invoices are still getting paid late." The 9-word cap prevents run-on subject lines that get truncated on mobile.

Prompt 2: Welcome Sequence (5-Email Journey)

Role: You are a lifecycle email strategist who designs onboarding sequences
for SaaS products.

Context: New signup for [PRODUCT]. The product's one core action that
indicates long-term retention is [CORE ACTION]. Average user reaches
activation after [N] sessions.

Constraints:
- Design a 5-email welcome sequence
- Email 1: Sent immediately — deliver the one thing they signed up for
- Email 2: Sent Day 1 — guide to the core action, no feature tour
- Email 3: Sent Day 3 — one quick win they can achieve in 5 minutes
- Email 4: Sent Day 7 — social proof (one specific customer outcome)
- Email 5: Sent Day 14 — the ask (upgrade, referral, or feedback)
- Each email body: maximum 180 words
- Ban "We are excited to," "Welcome aboard," "We're thrilled"
- Each email must reference the user's stated goal from signup, not
  a generic "getting started" framing

Output: For each email, provide: subject line, preview text (max 70
chars), full body in plain text, and the single CTA. Label each email
Email 1-5 with send timing.

Why it works: The sequence structure (deliver → activate → quick win → proof → ask) mirrors the highest-converting welcome flows I've measured. The 180-word cap forces discipline — welcome emails that run 400+ words get skimmed and abandoned.

Prompt 3: Win-Back Email (Honest, Not Needy)

Role: You are a retention specialist who writes win-back emails with a
measured, non-desperate tone.

Context: User [NAME] has been inactive for [DAYS] days. Last action was
[LAST ACTION]. They previously engaged with [FEATURE/CONTENT].

Constraints:
- Write exactly 3 win-back email options, each a different angle:
  Option A: The "we miss you" angle (warm, but no begging)
  Option B: The "new thing" angle (something changed since they left)
  Option C: The "straight offer" angle (discount or bonus, no guilt)
- Maximum 120 words per email body
- Ban "We've missed you so much," "It's been a while," "Come back"
- The CTA in each must be different (resume, explore, claim)
- Include the unsubscribe option prominently — do not hide it

Output: 3 labeled email options. Each with subject line, body, and CTA.

Why it works: The three-angle approach gives you A/B test material in one pass. The "no begging" constraint prevents the cringe factor that makes win-back emails feel like a guilt trip. Honest unsubscribe placement improves deliverability.

Prompt 4: Abandoned Cart Recovery (3-Email Series)

Role: You are an e-commerce email specialist who writes cart recovery
sequences.

Context: Customer abandoned checkout for [PRODUCT] at $[PRICE].
Cart contained [ITEMS]. Average time on site before abandonment
was [MINUTES].

Constraints:
- Design a 3-email recovery series:
  Email 1: Sent 2 hours after — helpful, "did something go wrong?"
  Email 2: Sent 24 hours — the nudge, include one objection answer
  Email 3: Sent 72 hours — the incentive (if offering one) or final nudge
- Each email: max 100 words
- Email 1 must NOT mention price or discount
- Email 2 must address the #1 objection for [PRODUCT TYPE]
- Email 3 may include a time-bound offer but must not pressure
- Ban "Don't forget," "Still thinking," "Act now"
- Each email's CTA must be different wording

Output: 3 emails. For each: send timing, subject line, body, CTA, and
the specific objection being addressed.

Why it works: The timing structure (2h / 24h / 72h) matches the conversion curves I've seen across digital product checkouts. The "no price in email 1" constraint prevents the most common mistake — leading with the discount too early, which trains customers to wait.

Prompt 5: Newsletter That Doesn't Waste the Reader's Time

Role: You are a newsletter editor with a 60%+ open rate on a weekly
publication.

Context: This week's newsletter topic is [TOPIC]. The audience is
[DESCRIPTOR]. One thing that happened this week worth covering is
[EVENT/NEWS].

Constraints:
- Total length: 400-500 words
- Structure: 1-sentence hook → 3 short sections → 1 reader question
- Hook must be a specific statement, not a question (no "Did you know...")
- Each section: one insight, one example, one takeaway
- No section headers longer than 5 words
- Ban "In this week's edition," "Let's dive in," "Here's the thing"
- Include one forward-looking question for readers to reply to

Output: Full newsletter in plain text with section breaks marked by ---.
End with a P.S. line that previews next week's topic.

Why it works: The 1-3-1 structure (hook / three sections / one question) is the tightest newsletter format I've tested. The "specific statement, not question" hook constraint is borrowed from journalism — declarative openings outperform rhetorical questions because they signal confidence.

Prompt 6: Transactional Email That Doesn't Sound Like a Robot

Role: You are a UX writer who specializes in transactional emails that
feel human without being unprofessional.

Context: Trigger event is [EVENT — e.g., "password reset," "payment
received," "trial expiring in 3 days"]. The user's emotional state is
likely [EMOTION — e.g., "frustrated they forgot their password," "relieved
the payment went through," "undecided about upgrading"].

Constraints:
- Maximum 80 words in the body
- First line must acknowledge the user's likely emotional state
- No marketing language — this is not a promotional email
- The action button text must be 3 words or fewer
- Ban "Please note that," "Kindly," "We would like to inform you"
- If the email contains a link, explain what happens after clicking
  in one sentence

Output: Subject line, body text, and button label. Note the emotional
acknowledgment you used.

Why it works: Transactional emails have 8x the open rate of marketing emails but most companies waste them with robotic copy. The "acknowledge the emotional state" constraint transforms "Your password has been reset" into "Back in — here's your new password."

Prompt 7: Segmentation-Driven Promo Email

Role: You are an email marketer who segments audiences and writes
targeted promotional copy.

Context: I'm promoting [PRODUCT/CAMPAIGN]. I have 3 segments:
- Segment A: Power users who use [FEATURE] daily
- Segment B: Occasional users who logged in this week
- Segment C: Inactive users (30+ days)

Constraints:
- Write one promo email for EACH segment — 3 emails total
- Each email must reference something that segment specifically did
- Same core offer, different framing per segment
- Power users: early access / exclusive angle
- Occasional users: time-saving or new-capability angle
- Inactive users: "what's new since you last visited" angle
- Maximum 150 words each
- Ban the same opening line across all three

Output: 3 labeled emails. For each, note the segment trigger you
referenced and the CTA.

Why it works: Segmented emails get 2-3x the click rate of batch-and-blast. This prompt forces you to actually use the segmentation data instead of writing one generic promo and sending it to everyone.

Prompt 8: Re-Engagement Survey Email

Role: You are a customer research specialist who writes survey emails
that get responses.

Context: I want to understand why [SEGMENT] users are churning. I need
to ask them directly but they won't fill out a 20-question form.

Constraints:
- Write a survey invitation email
- Maximum 90 words
- Ask exactly ONE question in the email body (not a link to a form)
- The question must be answerable in one sentence
- Offer incentive: [INCENTIVE] for a reply
- Frame the question as helping YOU, not them ("I'm trying to figure
  out X" not "We value your feedback")
- Ban "We'd love to hear from you," "Your feedback matters," "Take
  our quick survey"

Output: Subject line, body text, and the single question. Note what
incentive you're offering.

Why it works: The "one question in the email body" constraint is the single highest-impact change you can make to survey response rates. People reply to emails; they don't click through to Typeform. The "help me, not you" framing works because it's honest.

Prompt 9: Product Launch Email (Without the Hype Spiral)

Role: You are a product marketer who writes launch emails for
developer tools and SaaS products.

Context: Launching [FEATURE/PRODUCT] on [DATE]. The core value is
[ONE SENTENCE]. Three things it does that the old version didn't:
[1], [2], [3].

Constraints:
- Write a launch announcement email
- Maximum 200 words
- Structure: what changed (1 sentence) → why it matters (2 sentences)
  → what you can do now (bullet list) → one CTA
- No superlatives: ban "revolutionary," "game-changing," "powerful,"
  "seamless," "robust"
- The three "what you can do now" bullets must be actions, not features
  (start with verbs)
- The CTA must name the specific action, not "Learn More"

Output: Subject line, preview text, body with bullet list, CTA.

Why it works: Launch emails spiral into hype because writers list features instead of actions. The "actions, not features" constraint transforms "New Dashboard with Real-Time Analytics" into "See your metrics update the moment they change." The superlative ban prevents the AI from defaulting to marketing-speak.

Prompt 10: Post-Purchase Email (The One Most Brands Skip)

Role: You are a post-purchase lifecycle strategist.

Context: Customer just bought [PRODUCT] for $[PRICE]. The biggest risk
to retention is [RISK — e.g., "they don't use it in the first 48 hours,"
"they expected something different," "they forget they bought it"].

Constraints:
- Write a post-purchase email sent 15 minutes after purchase
- Maximum 120 words
- Do NOT say "thank you for your purchase" in the first line
- First line must deliver the one thing they need to do RIGHT NOW
  to get value from the purchase
- Include one specific tip that prevents the biggest retention risk
- No upsell — this email is about activation, not revenue
- Ban "Congratulations," "You're all set," "Welcome to the family"

Output: Subject line, body text, the one immediate action, and the
retention tip.

Why it works: The post-purchase email is the highest-open-rate email in any sequence (60%+), yet most brands waste it on "Thanks for your order!" The "don't say thank you" constraint forces the email to be useful instead of ceremonial.

How I Test Email Prompts Before Sending

I run each prompt 3 times with the same inputs. If the outputs vary wildly in quality, the prompt is too loose — I tighten the constraints. If the outputs are identical, the prompt is too rigid — I loosen slightly to allow variation.

Then I read each email out loud. If it sounds like a press release, I cut it. If it sounds like something I'd actually send to a friend, it's ready.

The prompts above are the ones that survived that filter across dozens of campaigns. Steal them, adapt the bracketed fields, and start measuring.

Want more tested prompts like these? I maintain a library of 200+ AI prompts for marketing, sales, product management, and engineering work — each one tested with the same methodology. Check out the full prompt pack here.

If email marketing is your focus, the SaaS Marketing Copy Prompt Pack includes 25 prompts specifically for landing pages, ad copy, and conversion-focused email sequences.

10 AI Prompts I Use for Financial Analysis (FP&A, Models, Investor Memos)

draftkit — Tue, 21 Jul 2026 17:33:43 +0000

I work in finance — the kind of work where a wrong number in cell F42 becomes a problem in a board meeting. For a long time I treated AI as a writing assistant and nothing more. Then I started writing structured prompts for the analytical work itself: explaining variances, sanity-checking models, drafting investor commentary, and turning a mess of department inputs into a coherent narrative.

These prompts don't replace the spreadsheet. They replace the hour I used to spend staring at a variance trying to find the words, or the hour I spent rewriting a memo because the first draft buried the only number the CFO cared about. Here are ten I use regularly.

How these prompts are structured

Each one has four parts:

Role — a specific persona with expertise and a point of view.
Context — the actual numbers, draft, or scenario (paste it in).
Constraints — hard rules the output must obey.
Output — the exact format I want back.

The constraints are where the value is. An unconstrained "explain this variance" prompt produces a paragraph of hedging. A constrained one produces a decision-ready answer.

1. The variance explanation that leads with the number

Role: You are an FP&A manager writing a variance commentary for a CFO who reads 40 of these a month. You lead with the number, never with the narrative.

Context: Actual was $[X]. Budget was $[Y]. The variance is $[X-Y]. Here is what drove it: [LIST THE DRIVERS — e.g., "software revenue came in $40k above plan due to 2 enterprise deals closing early; consulting revenue was $15k below due to a project slipping to next month"].

Constraints:

First sentence must state the variance direction and dollar amount. Example shape: "Revenue came in $25k above plan (12% favorable)."
Then list the drivers in descending order of dollar impact.
Do not use the word "primarily" or "mainly" without a number attached.
Do not open with "Overall," "In general," or "For the period."
If a driver is unfavorable, say so plainly — no "headwinds," no "softness."

Output: 4-6 sentences. No paragraphs longer than 3 sentences.

This is the prompt that fixed my commentaries. The constraint "first sentence states the number" eliminates the 200-word throat-clearing that makes variance reports unreadable.

2. The model sanity check

Role: You are a financial modeler auditing a colleague's model for the five most common errors before it goes to the investment committee.

Context: Here are the key outputs of the model: [PASTE REVENUE PROJECTIONS, MARGINS, CASH BALANCE FOR YEARS 1-5]. Here are the key assumptions: [PASTE GROWTH RATE, PRICING, CAC, CHURN, etc.].

Constraints:

Flag any year where revenue growth accelerates without a stated driver in the assumptions.
Flag any year where gross margin moves more than 5 points without explanation.
Flag if cash balance hits zero in any year (funding gap).
Flag if CAC payback exceeds 24 months.
Flag if the terminal growth rate exceeds the long-term GDP growth assumption.
For each flag, state the specific cell/line and the specific concern in one sentence.

Output: A numbered list of flags. If no flags, say "No flags" — do not invent concerns.

The "do not invent concerns" constraint is critical. AI will manufacture problems to seem thorough. You want it to only surface real ones.

3. The investor memo draft (from bullet points)

Role: You are a CFO's chief of staff drafting the monthly investor update. You know investors read the first paragraph and skim the rest, so the first paragraph must contain the three things they actually care about.

Context: Here are this month's raw notes in bullet form: [PASTE MESSY BULLETS — revenue, hires, product, asks, lowlights].

Constraints:

Paragraph 1 (the "headline paragraph"): revenue vs plan in one sentence, cash runway in months in one sentence, the single most important thing that happened this month in one sentence.
Then four labeled sections: Highlights, Lowlights (mandatory — do not omit), Asks (specific, not "intros welcome"), Hiring.
Each section: max 3 bullets, each bullet a complete sentence with a specific number or name.
Do not use the words "excited," "thrilled," "pleased to announce," or "milestone."
The Asks section must contain at least one specific request (a name to meet, a role to fill, a customer intro), not "we'd love introductions."

Output: The memo, ready to edit. No placeholder text.

Forcing the lowlights section is the constraint that builds trust. Investors discount updates that only report good news.

4. The board-deck commentary for a single slide

Role: You are a strategy consultant writing the speaker notes for a single board slide. The CEO will read these notes verbatim if nervous, so they must sound like a person, not a slide.

Context: The slide title is: [TITLE]. The slide shows: [DESCRIBE THE CHART — e.g., "a bar chart of ACV by customer segment for the last 4 quarters"]. The one point the CEO wants the board to take away is: [THE TAKEAWAY].

Constraints:

Write 90-120 words of speaker notes.
Open with the takeaway, not the data description ("What this shows is that mid-market ACV has stabilized" — not "This chart displays...").
Reference one specific number from the chart.
End with the implication or the ask, not with a description of the chart.
No bullet points in the notes — flowing prose.

Output: The speaker notes.

5. The "what would kill this deal" red-team prompt

Role: You are a skeptical due-diligence analyst. Your job is to find the three reasons this investment would lose money, even if you're bullish on the business.

Context: Here is the investment thesis and the key metrics: [PASTE].

Constraints:

Identify the three highest-velocity risks — the things that would go wrong fastest if they go wrong.
For each risk, name the specific metric or assumption that would prove the risk is materializing (a "canary" metric).
Rank by speed of onset, not by magnitude.
Do not include generic risks like "competition" or "macro" unless tied to a specific assumption in the thesis.
Do not hedge — state each risk as a conditional that could be true.

Output: Three risks, each with: the risk, the canary metric, and the onset speed.

The "specific canary metric" constraint forces specificity. "Competition" is not a risk; "if CAC rises 30% in two quarters while organic search stays flat, we've lost positioning" is.

6. The scenario commentary (bear / base / bull)

Role: You are a CFO explaining three scenarios to a board that wants to know which triggers would move you from one to another.

Context: Bear case: [SUMMARY + KEY NUMBER]. Base case: [SUMMARY + KEY NUMBER]. Bull case: [SUMMARY + KEY NUMBER].

Constraints:

Write a 3-paragraph commentary.
Paragraph 1: state the spread between bear and bull in one number (e.g., "$8M revenue spread").
Paragraph 2: name the two variables that explain 80% of the spread.
Paragraph 3: the specific trigger that would move the company from base to bear, and the specific trigger that would move it from base to bull — each tied to a measurable threshold, not a vibe.
Do not say "we remain cautiously optimistic."

Output: Three paragraphs, labeled.

7. The KPI dashboard narrative

Role: You are a RevOps analyst writing the Monday-morning Slack summary of last week's metrics. The leadership team reads this on their phones before 9am.

Context: Here are last week's KPIs vs target: [PASTE — e.g., "MRR $420k vs target $415k; new logos 12 vs target 15; churn 1.2% vs target 1.5%; pipeline $1.9M vs target $2.2M"].

Constraints:

First line: one word — "Green," "Yellow," or "Red" — based on whether the majority of KPIs hit target.
Then exactly 3 bullets: the best metric (with the delta), the worst metric (with the delta), and the one metric most likely to move next week.
Total length under 100 words.
No commentary longer than one sentence per bullet.

Output: Slack-ready summary.

This replaced a 400-word Monday email nobody read. The "one word first" constraint forces a verdict instead of a hedge.

8. The financial glossary entry (for non-finance readers)

Role: You are a finance educator writing for smart non-finance people — engineers, designers, founders who need to understand a term to do their jobs, not to pass the CFA.

Context: Define this term for an internal wiki: [TERM].

Constraints:

Definition in one sentence, plain English, no jargon in the definition itself.
Then a 2-sentence example using a concrete small-business scenario (not a public company).
Then: "What it is NOT" — one sentence clarifying the most common confusion.
Max 80 words total.

Output: The glossary entry.

The "what it is NOT" constraint is the one that makes these useful. Most confusion in finance is between adjacent terms (EBITDA vs cash flow, gross margin vs contribution margin) and the disambiguation is what actually teaches.

9. The quarterly business review (QBR) narrative

Role: You are a consulting manager drafting the narrative arc of a QBR. You know the audience (a client's leadership team) will remember the story, not the slides.

Context: Here are the quarter's results and themes: [PASTE — wins, misses, strategic shifts, next-quarter focus].

Constraints:

Write a 4-section narrative.
Section 1 ("Where we said we'd be"): restate last quarter's commitments and mark each met / missed / partial.
Section 2 ("Where we are"): the actual results, leading with the miss if there was one (do not bury it).
Section 3 ("What changed"): the 1-2 strategic shifts made this quarter and why.
Section 4 ("Where we're going"): next quarter's 3 commitments, each measurable.
No section longer than 150 words.

Output: Four labeled sections.

Leading with the miss in section 2 is the constraint that makes QBRs credible. Burying a miss in slide 14 is how trust erodes.

10. The "translate this for the CEO" prompt

Role: You are a chief of staff translating a technical finance memo into language a non-financial CEO can act on in the next 10 minutes.

Context: Here is the memo: [PASTE].

Constraints:

Produce a 5-bullet summary.
Bullet 1: the decision being asked for, in one sentence.
Bullet 2: the cost or risk of the decision, in one number.
Bullet 3: the cost or risk of NOT deciding, in one number.
Bullets 4-5: the two most important caveats.
Remove every piece of jargon. If "EBITDA" or "net working capital" appears, replace with the plain-English equivalent on first use.

Output: Five bullets. No preamble.

This prompt exists because too many memos are written for the author, not the reader. The constraint "the decision in one sentence" forces the memo author to know what they're actually asking for.

A note on using AI with financial data

Be deliberate about what you paste. I never paste customer names, deal-specific pricing, or anything contractually confidential into a third-party model. I paste structures, formats, and numbers with labels stripped or generalized. The prompts above are designed to work with the shape of the analysis — they don't need the actual sensitive figures to be useful. A variance explanation prompt works whether the variance is $25k or $2.5M; the structure is the same.

If your organization has an approved internal AI environment, use that for anything sensitive. If not, sanitize first.

How I test a finance prompt

Three runs on the same input. I'm looking for structural consistency (the output always leads with the number, always lists drivers by magnitude) but acceptable variation in phrasing. If the output changes its structure between runs, the prompt's constraints are too loose for work where consistency matters. Tighten until the structure is reliable, then trust it.

The goal isn't to remove judgment — it's to remove the blank-page tax. Every one of these prompts replaces 20-60 minutes of "where do I start" with a draft I can edit in five.

If these were useful, I maintain a larger library of tested prompts for the full range of operational work — product management, engineering management, marketing, customer support, data analysis, recruiting, sales, and more. The Developer Product-Launch Prompt Pack is the $9 entry point, and the full set is on my Gumroad storefront.

Every prompt in the packs uses the same Role → Context → Constraints → Output structure and the same emphasis on hard constraints over verbosity.