Foursquare Had the Answer in Its Data All Along

On misreading signals, botched corrections, and the question you never thought to ask

In 2014, Dennis Crowley made a decision that would define the next decade of Foursquare’s existence.

He split the product in two.

Foursquare, the app that had built its identity around check-ins, badges, and mayorships, would become a recommendation engine. A Yelp competitor. The check-in feature where the product’s founding mechanic, the thing that had driven 7 billion data points into Foursquare’s servers would be moved to a new app called Swarm.

Crowley framed it as evolution. The company had grown beyond the check-in. The data they’d accumulated pointed toward something more valuable: a location intelligence layer that could tell you where to go before you even thought to ask.

He was right about the destination. He was five years too late getting there. And the way he arrived broke the very thing he needed to make it work.

This is not a story about a pivot. It is a story about what happens when the right answer is sitting in your data for years and you keep asking your data the wrong question.

The Check-in Was Never the Point

Foursquare launched in 2009 with a mechanic that was genuinely addictive. You checked in. You earned badges. You competed for mayorships. It spread through early adopter circles fast, hit mainstream attention faster, and within a few years had accumulated over 50 million users and 10 billion check-ins.

But the check-in was always a collection mechanism, not a destination. Every time a user checked in, Foursquare learned something: where people go, how often, at what times, in what sequence, in what context. The database that was accumulating underneath the gamification layer was, quietly, one of the most valuable location datasets ever built.

Crowley knew this. He talked about it openly. The Pilgrim engine, Foursquare’s location-guessing technology had become sophisticated enough to infer where you were without a check-in at all, using passive signals from your phone. They had built the capability to make their core mechanic unnecessary before they acknowledged that the core mechanic was the wrong product.

The right product was always recommendations. Always location intelligence. Always the answer to: where should I go, based on everything you know about where I and people like me have been before?

That product was sitting inside Foursquare the entire time. It just wasn’t what Foursquare believed it was building.

The Signal They Didn’t Read

When Crowley announced the Swarm split in 2014, he revealed a number that should have surfaced years earlier.

Only 5% of all Foursquare user sessions had both social and discovery activity in them. The other 95% were doing one or the other. Users who opened the app to find a restaurant were not the same users who opened it to check in and see where their friends were. The product was serving two fundamentally different jobs, and almost nobody was asking it to do both at once.

This was not new information when the split was announced. It was sitting in the usage data the entire time. The question is why it took until 2014 to act on it.

The answer is not that Foursquare lacked data. They had more data than almost any consumer app of that era.

The truth is that data never lies but it only reveals to those who wish to see.

And for years, Foursquare’s team was not asking their data what problem they were actually solving. They were asking it how to solve the problem they had already committed to.

The 5% stat, read through the lens of “we are a check-in product,” looked like a design problem. Social and discovery weren’t integrating. Users weren’t doing both. The solution: better design, better prompts, better integration between the two surfaces. The product team spent years trying to make the check-in and the recommendation coexist more elegantly inside a single app.

Read through a different lens what job are users actually hiring this product for the same stat looks like a diagnosis. Users had already separated the two use cases in their own behaviour. The product just hadn’t caught up.

Same data. Completely different answer. Depending entirely on which question you asked of it.

The Math Problem Foursquare Couldn’t Solve

Building a product is like solving a math problem in two parts.

Part one: identify and clearly write down the problem that needs to be solved. Part two: solve it.

Most teams are reasonably good at part two. Execution, iteration, design, engineering these are skills that can be developed, measured, and improved. Part one is harder, because it requires something execution skills don’t: the willingness to question the premise you’ve been operating under.

Foursquare was late on part one by at least three years. The correct problem build the world’s best location intelligence and recommendation layer was knowable from the data well before 2014. The 5% stat was one signal. The growth of Yelp was another. The behaviour of power users, who had largely stopped using the social features and were using Foursquare purely as a discovery tool, was another.

None of these signals were hidden. They were being interpreted through a locked problem statement: we are a check-in product. That framing filtered everything. Data that should have prompted a question instead prompted an optimisation.

When the correct problem was finally named, Foursquare moved to part two and botched it.

The split into Foursquare and Swarm was logically coherent: separate the two use cases that users had already separated in their behaviour. But the execution fractured the network effect that made both products worth using. The community activity the check-ins, the tips, the edits from superusers had been generating the data that powered the recommendation engine. Splitting the apps meant splitting the community. And a recommendation engine without active data generation is just a static database slowly going stale.

Crowley later admitted the split wasn’t communicated well enough. That is an understatement. What wasn’t communicated was that the two products were not actually separable each depended on the other in ways the team either didn’t fully see or didn’t fully reckon with before pulling the trigger.

The Decade of Compounding Cost

The split happened in 2014. What followed was ten years of consequences.

Foursquare spent years trying to become a Yelp competitor, fighting for a market position against an entrenched incumbent with a loyal user base. Swarm drifted, lost users, added features, removed features, and never found stable footing as a standalone product. The location intelligence business Foursquare’s actual most valuable asset grew into a legitimate enterprise data business, powering location insights for companies like Apple, Microsoft, and Twitter. But consumer Foursquare never recovered.

In 2024, the company announced it was sunsetting the Foursquare City Guide app entirely, returning focus to Swarm. Ten years after the split, the reversal was essentially complete. Crowley wrote that he was “in a real funk” about it.

The cost of a delayed part one compounds. In 2011, naming the correct problem would have been a strategic decision uncomfortable, identity-challenging, but executable. In 2014 it was a crisis response, executed under pressure, communicated poorly. By 2024 it was a decade of declining consumer relevance and a founder writing about being in a funk.

Course correction is always an option. It is never free. And the price scales with how long the wrong problem went unexamined.

The Principle Worth Carrying Forward

The Foursquare story is not a lesson about pivoting. It is a lesson about the relationship between your problem statement and your data.

Data does not arrive with interpretations attached. It arrives as numbers, ratios, behavioural patterns neutral until someone asks a question of it. The question determines what the data reveals. A team that has locked in a problem statement will ask questions that confirm the problem statement. Not because they are incurious or incompetent, but because the problem statement is the lens through which every metric gets read.

The discipline that Foursquare lacked and that most product teams lack is the habit of periodically setting down the current problem statement and asking the data a different question. Not how are we performing against our current objective but what job are users actually hiring this product for, and is that the job we set out to solve?

These are not the same question. The first optimises. The second diagnoses.

Foursquare optimised for years on a problem it had already outgrown. The data that could have told them so was sitting in their servers, waiting for someone to ask it something different.

What question are you currently asking of your data and what might it reveal if you asked it something else?