Google+ launched on 28 June 2011, presented by Vic Gundotra and Bradley Horowitz as Google's attempt to make sharing online resemble sharing in real life. Circles let you separate colleagues from family. Hangouts made group video calling casual rather than scheduled. Streams organised conversation by relationship rather than by chronology alone. It was a competent product with genuinely good ideas, launched by a company with unmatched distribution. It is now routinely listed among the largest failures in consumer technology, the consumer service was shut down in 2019 and its API was discontinued on 7 March 2019.[1][2] For anyone responsible for deploying internal tools, the interesting part is not that it failed. It is how it failed, because the mechanism is the one that kills enterprise rollouts.
The Business Version of the Problem
Google+ was not initially available to Google Apps customers, which was its own instructive detail — the company launched a collaboration-adjacent product that its business users could not access, then spent months retrofitting it.[3] When it did arrive for organizations, and later when Google pushed it into YouTube and Gmail, the strategy became explicit: if adoption will not happen voluntarily, require it. Users found themselves with profiles they had not requested, prompts they could not dismiss and integrations they had not chosen. Usage statistics improved. Actual use did not. People created the account because they had to, then continued doing what they had been doing. And the resentment generated by compulsory adoption attached itself to the product permanently, which meant the features that were genuinely good — Hangouts in particular — were dismissed along with everything else. This is exactly what happens inside companies when a platform is mandated. The metrics show accounts created and licences assigned. The reality is that work continues in email, in spreadsheets and in whatever tool the team already trusted, and the new system becomes an additional place to update rather than a replacement for anything.
Why Forced Adoption Produces Compliance Instead of Use
Three mechanisms, each visible in the Google+ story and in every failed internal rollout. Mandating access is not mandating value. You can require someone to have an account. You cannot require them to find it useful, and useful is the only thing that produces sustained behaviour change. A tool that saves its user time gets adopted with no mandate at all. Compulsion converts indifference into opposition. Someone who has not tried a tool is neutral. Someone who has been forced to create a profile has a position, and it is not a favourable one. The mandate spends goodwill that the product then has to earn back. Existing behaviour has enormous inertia and usually good reasons. People use email for internal coordination because it works, everyone has it, and the record is theirs. A replacement must be better enough to overcome switching cost, retraining and the awkward period when half the organization has moved and half has not. Most tools are not better by that margin, and mandating them does not close the gap. The corollary matters as much. When a tool genuinely is better, adoption does not need to be forced — and if you find yourself needing to force it, that is diagnostic information about the tool rather than about the users.
What Google+ Got Right, Which Nobody Remembers
It is worth being fair to the product, because the good parts contain a useful lesson. Circles addressed a real problem: the collapse of distinct social contexts into a single audience. Sharing something with colleagues that you would not share with family is entirely normal offline and was awkward on every platform of the period. Hangouts made multi-party video calling trivial at a time when the alternative was a scheduled conference bridge with dial-in codes. It was ahead of the market and it survived the product that carried it. The interface was cleaner than the incumbents'. The privacy model was more granular. And Circles' underlying insight — that audience segmentation should be the default rather than an advanced setting — was correct and has been reimplemented repeatedly since. None of it mattered, because the product needed a network it could not build, and the attempt to manufacture that network by compulsion destroyed the credibility it would have needed to grow organically.
Practical Guidance for Avoiding Forced-Adoption Failure
- Define what the new tool replaces, explicitly and by name. If nothing is being retired, you are adding a system rather than changing one, and the coordination burden increases for everyone.
- Run a real pilot with a team that wants it. Volunteers surface genuine friction and produce honest feedback. A pilot with a mandated group only tells you whether people comply.
- Measure behaviour that indicates value, not accounts created. Licences assigned, profiles completed and logins are compliance metrics. Documents authored, threads resolved, meetings not held — those indicate the tool is doing work.
- Make the first experience useful within one session. Adoption is decided in the first few minutes. If a user's initial encounter is configuration, training or an empty workspace, the default outcome is abandonment.
- Sequence the rollout around existing workflow, not org chart. Teams that work together should move together. Partial migration within a working group forces people to run both systems, which guarantees they keep the old one.
- Give people a way to say it is not working. A feedback channel that visibly changes something converts resistance into participation. One that is ignored confirms the suspicion that the decision was never open.
- Be willing to stop. The most expensive rollouts are the ones defended past the point of evidence because someone's credibility is attached. Set a decision point in advance with criteria.
- Retire the alternative deliberately once adoption is real. Not before. Removing the old tool while the new one is still unproven creates a gap that people fill with something worse and unmanaged.
The Current Repeat
This pattern is playing out again with AI tools, and faster. Organizations are buying assistants and copilots in bulk, assigning licences to everyone, and reporting adoption in terms of seats deployed. The pattern is identical to the Google+ error: distribution treated as adoption, access treated as value, and a metric that rises while behaviour does not change. The organizations getting real use are doing the unglamorous version instead. Find the specific tasks where the tool is clearly better, prove it with a team that volunteered, make that success visible, and let demand spread. It is slower at the start and it is the only approach with a record of working. Google had the best distribution in the world and could not force a product into people's working lives. A licence assignment is not a weaker version of that lever — it is the same lever, and it does not work either.
Common Questions
When did Google+ launch and why did it fail?
It launched on 28 June 2011 with strong features including Circles and Hangouts, but could not build a sustained network. Google's attempt to drive adoption by integrating it into other services produced compliance rather than use, and the consumer product was shut down in 2019.
What is the problem with mandating a collaboration tool?
Mandates create accounts, not usage. People comply with the requirement and continue working in the tools they already trust, which leaves the organization running both systems and paying for the coordination overhead of each.
How should a new internal tool be rolled out?
Name what it replaces, pilot with a team that wants it, measure behaviour rather than licences, ensure the first session delivers something useful, sequence by working group, and set a decision point where you are prepared to stop.
What does this have to do with AI tools?
The same error is being repeated. Bulk licence assignment is being reported as adoption, while actual usage concentrates in a small number of people who found a task the tool does well. Value follows demonstrated usefulness, not distribution.
Adoption Risk Briefing — Outpace tells you before you roll out whether a tool will be used or merely assigned, and what would have to change for the answer to be the first one.