Features
Part of Platform timelines: steps, examples and decisions
Platform timelines timeline: what to know and why
A phase map for platform timelines: the stages services pass through, the transition that matters most, and how to use the map without overreading it.
This is a timeline with no dates on it. It plots the phases that networked services pass through, in the order they tend to pass through them, and it applies to almost every service that has ever grown large. The order is remarkably stable. The timing is not, and no two services take the same time over any phase, which is why a dated version would be wrong for all of them and this undated one is roughly right for most.
Read it as a map of where a service is, not when. A reader who can place a service on it can usually predict the next phase, and that is more useful than a date.
What to take away
- Services pass through founding, invitation, opening, growth, ranking, extraction and decline, in roughly that order.
- The transition that changes the most is the one from a feed you choose to a feed the service chooses. Everything after it is downstream of that decision.
- Each phase has a characteristic experience for users and a characteristic incentive for the operator, and the two diverge as the phases advance.
- The phases are a pattern, not a law. Some services stop at a phase and stay there, usually by staying small.
The phases
| Phase | What users experience | What the operator wants | What marks the transition out |
|---|---|---|---|
| Founding | A small group, mostly known to each other; norms set by example | To find out whether the thing works | The first users who were not invited by a founder |
| Invitation | Scarcity; being inside is itself a signal; the population grows by trusted introduction | Growth without losing the founding character | The invitation constraint is dropped, usually because growth is now the goal |
| Opening | A wave of newcomers; the founding norms strain; old members complain | Scale, as fast as possible | Volume outruns what the members can read |
| Growth | More content than anyone can see; the chronological feed becomes unusable | To keep people from leaving as the feed degrades | The service starts choosing what is shown |
| Ranking | A feed selected by the service; reach becomes unpredictable; attention concentrates | Engagement, because engagement is now the measure | Revenue becomes the priority over growth |
| Extraction | Advertising, paid placement, paid features; the experience is tuned for the operator's income | Income from a population that cannot easily leave | The population starts to leave anyway, or a new service enters its founding phase |
| Decline | Fewer new users; the population ages; the service optimizes harder for the ones who remain | To slow the exit | Closure, sale, or a long tail of persistence |
The transition that matters
The move from growth to ranking is the one that determines everything afterwards. Before it, the user chose what to see by choosing whom to follow, and the service delivered it. After it, the service chooses, on criteria it does not publish, and the user's choices are inputs to a system rather than instructions to it.
Every critique of the later phases, and most of the loss of what the benefits page describes, follows from this one change. It is made for an understandable reason, because a chronological feed at scale is unreadable, and it is almost never reversed, because a ranked feed is what the extraction phase depends on. A service that has made this transition is a different kind of thing from the one its early members joined, and they are right to say so, even when they cannot say why.
Why the phases are stable
The order holds because each phase creates the conditions for the next. Founding creates a character worth protecting, so invitation protects it. Invitation creates scarcity, which creates demand, which the operator eventually meets by opening. Opening creates volume, which breaks the chronological feed, which forces ranking. Ranking creates an attention system, which is what advertising buys, so extraction follows. Extraction degrades the experience, and decline follows when the degradation exceeds the cost of leaving.
The cost of leaving is the variable that sets the timing. The network effect is the conventional name for the fact that a service is worth more to each user the more users it has; the same fact means that leaving costs more the larger the service is, and the standing described under online status and identity does not transfer. A service with a strong lock-in can sit in extraction for a very long time. One with weak lock-in passes through it quickly.
Where services stop
Not every service runs the whole sequence. Some stop at invitation and stay small on purpose; most of the long-lived communities described under internet communities are of this kind, and they avoid the later phases by refusing the growth that triggers them. Some stop at growth without ranking, usually because they are not funded in a way that requires extraction, and remain usable to a population that has learned to cope with volume. Some are closed before reaching decline, by an owner with other priorities.
The general technology life cycle describes a similar arc for products in general; the version here is specific to services whose product is other people, which is why the phases are about population and not about features.
Using the map
- Place the service by its feed, not by its age. A service that shows you what you chose is before the transition; one that shows you what it chose is after.
- Expect the next phase, not the current one. The behavior of a service in ranking predicts extraction, and the behavior in extraction predicts decline, more reliably than any announcement.
- Discount the operator's account of which phase it is in. Operators describe growth as founding and extraction as growth, for reasons that are not dishonest but are not neutral.
- Do not attach dates. The timing varies too much between services for a dated version to mean anything, and a dated entry would import all the failures the platform timelines page describes.
Common questions
Can a service go backwards?
Rarely, and usually by splitting: a group leaves an extraction-phase service to found a new one, which starts at founding. The original does not go back; a piece of its population does.
Does every service reach decline?
Every service that reaches extraction has so far. The ones that avoid decline are the ones that stopped earlier, which they did by staying small or by being funded in a way that did not require extraction.
Why no dates at all?
Because the phases take wildly different times on different services, and a date would be true for one and false for all the rest. The order is the information; the timing is noise.


