How to Prepare a Discord Community for a Product Launch: Answer the Questions Before Launch Day
A one page launch brief, a test for what is new, and a question forecast that gets approved answers to your community team before the announcement goes out.
How to prepare a Discord community for a product launch: list what is new compared with the last launch, predict the questions each new thing will raise, and get approved answers to the community team before the announcement goes out. Where no answer exists yet, prepare an honest holding reply with a date on it.
What to hand your community team before the announcement
Before an announcement goes out, the product side hands the community team two things. The first is a one page launch brief. The second is a list of the questions members are likely to ask, with an approved answer beside each one. I refer to that list as a question forecast. It is a written prediction of what members will ask in the first hours after an announcement, made while there is still time to get the answers approved.
The forecast is built with one test. Anything in the launch that members have not seen before gets its own set of predicted questions. That covers a new plan, a new feature, a new product format, a new price point, a changed option or a moved date. These are the parts that produce the most questions. They are also the parts the community team is least ready for, because nobody on that team has answered those questions before.
If you run product or product marketing, this is your document to start. You own the launch calendar and you know what is different this time. The community team knows how members phrase things and where in the server they will ask. The forecast joins those two kinds of knowledge, and most of the work happens in the week before a launch.
I will walk through one launch day twice, first without the forecast and then with it. The template follows.
Launch day without the forecast
The announcement goes out in the announcements channel at the planned time. The community team reads it there, at the same moment as every member. Nobody sent it to them earlier. Product planned the launch, community runs the server, and no step in the launch plan connects the two. This launch has something new in it. Say it is a new plan that sits above the existing one, at a higher price. Within minutes the questions arrive under the announcement and in the general channel:
"Does this replace the plan I am on?" "Why is it priced higher than the current one?" "Is the new feature in my plan or only in this one?" "When does it reach my region?"
The moderator on shift knows what the announcement says and nothing beyond it. They post in a staff channel asking product. This is the busiest day product has, so the reply takes a while. During that wait a second moderator tries to help and answers the pricing question from memory of an earlier launch. The answer is close, and wrong on one detail. Members now have one question with two answers and others still pending, and a few of them start answering each other with guesses. When the correct answer arrives, it has to be posted as a correction. Corrections travel slower than first answers. Some members saw the first version and have already left the channel. Two things about this day deserve attention from the product side. The people asking are your most interested members. They read the announcement and cared enough to ask about it. A slow or contradictory reply reaches them at the point where they are deciding what to do. Your launch messaging gets rewritten live. Weeks of work went into how this launch is described. In the server it is being paraphrased by people who were never given the description. The moderators did what they could with what they had, and what they had was the announcement. Routine launches survive this arrangement, because the team has answered the same questions before and can repeat itself. The arrangement fails on the launches with something new in them, and those are usually the launches you care most about.
The same day with the forecast
Run the same launch again. A week earlier, product sent a one page brief. The community lead read the line about the new plan and wrote down the questions members would ask about it. Product filled in the answers and approved the wording. Two questions had no answer yet, the regional date among them, and each of those got a prepared reply and a date. The announcement goes out. The first question is whether the new plan replaces the current one. The moderator opens the pinned post in the staff channel, copies the approved answer and posts it. A moderator on a later shift gets the same question and gives the same answer in the same words. Then the regional question arrives. There is still no final date, and the moderator says so:
"We do not have a confirmed date for that region yet. The product team will confirm by Thursday, and we will post it in the announcements channel when they do."
The member still has no date. They do know when one is coming and where it will appear, and that is enough for most people to stop asking. A few questions come in that nobody predicted. They go into a short log, product answers them that afternoon, and they are added to the template so the next launch starts with them already on the list.
| Moment | Without the forecast | With the forecast |
|---|---|---|
| The team learns what is launching | When the announcement is posted | About a week ahead, from the brief |
| The first question about the new plan | The moderator asks product and waits | The moderator posts the approved answer |
| Two staff get the same question | Two different answers | One answer, in the same words |
| A question with no answer yet | A guess, or silence | A prepared reply with a date |
| A date moves late | The team posts the old date | The brief is updated the same day |
| The day after | Nothing is written down | Missed questions join the template |
The launch brief, on one page
The brief is written by whoever owns the launch calendar. It has five parts and it stays on one page, because a longer document does not get read by a moderator between shifts.
LAUNCH BRIEF
Launch: [name]
Announcement goes out: [date, time, time zone]
Brief version: [number] Last updated: [date]
1. What is launching and when
2. What is new or different from the last launch
3. What is not included that members will expect
4. Price and availability
5. What changed since the last version of this brief
Part 1 is the plain description. Write it the way you would explain the launch to a colleague in another department, without launch copy. Part 2 is the part the forecast is built from. List every item that differs from the last launch, one line each. Be literal. "First time we have offered an annual plan" is a useful line. "Exciting new options" is no use to anyone. Part 3 gets skipped more than any other, and it earns its place. Members ask about what is missing as often as they ask about what is there. If a feature is only on the higher plan, if an older option is not coming back, or if a region is not included at launch, write it down here so the team is ready for the question. Part 4 covers the exact price, what the price includes, where the product can be bought or switched on, and who can get it on day one. Part 5 is a short change log. Dates move, and a brief that was correct last Tuesday can be wrong today. When something changes, add one dated line here and send the brief again. The community team reads that one line and does not have to compare two versions of the page. I ask for the first version of the brief about a week before the announcement. That leaves enough time to write the questions, get answers approved and chase the ones nobody can answer yet.
The "new thing" test
Take part 2 of the brief and go down it one line at a time. For every first-time format, tier, option, size or price, write a separate set of predicted questions. These six cover most of what members ask about something they have not seen before:
| What members ask | What the answer has to contain |
|---|---|
| What is it? | One plain sentence, with no launch copy |
| How is it different from what you already have? | A comparison with the closest existing thing |
| What does it cost? | The exact price and what it includes |
| Why that price? | The reason, above all when it is higher than the last one |
| Who is it for? | Who should get it, and who is fine without it |
| When and where can I get it? | Date, time zone, place, and any plan or region limits |
Changes get the same treatment as additions. A changed option, a removed feature or a moved date raises its own pair of questions: why did this change, and what happens to me if I was using the old version. Anything that is the same as last time needs no new work. Reuse the answers from the last launch. This is what keeps the forecast small. A launch with one new item produces one set of questions, and a launch with three new items produces three sets. Split the work by who knows what. Product drafts the first questions, because product knows what is new. The community team then rewrites them in the words members use and adds the ones product did not think of. Product writes the answers and approves the final wording.
Every question gets a status
Each question in the forecast carries one of two statuses: Answered or Not yet known.
Answered means there is approved wording a moderator can paste.
Not yet known means three things have been written down: an honest holding reply, the date the real answer is due, and the name of the person getting it. The holding reply is prepared in advance like any other answer.
QUESTION FORECAST
New item: annual plan (first time offered)
Q: What is the annual plan?
Status: Answered
Approved answer: [two plain sentences]
Q: Can I switch from monthly part way through a month?
Status: Not yet known
Holding reply: "We are confirming how switching works. The product team will post the answer by [date]."
Owner: [name] Answer due: [date]
A moderator with no answer does one of two things: guesses, or goes quiet. Both are worse than a prepared "not yet". The date in the holding reply is a promise made to members in public, so one named person has to own it.
A weekly sync and a same-day rule
Hold a weekly sync between whoever owns the launch calendar and whoever runs the community. Keep it short and keep the agenda fixed:
- What launches in the next few weeks
- What is new in each one
- Which briefs are due, and which answers are still open
- What changed since last week Between syncs, one rule applies. Any last-minute change is sent the day it happens. A moved date, a changed price or a dropped option goes into part 5 of the brief and into the same staff channel every time. Without that rule the community team will post the old date with full confidence, and they will be right to, because it is the last thing they were told.
Where the answers live on launch day
The approved answers live in one place that every staff member on shift can reach. A pinned post in the staff channel works. So do saved replies in whatever support tool the team already uses. The tool matters less than the rule that everyone answers from the same text. Keep each answer short enough to paste into a reply. When an answer changes, edit it in that one place and say so in the staff channel. Once the launch is live, the answers members ask for most can also go in a public post under the announcement, so people find them without having to ask.
- The brief is on its latest version and part 5 is current
- Every predicted question shows Answered or Not yet known
- Every Not yet known has a holding reply, an owner and a date
- The approved answers are pinned where every moderator on shift can reach them
- One named person on the product side is reachable for the first hours
- Someone is logging the questions nobody predicted
After the launch: the questions nobody predicted
Within a couple of days of the launch, read the log of questions that were not in the forecast. Sort each one into one of two groups. If it was about something new, add it to your standing list of questions for new items. The six questions above are a starting set, and your own list will grow to fit your product. If it was about something the brief left out, add a prompt to the brief template so the next author is asked for it. Leave alone the predicted questions that nobody asked. Having an answer ready that was never needed costs very little. After several launches the template stops being generic and starts to describe your members.
Where this sits in the wider system
The question forecast is one part of response time and support routing, meaning how fast a member gets a correct answer and who that answer comes from. That work sits alongside documentation, onboarding, engagement rhythm and reporting. The forecast covers launch days and nothing else. A server where replies are slow on an ordinary Tuesday has a routing gap that a launch brief will not close, and the same goes for a server with no place to keep answers between launches. The questions members ask on launch day are predictable a week earlier by anyone who knows what is new. Writing them down is a small job, and it lets the team answer from a page on the day. More at danieljeong.org.