The swipe file: 12 templates to use.

TITLE: [Tool A] vs [Tool B] for [specific workload]
WHO THIS IS FOR: [team size / stack / use case]

1. The decision: what should the reader optimize for?
2. Quick verdict: choose A when [...] / choose B when [...]
3. Setup: steps, dependencies, time, team skills
4. Real cost: license + infrastructure + engineering time
5. Trade-offs: performance, maintenance, limits, security
6. Migration: what moves, what breaks, how to test
7. Honest recommendation with assumptions
8. One downloadable checklist / working demo

CHECK: Have an engineer review all claims. Link vendor docs.
MEASURE: Product evaluations influenced and opportunities created.

RESEARCH QUESTION: [a problem your audience debates]
DATA: [consented, anonymized product data / survey]
SAMPLE: [how many, who, when, exclusions]
METHOD: [how calculations were made]
FINDINGS: 3–5 surprising but defensible points
LIMITS: what the data does NOT show

PUBLISH:
- Main report with methods and visuals
- 3 short articles (one key finding each)
- 1 engineer-led webinar / roundtable
- 1 benchmark worksheet or calculator
- 5 founder/engineer posts with individual charts
- 1 account-specific email connecting the finding to a problem

MEASURE: Relevant conversations, backlinks, qualified pipeline.
RULE: Never invent findings or present vendor samples as the entire industry.

TITLE: How to [specific task] with [specific stack]
1. The problem and where it shows up in production
2. Prerequisites and environment versions
3. Small architecture diagram / mental model
4. Exact implementation steps + runnable snippets
5. Expected output and how to check it
6. 3 failure modes and how to debug them
7. Trade-offs / when NOT to use this approach
8. Links to docs, repos and an optional product demo

EDITORIAL REVIEW:
- Engineer checked commands and screenshots
- Claims are reproducible and limitations visible
- Useful even if the reader never buys
- No generic “everything is changing” introduction

MEASURE: Qualified activations and assisted opportunities.

TITLE: The practical guide to [recurring technical job]
WHO IT'S FOR: [team profile]
WHEN TO USE IT: [trigger]

STEP 1: Prepare the inputs and team
STEP 2: Decide roles, priorities and thresholds
STEP 3: Execute the workflow
STEP 4: Verify that it worked
STEP 5: Handle exceptions and failure modes
STEP 6: Review and improve the process

DOWNLOADABLE CHECKLIST:
[ ] Prerequisites confirmed
[ ] Owner assigned
[ ] Rollback or recovery path ready
[ ] Success metric checked
[ ] Lessons documented

LAST: Where a product can reduce manual effort (honestly).

COHORT: [100 accounts sharing a genuine trigger]
BUYER: [role with this problem]
TRIGGER: [why the problem matters this quarter]
CURRENT ALTERNATIVE: [what they use instead]
EVIDENCE: [one specific, provable result]
ASK: [technical conversation, assessment, useful resource]

EMAIL 1
Subject: [specific problem at company]
Hi [first name] — noticed [real signal].
Teams dealing with [problem] often run into [consequence].
We put together [proof / short resource].
Worth comparing notes on how you're handling [specific job]?

FOLLOW-UP: Share one useful technical fact, not “bumping this.”
TRACK BY COHORT: delivered → replies → qualified meetings →
opportunities → ARR, with warm and cold separated.

ROLE / TEAM / COMPANY:
LAST REAL INCIDENT: “Tell me what happened last time...”
COST OF THE PROBLEM: time, money, reliability, risk
CURRENT WORKAROUND: tools, humans, handoffs
TRIGGER TO CHANGE: why now, not next year?
USER / CHAMPION / BUDGET OWNER:
COMPETITORS / DO-NOTHING OPTION:
REQUIREMENTS TO TRY:
REQUIREMENTS TO BUY:
OBJECTIONS (exact words):
DEMO MOMENT THAT GOT A RESPONSE:
NEXT STEP / TIMELINE:

AFTER 10 CALLS: Count repeated pains, triggers, objections.
UPDATE: ICP, homepage, comparison pages, demo and outbound.

HEADLINE: How [customer] changed [metric] from X to Y
WHO: company, team, workload, scale
BEFORE: baseline, pain, why old approach failed
WHY NOW: buying trigger and options considered
CHANGE: what was implemented, by whom, over how long
AFTER: metric, method of measurement, time period
TRADE-OFFS: what still needs work / limitations
QUOTE: real customer language, with approval
PROOF: chart, screenshot, table, or reproducible test
NEXT STEP: related demo / architecture conversation

CUT INTO: 1-page sales PDF; comparison-page proof; 2 short
customer clips; newsletter excerpt; webinar topic.
MEASURE: Deals using the story and their stage progression.

FEATURE: [new capability]
WHO CARES: [specific practitioner]
WHAT CHANGED: [before → now, without hype]
DEMO: [one end-to-end working example]
TECHNICAL OWNER: [builder/reviewer]

BEFORE (2–3 weeks):
- Test the feature and record demo
- Engineer writes explanation; docs and FAQs checked
- Prepare screenshots, email, blog, partner notes
- Reach out to relevant users/partners in advance

LAUNCH DAY:
- Blog and docs live
- Founder/engineer posts linking to working example
- Relevant communities and partners informed
- Product and support teams available for questions

FOLLOWING WEEK:
- Publish tutorial / answer objections
- Email interested accounts with context
- Review trials, activations, qualified opportunities.

AUDIENCE: users of [popular tool/standard]
COMPLEMENTARY JOB: [the combined workflow]
PREREQUISITES: supported versions, credentials, permissions
STEP-BY-STEP: setup and working example
LIMITATIONS: what does not work / failure cases
VERIFY: sample input and expected result
MAINTAINER: who checks changes after version updates?

DISTRIBUTION:
- Docs on both sides if partner agrees
- Technical walkthrough / webinar
- Engineer post with demo
- Partner newsletter or community share

MEASURE: Activated integrations and relevant opportunities.

ACCOUNT / OWNER / RENEWAL DATE:
CURRENT USE CASE AND USERS:
VALUE DELIVERED: [measurable result]
ADOPTION HEALTH: [usage, blockers, support issues]
NEXT ADJACENT WORKLOAD:
WHY IT MAKES SENSE: [connection to existing success]
NEW TEAM / CHAMPION / BUYER:
SMALL WORKSHOP OR EVALUATION:
SUCCESS CRITERIA:
RISK TO CURRENT CUSTOMER EXPERIENCE:

OUTCOME: Continue / test / not right yet
MEASURE: Expansion ARR, gross retention and adoption.

REQUEST FORM:
- Your role and team size?
- Which tool or workflow do you use today?
- What problem are you trying to solve this month?
- What have you tried already?
- What integration or blocker matters most?

INVITATION PRIORITY:
High-fit problem + supported stack + willingness to test

AFTER INVITE:
Day 1: Can they get to first value?
Day 7: What stopped them or surprised them?
Day 14: Would they recommend it or continue using it?

MEASURE: Activation, first-value time, repeated usage.

ONE-PERSON JOB: [specific task solved in under X minutes]
MAX COST TO PROVIDE: [capacity/support constraint]
PROOF OF VALUE: [observable result]
TEAM MOMENT: [why would user invite a teammate?]
PAID MOMENT: [security/control/capacity/support requirement]

TEST:
- 20 users try the task with minimal help
- Track setup abandonment and time to first value
- Observe real teammate invitations
- Ask what blocks team adoption

DON'T SCALE UNTIL: the free path is useful AND economical.