Cohort Communication That Actually Gets Read
Why the weekly all-cohort email stops working by week four, and what to send instead so founders do not miss the things that matter to them.
Week four is when it stops working
The pattern is consistent. A programme starts, a weekly cohort email goes out, and for three weeks everyone reads it.
By week four the email contains six items, of which two matter to any given founder. By week six people are skimming. By week eight somebody misses a funding deadline that was in the email, and the programme's response is to send a firmer email.
The problem is not attention. It is relevance. A channel where most content does not apply to the reader trains the reader to stop reading, and once that habit forms it applies to the important messages too.
Send less to everyone
Very little genuinely needs to reach an entire cohort:
- Deadlines that apply to all of them
- Building, access and safety changes
- Events they are all invited to
- Programme-wide policy changes
That is roughly it. Everything else has a smaller audience:
- Funding deadlines → companies with active commitments
- Lab closure → companies who book that lab
- Missing documents → the companies missing them
- Mentor availability → companies matched to that mentor
- Space renewal → companies whose term is ending
Targeting is not just politeness. It is what keeps the all-cohort channel meaningful, because if the whole-cohort message is rare, it gets read.
Separate the channels by consequence
Three kinds of message, and they should not share a pipe:
Things with a consequence. Deadlines, funding conditions, policy changes, anything you may later need to show was communicated. These need a record: who was sent it, when, and ideally whether they opened it.
Things that are useful. Events, mentor availability, opportunities, introductions. Nice to receive, no consequence if missed.
Conversation. Cohort chat, questions, informal help. Founders will use WhatsApp for this whatever you set up, and that is fine.
The failure is putting the first category into the third. A funding deadline posted in a WhatsApp group of thirty people is not a record of notification, and when a company misses it there is no useful answer to "nobody told me".
Track reads on the ones that matter
For the small number of announcements with a consequence, knowing who has opened it converts a broadcast into a process.
Without it: we told everyone. With it: nineteen of twenty-two have opened it; here are the three to call. The second is a five-minute task that prevents the missed deadline; the first is a position to defend afterwards.
This is not surveillance and founders do not experience it that way, because it is only applied to things with real consequences and it results in them being helped rather than blamed.
Write for one reader
The all-cohort email is usually written as an institutional bulletin. It reads like one, and it is skimmed like one.
Practical changes:
- One subject, one message, where possible. Two important things in one email means the second gets missed.
- Say who it is for in the first line. "If you have an active funding commitment, this affects you" lets everyone else stop reading, which is a service.
- Put the action and the date at the top. Not after three paragraphs of context.
- Say what happens if they do nothing. This is the line most often missing and the one that determines whether anyone acts.
Repeat deadlines on a schedule
Anything with a date should be communicated at least three times: when it is set, a week before, and the day before. Not because founders are careless - because they are running a company and your deadline is one of forty things.
Building that into the schedule at the start of the cohort means it happens without anyone remembering. Sending reminders reactively means they get sent when someone notices, which is usually after the first person has already missed it.
Make the record findable afterwards
The question that arrives later is "was this communicated, and when". It is asked by a funder, by a governing body, and occasionally by a founder disputing a decision.
That question is answerable if announcements are stored against the programme with their date and recipients, and unanswerable if they went out from one person's mailbox. This is the practical argument for announcements living in the same system as the cohort rather than in email: not efficiency, but the fact that email leaves with the person who sent it.
A workable rhythm
- Weekly, short, targeted: what is due this week, for whom
- On demand, targeted: things affecting a subset
- Rare, all-cohort: genuinely universal announcements, with read tracking if there is a consequence
- Always available: an archive founders can search when they remember something was mentioned
The measure of success is not open rate. It is whether the number of people who miss a deadline they were told about goes to nearly zero.
Frequently asked questions
- Why do founders stop reading cohort emails?
- Because most of the content does not apply to them. A weekly all-cohort digest where four of six items are irrelevant trains people to skim, and once skimming starts the important item goes unread too.
- What should go to the whole cohort?
- Deadlines that apply to everyone, building and access changes, and events. Almost everything else is better targeted - a funding deadline is only for the companies with commitments, a lab closure only for the ones using it.
- Should incubators use WhatsApp groups?
- For informal cohort chat, they work and founders prefer them. For anything you may need to prove was communicated - deadlines, funding conditions, policy changes - use a channel with a record. A message in a group of thirty is not a record of notification.
- How do you know whether an announcement was read?
- Only if the channel tells you. Read tracking on important announcements is the difference between 'we told everyone' and 'nineteen of twenty-two opened it, here are the three to follow up'.
