If the last mile is the work of getting a tool’s output into the place the user actually needs it, the first mile is the mirror image: the work of getting the document into the tool in the first place. It’s the very start of the task, and it’s easy to underweight because in a demo it’s trivial — you drag in a clean PDF you prepared earlier. But the real first mile is where the user’s document actually lives, in the form it actually takes, and the friction there decides whether the tool gets opened at all.

Real documents don’t start as clean uploads. They’re attachments buried in an email thread, files in a shared drive with a dozen near-duplicate versions, scans of physical paper, exports from another system in an awkward format, or a single PDF that actually contains three separate documents stapled together. The user’s first interaction with the tool isn’t “extract this” — it’s the unglamorous work of locating the right document, getting it into a form the tool accepts, and confirming it’s the version they actually mean. If that work is heavy, it’s a tax charged at the start of every single use, and taxes charged up front are the ones that stop people from starting.

The first mile is where good intentions about adoption go to die, because it sits before the value. A user who’s already seen the tool’s output knows what they’re working toward and will tolerate some friction to get there. But the first mile happens before that payoff, when the user is deciding whether this task is worth the effort at all. High friction here doesn’t produce a worse result — it produces no result, because the user defaults to their old manual process rather than fighting to get the document into the tool. The tool never gets the chance to be good, because it never gets the document.

Reducing first-mile friction means meeting the document where it already is. Accept the messy formats users actually have instead of demanding a clean one. Handle the multi-document file by helping the user split it rather than failing on it. Make it trivial to pull from the places documents actually live — the email, the drive, the system of record — instead of requiring a manual download-then-reupload dance. Tolerate the imperfect scan and say clearly when quality will affect the result. Every bit of friction removed from the start is friction removed from every future use, which compounds in a way that a one-time improvement elsewhere doesn’t.

The symmetry with the last mile is the real lesson: a tool’s usefulness is bounded by its edges, not its center. The extraction in the middle can be excellent, but if getting the document in is a chore and getting the output out is a chore, the excellent middle is wrapped in enough friction that the user does the whole thing by hand instead. The center is what you demo. The edges are what determine whether the tool is used. Build the first mile and the last mile with the same seriousness you bring to the extraction, because to the user they’re not separate from the product — they’re the parts they actually touch first and last.