Work Management — When a Document Becomes a Workflow

One of the things I find most interesting about enterprise software is that customers rarely experience the product the way we design it internally.

Inside a product organization, we might have a document-management team, a tasks team, a collaboration team, an eSignature team, and a workflow team. Each capability has its own roadmap, metrics, engineering team, and product manager.

But the customer doesn't experience those boundaries. They simply have work they need to complete.

A document is a good example. At first glance, a document is just a file. You upload it, store it, share it, and eventually download it.

But in a real business process, documents rarely exist in isolation. A document might represent a request, an approval, a compliance requirement, a customer deliverable, a contract, or a decision.

Someone needs to request the document. Someone else needs to provide it. Another person needs to review it. Someone might need to make corrections. Another person may need to sign it. Eventually, somebody needs to know whether the entire process is complete.

At that point, the document isn't really the work. The workflow around the document is the work.

The traditional mental model for document software is largely object-centric: here's your file, here's your folder, here's your permission, here's your share link.

But the customer's mental model is often outcome-centric.

They aren't thinking, "I need to upload a document." They're thinking, "I need to collect all the documents required to complete this process."

Those sound like similar problems until you map the actual workflow.

Imagine a business collecting documents from a customer. They might create a folder, send an email requesting the files, explain what is required, wait for a response, follow up when something is missing, review what comes back, request corrections, obtain signatures, and finally mark the process complete.

From the product's perspective, those could be several separate features.

From the customer's perspective, it's one job: collect and complete the required documents.

That difference changes the product strategy. Instead of asking how we can make each individual capability better, we can ask how we can make the journey between those capabilities more seamless.

A request can create a task. A document can become part of that task. A review can trigger another action. A signature can represent a completion milestone. An activity stream can provide the context around what happened.

The individual features start becoming building blocks inside a larger workflow.

The opportunity isn't necessarily to build another generic project-management product. It's to understand where work naturally happens inside the business and reduce the friction between the systems and actions required to complete it.

That requires thinking about the customer's job rather than the product's information architecture:

Where does the work begin? Who owns the next step? What information needs to move between people? Where do handoffs fail? What causes delays? What does "done" actually mean?

Those questions often reveal product opportunities that aren't visible when you look at features individually.

A file is an object. A document is information. But once people start acting around that document, it becomes part of a workflow.