Week-one programming for paid communities: the minimum viable calendar
The default week-one programming strategy for most paid communities is passive: send the Day 0 welcome DM, maybe send a Day 3 nudge to members who have not yet posted, and wait to see who activates. This approach treats week one as a filtering mechanism — the members who are engaged enough will find their own way in; the ones who do not will churn and at least they will have self-selected out before the operator invested too much time in them.
The filtering-mechanism framing is wrong, and the operators who hold it consistently see month-three retention rates ten to fifteen percentage points below the operators who treat week one as active programming territory. The key difference is not effort — the best week-one programming calendars are not more work than passive onboarding. The difference is intentionality: the operator who designs three specific moments for new-member action in week one, and executes them consistently, gives new members a structure to activate inside. The operator who runs passive onboarding is betting that new members will self-direct in an environment they have never been in before, using social norms they have to infer, on a timeline set by novelty — a bet that loses most of the time.
This post covers what week-one programming is and is not, why week one is structurally different from every other week in a member’s lifecycle, the minimum viable three-slot programming calendar that produces consistently high first-week post rates without requiring the operator to run events or live sessions, the wrong week-one programming patterns that look right but underperform, and how to measure whether week-one programming is actually working. The paid community metrics dashboard post covers the full five-metric measurement framework; this post focuses specifically on the week-one subset and why it deserves its own measurement layer.
1. Why week one is structurally different from every other week
Every new member who joins a paid community arrives with a novelty window — a period during which the community occupies a higher-than-usual position in their attention hierarchy. The novelty window is not loyalty or commitment. It is curiosity: the member paid for access and the act of paying has made the community temporarily salient in a way it will not be once the newness wears off. The novelty window for most members is five to seven days from the day they join. After that, the community competes for attention on equal terms with every other Slack workspace, newsletter, and tool in the member’s daily workflow.
This means the operator has five to seven days to do one thing: give the new member a moment to take action and form a peer connection before the novelty window closes. If the member takes action (posts something, replies to something, gets a reply from another member) in that window, they have an experiential reason to return. The community has become a place where they have participated, where they have been seen, and where another human acknowledged their presence. That is a substantially different relationship with the community than one in which the member opened Slack three times, scrolled the member list, read some old threads, and left without posting.
The member who scrolls and leaves in week one is not passively interested. They have already built the behavioural pattern for how they will interact with this community: observe, not participate. The paid community metrics reference shows that first-week post rate is the single highest-weight variable in predicting month-three retention — members who post in week one are three to four times more likely to still be subscribed at month three than members who never post. Week-one programming exists to close the gap between “member opened Slack and scrolled” and “member posted and received a reply.”
The other reason week one is structurally different is mental model formation. New members arrive without a working model of what kind of community this is, what the norms are, who the other members are, and what a good interaction looks like. They build that model from what they observe in week one. If they observe a community where the operator posts announcements and a small group of highly active members respond, they form a model of a broadcast community — one where the right behaviour is to read, not contribute. If they observe a community where many different members are posting replies to a weekly thread prompt and getting peer responses, they form a model of a participatory community where contribution is the norm. The programming that runs in week one determines which mental model new members form. After that model is formed, it is very hard to change.
2. The three types of week-one programming
Week-one programming falls into three types, each of which does a different thing and each of which has a different appropriate level of effort:
Onboarding automation. This is the sequence of direct messages sent to new members at fixed intervals from join date: Day 0 welcome DM, Day 3 conditional nudge (sent only to members who have not yet posted an introduction), Day 7 scorecard message (a brief summary of what the member has done so far and what their suggested next step is). Onboarding automation is the minimum viable week-one programming investment. It is automated, it is consistent, it does not require the operator to remember to do it, and it scales to any community size without additional operator time. Operators who skip or inconsistently run onboarding automation because it feels impersonal are trading consistency for a personalisation they cannot deliver at scale. The paid community onboarding checklist covers the exact message format, timing, and channel setup for each of the three DMs.
Structured async formats. These are recurring community posts that give all members — including new ones — a low-friction moment to contribute. The canonical example is the weekly thread prompt: a single question posted in the main channel on a consistent day each week, with the operator’s own reply as the first example response. Structured async formats are more effective than onboarding automation at producing peer connections, because they put new members in the same thread as established members and create a visible, low-stakes post occasion. The downside is that they require the operator to write a new prompt each week; they cannot be fully automated without losing the freshness that makes them work.
Optional live touchpoints. These are events, calls, or sessions that new members are invited to but not required to attend. They are the third type because they are the most demanding to run and the least effective at producing first-week activation for new members who have not yet formed a mental model of the community. A new member who attends a community event in week one without having posted or received a reply yet has an observer’s experience of the event: they watch established members interact, they may feel reluctant to speak, and they leave the event without a peer connection. The live touchpoint works well in week two or three, after a peer connection has already been formed through the async formats. Running it in week one, before the async foundation is working, produces attendance without activation.
3. The minimum viable week-one programming calendar
The minimum viable week-one programming calendar has three slots. These three slots are sufficient to produce first-week post rates of 45–60% in communities that implement them consistently. Adding more before these three are working reliably produces complexity without proportional benefit.
Slot 1: Day 0 DM — the entry action. Sent automatically when a new member joins. The Day 0 DM does two things: it gives the member a specific action to take in the next fifteen minutes (post an introduction using a structured format) and it collects one piece of information that will determine the member’s track for the Day 3 nudge (a goal-selection question: “What is the primary thing you want to get from this community?” followed by two or three options). The introduction format is the most important element. A generic “introduce yourself” prompt produces generic replies. A structured format — “Tell us: your name, what you work on, and one specific thing you want to get better at this month” — produces specificity that other members can respond to. The Day 0 DM should not list the community’s features, link to multiple resources, or describe the community’s history or values. All of that can come later. The only job of the Day 0 DM is to produce one post in the introductions channel within 24 hours of join.
Slot 2: Day 3 conditional nudge — the recovery intervention. Sent only to members who have not posted an introduction by day three. The Day 3 nudge is not a reminder about missed onboarding; it is a lower-friction restatement of the invitation. The tone is not “you haven’t done the intro yet,” it is “no rush — whenever you’re ready, even a one-liner works.” The nudge references the goal-selection the member made on Day 0 (“I see you’re interested in [goal-track topic] — there are a few members working on similar things”) and links directly to the most active channel for that goal track. This personalisation is what separates the Day 3 nudge from a generic reminder: it is the operator demonstrating that they read the member’s Day 0 response and have done one step of curation. The Day 3 Slack nudge guide covers the exact message format, the trigger logic for who receives it, and the two language patterns that produce the highest reply rates from members who have not yet posted.
Slot 3: weekly async thread prompt — the ongoing post occasion. A single question posted in the main channel on a consistent day each week. The prompt runs every week, not just during a member’s first week — but because new members have their novelty window open during their first week, the weekly prompt lands at the highest-attention moment in their membership cycle. If the weekly prompt runs on Monday and a new member joins on Tuesday, they will see and participate in the Monday prompt six days later, during their first week. If the prompt format is good and the operator’s example reply models the expected length and tone, a significant portion of new members will reply to their first weekly prompt without any additional nudge. The weekly prompt is the lowest-cost peer-connection mechanism available to a community operator because it puts new and established members in the same thread simultaneously — a new member who replies to the weekly prompt is, by definition, in a thread with established members who reply after them.
4. The wrong week-one programming patterns
Four patterns consistently underperform in week one despite looking reasonable from the outside:
Too many events. The operator who schedules a welcome webinar on day two, a community tour on day four, and a coffee chat on day six has filled the new member’s week with scheduling demands before the member has formed a mental model of whether attending any of these is worth their time. Event attendance in week one is lower than event attendance in week three for this reason: new members do not yet have enough context about the community to evaluate whether a specific event is useful. The operator who interprets low week-one event attendance as “members are not interested in events” is misdiagnosing a timing problem as a content problem. The intervention is not better events — it is moving the events to week two or three, after async activation has already occurred.
Mandatory participation. Programming that requires new members to attend, respond by a deadline, or complete an onboarding quiz before accessing channels produces friction that compounds with the other cognitive demands of being new. New members are already navigating a new workspace, a new set of social norms, and an initial self-presentation (the introduction). Adding mandatory steps to this load suppresses the first post rather than encouraging it. Optionality is not a nice-to-have in week-one programming — it is a conversion mechanism. A new member who skips the mandatory onboarding quiz because they are busy forms a more negative first impression than a member who skips an optional intro post and knows they can do it later.
Programming that requires full members to engage with new members. Some operators design week-one programming around existing member participation: “each new member gets a buddy from the existing membership,” or “long-tenured members are asked to reply to all new introductions.” These programmes create a dependency between the new member’s activation and the availability of an existing member to fulfil the engagement role. When the existing member is unavailable or forgets, the new member receives no response — exactly the failure mode the programme was designed to prevent, but now with additional disappointment because the operator explicitly promised a personal welcome. The safer design is programming that generates peer connections as an emergent byproduct of async formats (the weekly prompt thread) rather than as a designed obligation.
Programming that addresses week-two problems in week one. Some operators run week-one programming designed to solve month-two churn: goal-setting workshops, accountability partner matching, or structured projects with multi-week timelines. These formats ask the new member to make long-term commitments before they have confirmed that the community is worth committing to. A new member who joins a three-month accountability group in their first week and then churns at month one has both ended their subscription and abandoned their accountability partner — a worse outcome than if the long-term programming had waited until the member had formed a stable post habit. Week-one programming should produce one outcome: a new member who has posted at least once and received at least one peer reply. Everything else can wait for week two or three.
5. How to measure whether week-one programming is working
Two metrics determine whether week-one programming is working. The first is first-week post rate, which is the most direct measure of whether the programming created the low-friction moments for action that it was designed to create. A baseline reading before implementing week-one programming gives the operator a denominator: “without this programming, X% of new members post in week one.” After implementing the three-slot minimum viable calendar, the target is 45–60%. If first-week post rate does not move within the first four-week cohort after implementation, the problem is almost always in the Day 0 DM — specifically the introduction prompt format.
The second metric is peer-connection rate: the percentage of new members who receive at least one reply to their introduction from another member (not the operator) within 24 hours. Peer-connection rate measures whether the programming is producing community engagement rather than just operator-member exchanges. An introduction that receives only an operator reply is better than no reply; an introduction that receives replies from two other members who share the new member’s goal track is substantially more likely to produce a second post. To track it: at the end of each week, count the introductions posted by new members in the prior seven days. Count how many of those introductions received at least one non-operator reply within 24 hours of posting. Divide. A healthy peer-connection rate for a community running a weekly async thread prompt is 40–60%: less than half of new-member introductions receive a same-day peer reply even in active communities, but the peer-connection rate should be above 35% for the weekly programming to be generating the social layer that sustains month-two and month-three participation.
One signal that is easy to misread as success: the operator’s own replies to introductions. An operator who replies to every introduction within an hour has a 100% response rate and potentially a 0% peer-connection rate. The operator’s reply is better than silence, but it does not produce the peer-to-peer dynamic that week-one programming is trying to generate. The operator should reply to introductions — but should track peer-connection rate separately to confirm that other members are also engaging, and should treat a low peer-connection rate as a signal that the weekly thread prompt is not drawing enough established-member participation to create the secondary reply stream that new members need.
6. What to add in months 2–3 once the week-one baseline is working
The constraint on what to add after week-one programming is working is simple: add only one new format at a time, wait at least four weeks to measure its effect on the metrics above before adding another, and never add a format that requires existing members to decrease their participation in formats that are already producing peer connections.
The typical month-two additions are: a monthly goal-setting thread (structured format where members post one goal for the month and get acknowledgement from two peers), a bi-weekly topic-specific channel post (a second async thread in a goal-track channel for members who are past the introductions phase), and the first optional live session (a community-wide call where the operator shares a new development and opens the floor). These formats build on the first-week post habit rather than replacing it. They give members who have already posted in week one a reason to post again in month two, which is the window where engagement most commonly drops off after an initially strong week-one activation.
The paid community metrics dashboard covers what to watch in the 30-day contribution rate and monthly engagement rate as these month-two formats roll out — specifically, the high-30-day-contribution-rate, low-monthly-engagement-rate pattern that indicates month-two drop-off is beginning despite a strong week-one activation. The Foothold community health check surfaces the specific members who are at risk of the month-two engagement cliff in a weekly digest, so the operator can send the personalised outreach before the cliff turns into a cancellation.
Frequently asked questions
What programming should a paid community run in week one?
A paid community’s minimum viable week-one programming calendar has three slots: (1) the Day 0 onboarding DM — sent automatically when a new member joins, it contains a structured introduction prompt and a goal-selection question; (2) the Day 3 conditional nudge — sent only to members who have not yet posted, it offers a lower-friction version of the introduction prompt and links to the channel relevant to the member’s stated goal; and (3) the weekly async community thread prompt — a standing weekly post in the main channel that gives new members a low-stakes reason to reply alongside established members. These three slots are sufficient to produce first-week post rates of 45–60% in communities that implement them consistently. Adding events, workshops, or additional DM touches before these three are working reliably produces complexity without improving first-week post rate or peer-connection formation, which are the two outcomes week-one programming is designed to achieve.
How do you run week-one programming without overwhelming new members?
The single most effective constraint for avoiding overwhelm in week-one programming is the one-touch-per-day rule: no new member should receive more than one direct message, notification, or explicit invitation in any single day during their first week. Operators who violate this rule — sending a welcome DM on Day 0 and an event invitation on Day 1 and a community digest on Day 2 — produce a pattern where members start ignoring operator DMs entirely, which kills the effectiveness of the Day 3 nudge. The second constraint is optionality: every week-one programming touchpoint must be completable with a single action and must not require the new member to coordinate with anyone else. Live events in week one consistently underperform for new members because they require a scheduling commitment before the member has enough context to know whether the event is worth their time. The peer-connection proxy metric — tracking whether a new member receives a reply to their introduction within 24 hours from another member — is a more reliable indicator of week-one programming quality than event attendance.
What is the weekly community thread prompt format?
The weekly community thread prompt is a standing async post in the main channel on a consistent day each week. The format: one open question directly relevant to the community’s core topic, written so it can be answered in two to four sentences without requiring preparation or expertise that only senior members have. The operator posts their own reply immediately as the first response, modelling the expected length and depth. The thread stays unpinned — pinned posts signal permanence, while an unpinned thread signals an open conversation. The format that works best: “This week’s question: [specific challenge or decision relevant to the community’s topic] — what has worked for you?” Prompts that are too broad produce vague replies that don’t generate peer connections; prompts that are too narrow exclude members who don’t have an opinion on the specific topic. If no new members have replied within 48 hours, the operator tags one or two members whose goal-track matches the topic, converting the passive thread into a direct invitation that other new members can observe and join.
What does week-one programming failure look like?
Week-one programming failure has three diagnostic patterns. The first is a first-week post rate below 40%: fewer than four in ten new members make any post during their first seven days, meaning the programming is not creating the low-friction moments for action it was designed to provide. The second is zero peer connections formed in the first seven days: a peer connection is defined as a new member receiving a reply from another member (not the operator) within 24 hours of posting their introduction. Zero peer connections in week one is the strongest predictor of churn at month three — the new member has received no social signal that the community’s other members are interested in them. The third pattern is the lurker-from-day-one: a member who opens Slack daily but never posts. This member is consuming content without finding a moment to contribute, typically because the week-one programming is not offering a low enough entry point for first participation. The most common cause of all three patterns is a programming stack that is either too passive (no structured moments for action) or too demanding (events and multi-step activities before the member has formed any peer connections). The fix is almost always reducing week-one programming to the three-slot minimum viable calendar rather than adding more.