# Adoption Fails at the Doorway Not the Feature ## Claim A capability someone must remember to go somewhere to use loses to established habit regardless of its quality, so the decisive design variable is where a tool delivers its value, not how capable it is. <!-- atomicity: 1 idea ✓ --> ## Scope & conditions - Applies to tools competing against an already-full daily routine — a rep's CRM, inbox, calendar, and Slack in the source's framing, but generalizable to any professional's existing surfaces. - Every additional surface a tool asks someone to check is a recurring attention tax paid every day the tool stays in the stack, whether or not it's actually used — the cost is incurred even by an idle, unopened tool. - The diagnostic test is asking someone to narrate their working day's routine in order and treating that sequence as the map of where a capability must live — a five-minute, falsifiable check that beats feature comparison for predicting adoption. - Doesn't apply where the tool itself *is* the destination and the work genuinely happens there — IDEs, design tools, and BI dashboards succeed as places people go, which suggests the exception is tools where the work, not just a notification about the work, lives inside them. - A saturation limit isn't addressed by the source: if every vendor embeds into the same handful of existing surfaces (CRM, Slack), the attention tax reappears there instead of disappearing. ## Evidence > [!quote] ID:rw_cr_tax > Every additional surface a tool asks for isn't a small ask. It's a tax on attention that gets paid every single day the tool stays in the stack, whether anyone uses it or not. > [!quote] ID:rw_cr_routine > If your AI tool isn't on that list, it's not a productivity gain. It's homework. Common Room, a GTM-AI vendor, makes this argument about its own category — sales and marketing AI tools that fail because reps must remember to open a new destination. It's vendor content with an obvious interest in the conclusion, but the underlying mechanism (habit beats capability at the doorway) doesn't depend on Common Room's product and holds as a general adoption argument. ## Links - [[3. Resources/Permanent Notes/Developer-Tool Adoption Tracks Cognitive-Load Reduction Not Feature Count]] — contrasts on mechanism: that note is about friction *inside* a tool once someone is already using it (navigation overhead, feedback-loop quality); this note is about whether the tool sits *on* an existing routine at all, which is a precondition that has to be met before internal friction even matters - [[3. Resources/MOCs/DevRel MOC]] — home for adoption-mechanism claims that generalize across developer tools, GTM tools, and internal tooling alike - [[3. Resources/Permanent Notes/Usage Is Not Adoption When a Connector Fails in Silence]] — contrasts: this note locates adoption failure in where value is delivered, and the connector case locates it in a setup failure the vendor never sees. - [[3. Resources/Permanent Notes/A Tutorial Starts at the Reader's Actual Level, Not the Author's]] — has evidence from: set a tutorial's start line by what the reader knows (Kretzschmar). - [[3. Resources/Permanent Notes/A Page Labeled for Developers Loses Readers Who Don't Call Themselves Developers]] — extended by: test the audience word in a page header when the real readers have outgrown it (Kundel). ## Tests / falsifiers - Find a counterexample where a genuinely new destination (not an existing habit) achieved high adoption anyway, and check whether the work itself happened there — that would test the stated exception (IDEs, design tools, BI dashboards) rather than the core claim. - Watch whether GTM-AI vendors converging on the same few delivery surfaces (CRM, Slack) actually does reproduce the attention tax there, which the source itself flags as an unaddressed saturation risk. ## Source - [[3. Resources/Readwise/Articles/Why the Best GTM AI Meets You Where You Already Are Common Room]] — vendor blog post from commonroom.io; read and evaluated on its argument rather than its product claims, per the backlog note that it "generalizes to the security batch" on doorway/attention-tax reasoning.