Docs-to-Launch Checklist
Overview
Every feature release needs content support beyond the code itself. This checklist ensures nothing ships without documentation, messaging, and launch assets in place. The scope scales with the feature size — a minor fix gets a changelog entry; a major feature gets a full content campaign.
Pre-Launch Checklist
Information Architecture
- Feature page created and linked in nav
- Docs updated with new behavior
- Limitations page reviewed
- Schema docs updated (if applicable)
Messaging
- Feature headline drafted
- 3 benefit bullets written
- “How it works” section complete
- Objection handling reviewed
- Proof points identified
Assets
- Changelog entry drafted
- Social post prepared
- Email update drafted (if major)
- Screenshot captured (if visual)
Feature Release Template
For Every Feature
Documentation
| Item | Status | Owner |
|---|---|---|
| Feature page | Draft → Review → Published | Content lead |
| Docs update | Schema + behavior documented | Technical writer |
| Schema update | Frontmatter fields added to reference | Technical writer |
Messaging
| Item | Status | Owner |
|---|---|---|
| Headline | One line, benefit-first | Content lead |
| Benefits | 3 bullets: what changes for the user | Content lead |
| How it works | Step-by-step with YAML examples | Technical writer |
Assets
| Item | Status | Owner |
|---|---|---|
| Changelog | Version, date, what changed, migration notes | Content lead |
| Social | LinkedIn post + community post if applicable | Content lead |
| Screenshots | Annotated UI capture showing the feature in use | Design / Content lead |
Day 1 / Day 7 / Day 30 Content Plan
Day 1: Awareness
Announce the feature and make sure the documentation is live. The goal is that anyone who discovers the feature can immediately understand what it does and how to use it:
- Feature announcement post
- Changelog published
- Documentation live
- Social posts scheduled
Day 7: Education
Follow up with practical guidance. By now, early users have tried the feature and have questions. Address the common ones proactively:
- Tutorial or walkthrough
- Common questions documented
- Community post (if applicable)
- Follow-up social post
Day 30: Optimization
Review how the feature is landing. Refine documentation based on real usage patterns and update the objection map if new concerns have surfaced:
- User feedback reviewed
- Documentation refined
- FAQ updated
- Objection map updated
Content Types by Feature Size
Small Feature
| Content Type | Required | Optional |
|---|---|---|
| Docs update | ✓ | |
| Changelog | ✓ | |
| Social post | ✓ | |
| Feature page | ✓ |
Medium Feature
| Content Type | Required | Optional |
|---|---|---|
| Feature page | ✓ | |
| Docs update | ✓ | |
| Changelog | ✓ | |
| Social post | ✓ | |
| Tutorial | ✓ |
Major Feature
| Content Type | Required | Optional |
|---|---|---|
| Feature page | ✓ | |
| Docs section | ✓ | |
| Changelog | ✓ | |
| Social campaign | ✓ | |
| Tutorial | ✓ | |
| Email announcement | ✓ | |
| Community post | ✓ |
Quality Checklist
Before Publishing
- Spelling and grammar checked
- Links verified
- Screenshots current
- Mobile layout tested
- SEO fields complete
Messaging Quality
- Promise is clear
- Benefits are specific
- Proof is concrete
- Objections addressed
- CTA is visible
Technical Accuracy
- Schema examples correct
- Code snippets tested
- Edge cases documented
- Limitations acknowledged