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.

More in Features

Features

Platform timelines: steps, examples and decisions

Platform timelines collapse four different dates into one, and this sets out how to build an entry that survives review and what a timeline cannot show.

Industry

Platform timelines examples: lessons and useful context

Six platform timeline examples worked through: the staged rollout, the retroactive name, five acquisition dates, and two cases with no clean fix.

Guides

Platform timelines platforms explained with examples

The design levers behind platform timelines: forwarding, attribution, persistence, identity and ordering, and why virality is a claim about the network.

Industry

Platform timelines research: practical details and examples

Research method for platform timelines: sources ranked by what they establish, the in-place editing problem, and where the method genuinely runs out.

Latest from Reporting Desk

Reviews

How to make sense of memes and virality platforms

Memes and virality on platforms that bind them: four dependencies that stop a format traveling, and what actually crosses the boundary instead.