# Define the Job Before Selecting the Automation ## Claim An automation is only worth deploying once you can state the exact manual job it replaces and what good output looks like. <!-- atomicity: 1 idea ✓ --> ## Scope & conditions - Holds for jobs that are repetitive, data-intensive, and have a clear definition of done — the category Common Room's GTM piece argues is worth automating. - Breaks for judgment-heavy or relationship work where "good output" resists a stable specification (the piece itself carves out strategy, relationships, and taste as staying human). - Does not establish that any single vendor's data layer is the required foundation for that job — that's a separate, self-interested claim the source makes but doesn't demonstrate. ## Evidence Common Room's GTM analysis argues most AI-agent deployments disappoint not because the model is weak but because teams point it at their biggest existing workflow and get more volume at the same close rate — the deployment failed, not the tool. Their recommended fix is naming the exact job being replaced before selecting a tool, restricted to jobs that are repetitive, data-intensive, clearly "done"-able, and currently done inconsistently across the team. > "The tool didn't fail. The deployment did." ## Links - [[Product & Startup Instincts MOC]] — the discipline that keeps automation decisions from being tool decisions - [[3. Resources/Permanent Notes/Automation Relocates Toil Into Supervision]] — because extends: automation doesn't remove the job, it changes what the human is responsible for — which is exactly why the job needs to be named first. - [[3. Resources/Permanent Notes/Agent Tooling Earns Adoption by Augmenting Existing Workflows]] — because applies-in: a defined job is the precondition for the workflow-augmentation pattern to actually land. - [[3. Resources/Permanent Notes/AI Activity Metrics Measure Tool Throughput Not Engineering Value]] — because contrasts: measuring throughput without a defined job is exactly the failure mode this claim guards against — more output, same close rate. - [[3. Resources/MOCs/AI & the Future of Knowledge Work MOC]] — because applies-in: this is a general AI-adoption discipline, not GTM-specific. ## Tests / falsifiers - Compare rep adoption rates between teams that write an explicit job + definition-of-done before deploying an agent versus teams that deploy tool-first. - Look for cases where "more sequences, same close rate" persists even after a job is explicitly defined — that would falsify the claim that job-definition is the binding constraint. ## Maintenance - Last tended: 2026-08-16 - Next review: 2026-11-16 ## Source - [[3. Resources/Readwise/Articles/AI Agents in GTM What They Should Truly Do]] — reports the deployment-failure pattern and the job-selection criteria this claim generalizes from.