Industry
Part of Benefits of social media, in six rules: how to test any claim
Why a platform's structure decides which social benefits you actually get
Social media platforms deliver benefits only through structure: each benefit mapped to the network property it needs and to what quietly breaks it.
A benefit is not a property of a service. It is a property of a network shape, and a service either has the shape or it does not. That is why the same claimed advantage is real in one place and absurd in another, and why moving a group somewhere new sometimes loses the exact thing everyone valued.
This page maps each benefit onto the structural property it requires, and names what breaks it. The properties are older than the services built on them: Usenet newsgroups and mailing lists had a topical index and no ranking, web forums had a shared write surface, and subreddits, Facebook Groups and Discord servers each rebuilt one of those properties in a different order.
What to take away
- Every benefit rests on a structural propertya wide graph, a topical index, a shared write surface, an export path, or a low reply barrier.
- A service that lacks the property cannot deliver the benefit, no matter how many people are on it.
- Ranking systems help discovery and hurt reliability, and that trade is the source of most disagreement about whether a service is any good.
- The right question before moving a group is which property they were actually using.
Benefits and the properties they need
| Benefit | Property required | What breaks it |
|---|---|---|
| Meeting people outside your existing circle | A wide graph with visible second-degree connections | A feed that shows you mainly people you already know |
| Finding others with a rare need | A topical index that people can search and join | Organization by person rather than by subject |
| Coordinating something without an institution | A shared write surface with a stable address | Chronological feeds, where a plan scrolls away |
| Keeping a record of what you did | An export path and durable addresses | Ephemerality, and formats you cannot take out |
| Reaching someone who would not take your call | A low reply barrier and public conversation | Closed messaging, and filters that hide strangers |
| Publishing without asking permission | Distribution not gated by an editor | A ranking system that functions as an editor |
The first row is most often claimed and least often delivered. A wide graph pays off through connections you do not already have — the weak ties Mark Granovetter set out in 'The Strength of Weak Ties' — because weak ties reach people outside your immediate circle, while the people closest to you mostly know what you know already. On live services those second-degree connections surface as suggested friends, follower-of-follower recommendations and contact imports, each of which widens the graph without widening your circle.
Benefits vs required properties
Benefit
- Meet outside circle
- Wide graph, visible 2nd-degree
- Find rare need
- Searchable topical index
- Coordinate without institution
- Shared write surface, stable address
- Keep a record
- Export path, durable addresses
- Reach a stranger
- Low reply barrier, public
- Publish without permission
- Ungated distribution
Property required
- Meet outside circle
- Feed of known people
- Find rare need
- Organized by person
- Coordinate without institution
- Chronological feeds
- Keep a record
- Ephemerality, locked formats
- Reach a stranger
- Closed messaging, filters
- Publish without permission
- Ranking as editor
What breaks it
- Meet outside circle
- Find rare need
- Coordinate without institution
- Keep a record
- Reach a stranger
- Publish without permission
A service that optimizes for showing close connections works directly against this and will feel comfortable while delivering less. The breaks are mechanical: an engagement-ranked feed decides you should not see the stranger, a chronological feed of only the accounts you follow never shows them, and closed messaging groups give them no public surface to appear on.
Why size is not one of the properties
Size helps only through the properties. A large service with a poor topical index is worse for finding people with a rare need than a small one organized by subject, because the rarity is in the matching and not in the population. Usenet newsgroups, mailing lists, web forums and subreddits were topical indexes first and social graphs second; a general feed is not an index, however many accounts it reaches.
Size matters when everyone you need is reachable in one place, which is the network effect argument and is real. That same argument makes leaving costly, so the property that delivers the benefit creates lock-in. Dunbar-type arguments about how many relationships a person can actually maintain point the other way: reach grows with size, attention does not.
Those are two descriptions of one fact, and any honest account says both. What leaving actually costs is set out under online status and identity.
Where the properties have shown up
A topical index is the oldest property on the list and the easiest to lose. Usenet newsgroups, mailing lists and web forums organized people by subject long before any of them had a social graph, and subreddits rebuilt the same index inside a large service. LiveJournal and Tumblr added a shared write surface on top of a graph, so a post could be read, shared and answered in public. Wikis went further and made the page itself the shared artifact.
The export path is the property users notice last. Google Takeout, Reddit's data export and the account archive X offers all exist because a container can close or change hands: the shutdown of Google Reader and a MySpace migration that lost user uploads both left people holding less than they thought they owned.
Coordination looks different again. A mailing list and a Discord channel both give a group a stable address, and neither asks a ranking system whether a message should be shown. That is the property a group is usually using when it says a move to a new service felt wrong.
The ranking trade
A ranking system decides what you see. It improves discovery, because it surfaces things you would never have found, and it degrades reliability, because you cannot tell what you did not see. Facebook's News Feed ranks what you see, X replaced a plain chronological timeline with a ranked one, and neither promises that you saw everything.
For a benefit that depends on discovery, ranking helps. For a benefit that depends on knowing you received something, such as coordinating a plan or maintaining a record, ranking is a hazard: a message that was not shown was not delivered, and neither party finds out. Groups that coordinate on ranked feeds lose things regularly and usually blame each other.
The practical rule is to match the surface to the job: discovery on a ranked feed, coordination on an address you can return to, records somewhere you control.
Mixing them is the most common structural mistake, invisible until something is missed. The wider argument about what these systems optimize for is set out under critiques of social media.
Choosing a place for a group
Ask which property the group is actually using. Most groups are using one, occasionally two, and could not name it.
Pick a place for the group
What is the group actually using?
Finding new people -> wide graph + index
Coordinating -> stable addresses, no ranking
- If the group is finding new people,it needs the wide graph and the index. Losing those loses the group's purpose, whatever else it gains.
- If the group is coordinating,it needs stable addresses and no ranking. It does not need reach at all, and reach usually costs it attention.
- If the group is keeping a record,it needs export and durability, and it should assume the container will close. What that assumption should look like in practice is set out under internet communities.
- If the group is publishing,it needs distribution that does not depend on approval, and it should count on that being harder than it looks.
A move that improves one property at the cost of another is a real trade and worth stating as one. Moves are usually presented as upgrades, which is how a group ends up somewhere that does everything except the thing it was there for.
Reading a claim about what a service is good for
Two questions handle most of them.
Which property does this claim require?
Does the service have it now?
That second point is why claims of this kind date badly and why dating them matters more than it seems. The general practice for writing a claim that can be checked later is set out under platform timelines.
Common questions
Can a service add a property later?
Yes, and they do. It is worth watching whether the property is genuinely added or only made available to some accounts, since a benefit available on request is a different thing from one available by default.
Is a smaller service always better for rare needs?
Not always. It needs the index, not the smallness. A small service organized by person is no better than a large one organized by person.
What about services that promise several of these at once?
Some properties conflict directly, chiefly ranking against reliability and reach against coordination. A service claiming all of them has either made a choice it is not describing or is delivering them to different users.
Does any of this tell me whether a service is good?
It tells you what it can do. Whether that matches what you want is your question, and the properties are the vocabulary for answering it rather than the answer.
