Slack's Pivot Teardown: How a Failed Game's Chat Tool Found Fit

Slack is the best-known pivot in software: a games company shut its game down and sold the chat tool its own team had built to get the game made. The part founders can borrow is less the pivot itself than what came after it. Tiny Speck spent about seven months putting the tool in front of friendly teams, each one bigger than the last, and only opened it to the public once real companies kept using it without being asked. This startup teardown separates what the public record shows from the tidy version that gets retold, and turns the method into a rollout plan you can run with your own early users.

The sources are a First Round Review interview with Stewart Butterfield, Slack's own history blog Building Slack, Butterfield's internal memo We Don't Sell Saddles Here, and contemporary coverage of the game's closure. Most of it is the founders telling their own story after a huge success, so treat the details as a well-documented single case, not a controlled experiment.

The failed game

Tiny Speck made Glitch), a browser-based multiplayer game. It launched in September 2011, went back into beta two months later to fix problems with how easy it was to get into and how much there was to do, and closed on 9 December 2012. The shutdown announcement said the game had not found an audience large enough to sustain it, and pointed to the decline of Flash and the shift to mobile.

That is a clean case of no fit. Glitch had players and fans, enough people liked it to make the closure news, but not enough of them for the business to work. Liking is not the bar. The bar is enough people who would be badly put out if the thing disappeared, the same question Superhuman measured with its survey.

The tool nobody was selling

While building Glitch, the team had built an internal communication tool for itself, which Britannica describes as developed for the people working on the game. After the shutdown, a small core team stayed on to turn that tool into a product.

Here hindsight does the most damage. Today it reads as obvious: of course the chat tool was the real business, the same way Instagram's photo feature now looks like the obvious heart of Burbn. At the time the team knew something narrower. One small team, with unusual habits and a lot of tolerance for their own software, could not work without it. That is a strong signal from a sample of one. It says nothing yet about whether a sales team or an agency would feel the same, or would put up with the rough edges.

Widening the circle one team at a time

What Tiny Speck did next is the most borrowable part of the story. In the First Round interview, Butterfield says they "begged and cajoled" friends at other companies to try the product and give feedback, maybe six to ten companies to start. Rdio, the music service, was one of them.

The detail that matters is that the test groups got bigger on purpose. At Rdio the tool spread from a small front-end group to the whole engineering team and then to all 120 people in the company, and Butterfield says the experience at that size was rough. A tool that feels great for eight engineers can fall apart when a whole company is in it: too many channels, too much noise, no way to find anything. You only find that out by letting a bigger team in.

The Building Slack post on this period describes the loop. Teams that adopted the tool found bugs that were fixed and gaps that were filled, and sent anonymised usage data back. Testers at several companies kept using it and recommended it to others. That last part is the signal worth noticing: nobody had to be reminded to come back. The same post says the website, onboarding and docs were still a "ramshackle mix" of styles, so the team did a polish pass before letting strangers in.

The preview: demand measured as sign-ups

Slack opened a preview in August 2013, about seven months after work on it began. Butterfield told First Round they avoided calling it a beta because of what the word suggests about reliability. With a press push behind it, about 8,000 people asked for an invitation on the first day and 15,000 within two weeks, according to the same interview and Slack's own blog. Some later write-ups say 8,000 companies; the founder's own telling says people, so use that.

Those numbers are interest, not fit. A sign-up costs nothing, as Dropbox found when its demo video filled a waiting list overnight.

What made them useful was the step behind them: invitations went out in batches, so the team could keep watching whether newly let-in teams kept using the product the way the friendly ones had, and fix the next problem before inviting more. The public launch followed in February 2014.

The memo: what was actually being sold

Two weeks before the preview, Butterfield sent the team the memo later published as We Don't Sell Saddles Here. Its argument is about positioning. Few buyers were shopping for "team chat"; the value was the change in how a team works once its conversations are in one searchable place. The title's metaphor is that you sell the riding, not the saddle.

The memo also has the line that explains why the friendly-team phase mattered so much: "When you want something really bad, you will put up with a lot of flaws. But if you do not yet know you want something, your tolerance will be much lower." Tiny Speck's own team wanted the tool badly and forgave everything. Strangers would not. So the product had to be good enough for people who did not yet know they needed it, and the only way to know when it was ready was to watch teams that had no reason to be patient.

What they knew then versus what we know now

	What the team knew in 2013	What we know now
Demand	Its own team depended on the tool; six to ten friendly companies kept using it	Teams with no tie to the founders adopted it and stayed
Risk	The tool broke down at larger team sizes	Large-team use became the core of the business
Signal	Unprompted daily use and recommendations inside test companies	Retention and word of mouth carried growth
Unknown	Whether strangers would put up with the rough edges	They did once the polish pass was done, which only the preview could show

The retold version skips the uncertainty in the last row. The friendly companies were friends. They were more patient, more likely to give the product a fair trial and more likely to keep using it out of goodwill. The preview's job was to test exactly that bias, and the team treated it that way: a gated, batched release, not a launch.

It is also worth being clear about what this case cannot tell you. Butterfield had already co-founded and sold Flickr, had investors willing to back the change of direction, and could reach the press. Most founders cannot get 8,000 sign-ups in a day. The method underneath, widening the circle and watching unprompted use at each ring, does not depend on any of that.

What to borrow this week

1. Write down your own ring zero: who uses your product today because they have to or because they know you. Do not count them as evidence of fit.
2. Recruit three to five teams or users who match your target customer but owe you nothing. Give each one a fixed start date.
3. Pick one unprompted-use signal and a threshold before you start. For a team tool, that could be "at least half the team active on four of five weekdays in week three". For a single-user tool, "used in week three without a reminder email".
4. After three weeks, check each team against the threshold. Only widen the circle (more teams, or bigger ones) when at least most of the current ring passes.
5. When you widen, raise one dimension at a time, team size or distance from you, so you know which one caused what breaks.

If nobody in the second ring keeps using the product, that is the cheapest bad news you will get. Go back to customer discovery interviews before you build the next feature, and read the shape of your retention curve for the users who did stay.