The Feature Launch Brief: Fill-in-the-Blank
TL;DR
- Most product teams treat launch as the last step of building.
- There are five parts. Each stands alone, but together they form your full launch brief.
- Writing the launch copy on ship day.
- The highest-leverage moment in any product cycle isn't the code.
Most features get built in weeks and announced in an afternoon. That's backwards. The launch moment is where positioning gets set, users form first impressions, and revenue either moves or doesn't.
📋 Read time: 10 minutes. Use time: every launch you run from here.
Why This Exists
Most product teams treat launch as the last step of building. Write a changelog. Post on LinkedIn. Maybe send a newsletter. Then wonder why adoption is flat.
The teams that consistently see traction from their launches treat launch as a separate creative project. They define who the feature is for before they write the announcement. They decide what success looks like before they ship. They prepare for silence as much as they prepare for signal.
This template gives you a repeatable brief to run before every feature launch, whether it's a major product update or a small improvement your best customers have been waiting for. Fill it in, share it with your team, and launch with alignment instead of chaos.
How to Use This
- Start the brief the week you lock the scope of the feature, not the day you ship. The earlier you fill this in, the more it shapes your announcement and not the other way around.
- Use it as a team artifact. Share it with everyone who will touch the launch: product, engineering, marketing, sales. Disagreements surface early when they're cheap to fix.
- Fill every field. Blanks are decisions you're deferring. Deferred decisions become launch-day confusion.
- Revisit it post-launch. The last section of this template is a retrospective built in. Run it 2 weeks after you ship.
The Template
There are five parts. Each stands alone, but together they form your full launch brief.
Part 1: The Feature in Plain English
Fill this out first. If you can't complete it without jargon, the feature isn't ready to launch.
📄 Part 1 Template — Open to copy
FEATURE LAUNCH BRIEF
Feature name (internal): ___________________________
Feature name (public-facing, if different): ___________________________
Ship date (target): ___________________________
Brief owner: ___________________________
Last updated: ___________________________
---
PART 1: THE FEATURE IN PLAIN ENGLISH
1. What does this feature do in one sentence?
(Write it as if you're explaining to a smart friend who doesn't use your product.)
"This feature lets [user type] _________________________
so they can _________________________."
2. What did users have to do before this existed?
(Describe the workaround or the pain, not the absence of your feature.)
"Before this, they had to _________________________,
which meant _________________________."
3. What is the single most important thing users should understand about this feature?
(One sentence. Not a list.)
"_________________________."
4. What does this feature NOT do?
(Scope boundaries. Prevents wrong expectations from the first day.)
"This does not _________________________.
That's on the roadmap / out of scope because _________________________."
5. Is this feature complete, or is this v1?
[ ] Complete as designed
[ ] v1 of a larger capability (v2 will add: _________________________)
Part 2: Who This Is For
A feature built for everyone lands for no one. Name the person.
📄 Part 2 Template — Open to copy
PART 2: WHO THIS IS FOR
1. Primary user
(Not a persona name. Describe a real type of person.)
"This feature is built for _________________________
who currently struggle with _________________________
and care deeply about _________________________."
2. Are there secondary users who benefit differently?
[ ] No. This is single-audience.
[ ] Yes: "_________________________"
(Describe how their use case differs from the primary user's.)
3. Who should NOT be the target of this launch?
(Calling out the wrong audience saves support tickets and confused demos.)
"This feature is NOT a fit for _________________________
because _________________________."
4. What does the primary user already believe that this feature validates?
(Good launches confirm a belief the user already holds. Find it.)
"They already believe _________________________.
This feature proves them right."
5. Where does the primary user find out about new features?
(Check all that apply and note which is primary.)
[ ] Your product (in-app notification) — Primary? [ ]
[ ] Email newsletter — Primary? [ ]
[ ] LinkedIn / Twitter / X — Primary? [ ]
[ ] Slack community — Primary? [ ]
[ ] Direct outreach from CS / sales — Primary? [ ]
[ ] Other: _________________________ — Primary? [ ]
Part 3: The Positioning
This is where most launches go wrong. Positioning is set in the first 24 hours. If you don't set it, the market will set it for you.
📄 Part 3 Template — Open to copy
PART 3: THE POSITIONING
1. What category does this feature belong to?
(Choose one. If you're torn between two, pick the one your target user already searches for.)
"_________________________"
2. What is the before-and-after?
(The clearest launch copy is a transformation story.)
Before: "Users used to _________________________."
After: "Now they can _________________________."
3. What is the headline?
(Write 3 versions. Pick one.)
Option A (feature-forward): "_________________________"
Option B (outcome-forward): "_________________________"
Option C (problem-forward): "_________________________"
Selected headline: _________________________
Reason for selection: _________________________
4. What proof point can you attach to the launch?
(Data, beta user quote, usage number, time saved. No fabricating.)
"During beta / since shipping, _________________________."
5. What is the one thing you want users to DO after they read the announcement?
(Not feel. Do.)
"We want them to _________________________."
6. What does this launch signal about your company's direction?
(Investors and future customers read launches as strategy signals.)
"This shows that we are building toward _________________________
and that we believe _________________________."
Part 4: The Launch Plan
Tactics without a plan are just noise. This section forces specificity.
📄 Part 4 Template — Open to copy
PART 4: THE LAUNCH PLAN
1. Launch tier
(Set expectations before you plan. Not every feature is a Product Hunt day.)
[ ] Tier 1 — Major launch. Full channel activation, coordinated timing, press consideration.
[ ] Tier 2 — Standard launch. Changelog + email + social + in-app.
[ ] Tier 3 — Soft launch. In-app only or direct outreach to target segment.
Selected tier: _____
Reason: _________________________
2. Launch date and time
Target date: _________________________
Target time (and timezone): _________________________
Reason for this timing: _________________________
3. Channels and owners
Channel | Owner | Content format | Draft due
----------------------|------------------------|------------------------|----------
In-app announcement | _________________ | Banner / tooltip | _________
Email | _________________ | Newsletter / blast | _________
LinkedIn | _________________ | Post / article | _________
Changelog | _________________ | Release note | _________
Slack community | _________________ | Message | _________
Product Hunt | _________________ | Full listing | _________
Other: ____________ | _________________ | ___________________ | _________
4. Who needs to know before it goes live?
(Internal stakeholders, support team, key customers who beta-tested.)
"We need to brief _________________________ by _________________________."
5. What assets need to be created?
[ ] Product screenshot or recording
[ ] Demo video (length: _____ minutes)
[ ] Blog post
[ ] Updated docs / help center page
[ ] Social graphics
[ ] Other: _________________________
6. What is the support plan?
(Feature launches create support volume. Plan for it.)
"Anticipated questions: _________________________."
"The support team will be briefed on: _________________________."
"Escalation path for edge cases: _________________________."
Part 5: The Retrospective
Run this 2 weeks after the launch. Book the time now or it won't happen.
📄 Part 5 Template — Open to copy
PART 5: LAUNCH RETROSPECTIVE
(Complete 2 weeks post-launch. Date: _________________________)
1. What did we define as success in the brief?
"_________________________"
2. What actually happened?
Metric | Target | Actual
--------------------------------|----------------|-------
Adoption (feature activation) | _____________ | _______
Retention (returned after D7) | _____________ | _______
Support tickets / questions | _____________ | _______
Revenue impact (if tracked) | _____________ | _______
NPS / qualitative signal | _____________ | _______
3. What did we get right in the positioning?
"_________________________"
4. What did we get wrong or underestimate?
"_________________________"
5. What would we do differently in the brief itself?
"_________________________"
6. What does this launch tell us about the next one?
"_________________________"
7. Should this feature be on the next investor update?
[ ] Yes — because: _________________________
[ ] No — because: _________________________
[ ] Not yet — revisit at: _________________________
Common Pitfalls
Writing the launch copy on ship day.
The brief should be started the week scope is locked. Rushed copy is generic copy, and generic copy doesn't move anyone to act.
Targeting "everyone who uses the product."
If you write the announcement for everyone, it resonates with no one. Name the primary user. Everyone else can self-identify if the feature fits.
Leading with the feature, not the problem.
"We built X" is a feature statement. "You used to have to do Y the hard way" is a positioning statement. The second one gets shared.
Skipping the "what this is NOT" section.
Every launch without a scope boundary generates support tickets from users who thought it did something it doesn't. Set the boundary publicly.
Measuring launch success by views or likes.
Views are attention. Adoption is behavior. The only metric that matters for a feature launch is whether the right users activated and came back.
Treating the changelog as the launch.
A changelog entry is a record. A launch is a story. They serve different purposes. Don't let one replace the other.
Not briefing support before you go live.
Your support team finds out about the launch the same time as your users. They're fielding questions about something they've never seen. Brief them 24 hours ahead, minimum.
Why We Built This
The highest-leverage moment in any product cycle isn't the code. It's the decision about what to build and why. Most teams invest almost nothing in the moments before and after the code, and that's where launches fail.
ProductOS is built around the idea that research, definition, and positioning are the work. Cursor, Lovable, Bolt, and v0 are excellent at the build stage. They start at "how to build." ProductOS starts at "what to build and who it's for," then carries that context forward so nothing gets lost between the whiteboard and the shipped feature.
This template exists because we've seen what happens when teams skip the brief. The launch lands flat. Adoption numbers disappoint. The team assumes the feature was wrong, when the positioning was wrong. If you're running features through a disciplined launch process, you'll get better signal on what's actually working.
If any of this lands and you want to see it in action, we're at productos.dev. No pressure. The toolkit stands on its own.
If you'd rather have humans plus AI run this for you on a real product today, that's what 1Labs AI does.
Built by Heemang Parmar, Founder & CEO of ProductOS. 10+ years in product, 150+ builds. Also runs 1Labs AI, an AI product development agency.
Build it with ProductOS
Stop reading about it. Ship it.
Describe your idea once. AI agents research it, spec it, design it, and build real code you own, sharing one context the whole way.
Free to start · no credit card required
Head of Content, ProductOS
Content strategist for founding teams. Writes about AI search: answer engine optimization, topic clusters that compound authority, and honest comparisons of AI app builders.