When you’re building a document processing tool for a specific professional workflow, the first document type you support matters disproportionately.

Not because the other document types aren’t important. They usually are. But the first one determines whether the product has a reason to exist on day one — whether a potential user can pick it up on a real deal with real documents and walk away with something useful.

The wrong first document is one that matters eventually but isn’t needed immediately. It might be on every firm’s wish list but rarely the thing that blocks a deal. A team can wait for it, work around it, or handle it through existing processes. The product has a feature that nobody tries yet, and nobody trying it means no feedback, no iteration, and no momentum.

The right first document is the bottleneck. It’s the task that takes the most time on the most deals, that has the highest error rate when done manually, and that directly competes with the time available to do it. When a team is staring down a thirty-day diligence window and the most time-consuming task is sitting in a stack of documents, that’s the first document.

Identifying the bottleneck isn’t complicated. Talk to people who do the work. Ask where time goes. Ask what they dread when a new deal drops. Ask what they wish they could hand off. The answer is usually consistent within a vertical — the bottleneck is structural, not idiosyncratic. It comes from the shape of the work, not the preferences of individual analysts.

When you build the first document right, the product is immediately useful. Users bring it into a real workflow on a real deal. It saves time on something that genuinely needed saving. The feedback is specific and actionable. The second and third document types become obvious, because users tell you what they need next.

The first document is not a feature. It’s the reason the product exists. +++