when adoption isn't the problem

every post in this series has been about tools that fail on adoption.

hubspot — a dense crm platform that lands on a team that's the wrong shape for it. nobody tested fit, nobody asked the users, nobody owned the first ten minutes. adoption dies before the first login.

attio vs hubspot — same domain, different weight class, and the discovery that the teams who adopt either one successfully did the same three things: transparency, a plan, and user input before the contract.

linear — a lightweight issue tracker that proves the thesis holds across domains. different tool, different team, same failure when the rollout is missing.

this post is about the exception. notion actually gets adopted.

notion is one of the rare tools in the saas landscape that doesn't have an adoption problem. people use it. teams build in it. docs get created, databases get spun up, wikis get linked, dashboards get pinned. the tool lands. if the only metric is "did the team log in," notion passes every time.

the failure comes later.

open any company's notion after year two.

every team built their own version. engineering has a wiki that makes sense to engineering — nested five levels deep, organized by project, with a naming convention only the team lead understands. marketing has a content calendar that makes sense to marketing — flat, tag-heavy, organized by quarter. the company handbook lives in three places. the onboarding doc exists, and so does the slack message asking "where's the onboarding doc" — posted every time someone new starts.

the search bar does more work than the sidebar, because the sidebar can't be trusted. people don't browse anymore. they only find things they already knew to look for. a company where everyone knows the docs they wrote and nobody knows the docs anyone else wrote.

this is what adoption without utility looks like.

the failure isn't the product. notion is doing exactly what it was designed to do — be infinitely flexible, let every team shape the tool to fit their work.

the failure is that nobody was transparent with the org about how that flexibility would be used across teams. nobody had a plan for shared structure. naming conventions. where things live. what gets archived. who owns what. how the sidebar is supposed to work at the company level, not just the team level.

the tool is infinitely flexible. the org gave zero guidance about how to use that flexibility together.

some people on the team aren't technical enough to build a database from scratch. some are overwhelmed by the blank page — "what am i supposed to put here?" is a real question that notion's empty state doesn't answer. some built something that works perfectly for them and has no meaning to anyone else on the team.

nobody asked these people what structure they needed. nobody onboarded them to a shared model. the tool was rolled out as "here's notion, go build" — and everyone did. in every direction.

this is the same thesis as every other post in this series, wearing different clothes.

the crm posts were about loud failures — the team never logs in, adoption is flat, leadership blames the tool. notion is about the quiet failure — everyone logs in, adoption looks great, and nobody can find anything.

both are rollout failures. no transparency about how the tool would be used. no plan for how the team would absorb it. no voice for the people doing the work.

the tool was never the variable. not when it's dense. not when it's light. not when it's a crm. not when it's an issue tracker. not when it's a knowledge base.

the fix for notion looks like the fix for every other tool in this series, adjusted for the shape of the failure.

zero: before rolling out notion org-wide, define the shared model. what lives in notion and what doesn't. how teams name things. what the sidebar structure looks like at the company level. this isn't about killing flexibility — it's about giving flexibility a container.

one: name an owner for the workspace the way you'd name a pm for a product. someone who can make decisions about structure, enforce naming conventions, and say no to the fifth copy of the onboarding doc. without this person, the workspace is a garden with no gardener.

two: onboard new hires to the structure, not just the tool. "here's how our company uses notion" is more important than "here's how notion works." the new hire doesn't need to learn databases and templates on day one. they need to know where the handbook lives, where their team's docs are, and how to find something they didn't create.

three: audit quarterly. archive what's dead. surface what's buried. ask the team what they can't find. the workspace degrades the same way any product degrades without maintenance — slowly, then all at once.

four posts. four tools. a dense crm. a lightweight crm. an issue tracker. a knowledge base.

every failure had different symptoms. every failure had the same cause.

no transparency. no plan. no voice for the people using the tool. the rollout was never held like a launch.

saas is supposed to make the job easier. a tool that everyone uses but nobody trusts for the source of truth is making the job harder — it's just harder to notice.

where does your team draw that line?

— clarai.io