Somewhere in your building, a good automation idea is stalled behind a sentence: "we need to sort out our data first." The sentence feels responsible. It's usually a category error — it treats data readiness as a company-wide state, when the only readiness that matters is per-workflow.
The proposal generator doesn't care that your warehouse project is behind. It cares whether discovery notes and past proposals are reachable. That's the whole bar.
01What one workflow actually needs
- ▸Reachable inputs. The workflow's inputs exist digitally, somewhere queryable — an inbox, a CRM, a folder of PDFs. Not clean, not unified. Reachable. Modern extraction handles messy formats better than the platform pitch admits.
- ▸A few dozen examples. Past executions of the workflow — the emails sent, proposals written, tickets resolved. These calibrate what "good" looks like. Dozens, not thousands: this isn't model training, it's context.
- ▸A place for outputs to land. A system of record the result writes into. If this doesn't exist, creating it is phase one of the same build — not a separate initiative.
02The platform trap
The data-lake-first argument says: unify everything, then build intelligence on top. It fails in practice for a predictable reason — without a consuming workflow, data projects have no forcing function for what "clean" means. Teams spend quarters normalizing fields nothing reads, guessing at requirements the future was supposed to send back in time.
Workflow-first flips the dependency. The automation defines exactly which data matters, what shape it needs, and what quality bar it must clear — because the workflow breaks visibly when the bar isn't met. Each build leaves behind a small patch of genuinely production-grade data. Enough workflows, and you've built the platform bottom-up, every piece of it load-bearing.
03When the data really is the blocker
Sometimes the sentence is true. Honest signals that a workflow's data genuinely blocks automation:
- ▢The inputs are physical paper that nobody scans — digitization is genuinely step one.
- ▢The workflow's history lives only in people's memories: no sent folder, no saved outputs, nothing to calibrate against.
- ▢Two systems disagree about the same facts and there's no rule for which wins — automation would just pick fights faster.
- ▢Access is the issue: the data exists but governance hasn't decided anyone can touch it. That's a decision blocker wearing a data costume.
04A representative pattern: the knowledge assistant
The clearest illustration is the project most often held hostage by the platform pitch: the internal knowledge assistant. The data-lake framing says the company must first unify its documents — a migration, a taxonomy committee, a governance rollout, four quarters minimum. The per-workflow framing asks instead: what does answering staff questions actually require?
The honest list is short. The two hundred documents that answer 90 percent of recurring questions — not the whole drive, the working set: policy manual, current SOPs, product docs, the FAQ nobody maintains. An owner per source who can say which version is authoritative. A staleness rule for what falls out of scope. Read access for an indexing job. That is the entire substrate, and assembling it is a two-week task for someone who knows the org — most of it spent getting owners to bless their own documents.
What about the other ten thousand files? They stay where they are. The assistant that answers from two hundred curated documents beats the one that retrieves from ten thousand unvetted ones on every axis that matters — accuracy, trust, auditability. And each quarter, usage data tells you exactly which sources to add next: the questions it couldn't answer are the backlog. The lake never had that feedback loop; the workflow generates it for free.
05The honest sequencing
Pick the workflow. List its actual inputs. If they're reachable, build — and let the build force the data into shape one lane at a time. If they're not, scope the smallest data fix that unblocks this one workflow and call that fix what it is: the first half of the automation project, with the same owner and the same finish line.
"Fix the data" as a standalone initiative has no natural end. "Make discovery notes reachable so the proposal generator can read them" ends in weeks, and something visible turns on when it does.
OPERATOR NOTE — Data readiness is a property of a workflow, not a company. Companies that wait to be ready company-wide are waiting forever, on purpose, comfortably.
Put this thinking to work.
A 30-minute strategy call with an operator — we'll map your first deployment path, not send a deck.