Laws of PM Growth Zipf's Law

Zipf's Law

Power Laws in Product Usage

Product usage follows a heavy-tailed pattern — a few items get most of the attention, and the rest trail off. The head and the tail are different problems with different UIs.

Why PMs should care

In almost any product where users can interact with many items — stocks, songs, creators, SKUs, docs, templates, emoji, anything — a small number of items get most of the attention, and the rest trail off in a long tail. The second-ranked item gets about half the traffic of the first; the tenth gets about a tenth.

Product decisions should treat the head and the tail as different problems, because they are. The head is a ranking and discovery problem where speed and clarity matter most. The tail is a search and findability problem where breadth and relevance matter most.

The classic mistake: design one browse UI that tries to serve both. It ends up serving neither. Head users don't need to browse. Tail users can't find what they're looking for. Splitting the two into different surfaces is the Zipf-aware design.

Example in product work

On a trading app, the top 20 tickers (AAPL, TSLA, NVDA, MSFT, and the rest of the usual suspects) account for 80% of retail volume. The next 200 tickers account for 17%. The remaining 9,000+ account for the final 3%.

The product implication: the home screen and watchlist UI should be ruthlessly optimised for the head — one-tap buy, clean price cards, big charts, no clutter. The discovery UI for the tail should look completely different — search-first with autocomplete, fuzzy matching on company names ('tesla' → TSLA), ticker aliases, sector filters.

Trying to build one 'stock browser' that does both produces a UI where neither user type is happy. Splitting it into Watchlist (head) and Search (tail) as distinct surfaces is the Zipf-aware design.

What to do when you see it

Sources & further reading

Back to all 59 laws