AI projects mostly fail at the beginning — scoped in a meeting room, around a technology, by people who will never run the process. Here is what the first two weeks look like when they go right. It is also, not coincidentally, how we start ours.
Week one: map the work, not the tech
Sit with the people who do the process. Count things: how many documents, tickets, listings, audits per week; how long one takes; where it queues. The goal is a map of where hours actually go — which is reliably different from where management believes they go. Every system on our case list started as a number somebody measured, not a capability somebody pitched.
Pick the narrowest slice that is still useful
Not "automate support" — answer the top password-reset and order-status questions, with escalation for everything else. Not "process all documents" — one document type, end to end. A narrow slice ships in days, produces real feedback, and fails cheaply if it fails. The scope you cut is not lost; it is sequenced.
Week two: a working slice in real hands
Not a slide deck, not a demo on curated examples — a version the actual team uses on actual work, with a human checking outputs. Real usage surfaces in days what requirements workshops never find: the inputs are messier than described, the edge cases cluster differently, and the feature everyone insisted on goes unused.
Then decide on evidence
Two weeks in, you know the baseline, you have a working slice and its real numbers. Now the decision is arithmetic instead of faith: scale it, reshape it, or kill it. Killing a bad idea after two weeks is a success — it is the version of this story where the strategy-deck project dies after two quarters that should scare you.
