Design the work before you build the tech.

Most AI projects do not fail because the model was weak. They fail because nobody designed the work first. Automating a process you have never mapped does not fix it; it just makes the broken parts run faster and with more confidence. So the order matters: workflow design comes before model choice, before platform choice, before the first line of code. Sit with the people who do the job. Map what actually happens, not what the process doc claims. Find the one or two moments where time and judgment really go. Design the smallest change that moves those moments, agree on what good looks like, and then build.

There is a pattern we see again and again. A team buys a capable model or a slick platform. Someone builds a demo that works on a Tuesday afternoon. Everyone nods. Then it meets the actual job and quietly dies. Six months later the tool is a tab nobody opens, and the work it was meant to fix is being done the old way, by hand, by the same three people who were always doing it.

We think the order most teams run is backwards. The model is not the hard part anymore. The hard part is the work, so we start there.

The job is not what the org chart says it is

Every real workflow has a version written down and a version that actually happens. The written one lives in a process doc. The real one lives in someone's head, in a shared inbox, in a spreadsheet with a tab called final_v3_USE_THIS.

Take a deal-sourcing team we worked with. On paper, leads come in, get scored, get routed. In practice, one analyst knew that any listing from a particular kind of seller needed a second look, because half of them had a detail buried on page four that killed the deal. That rule was written down nowhere. It lived in her hands. Build from the model and you automate the paper version, shipping something that confidently sends bad deals up the chain. Sit with her first and you find the page-four rule before you write a line of code. When we built that team's sourcing system around rules like hers, it surfaced 3.2x more qualified opportunities. Not because the model was smarter. Because the map was honest.

You cannot get that from requirements gathering on a call. You get it by watching the work happen and asking dull, specific questions. What did you just do there. Why that one and not this one. What makes you stop and check. This is why we treat a proper workflow audit as the first real deliverable of any engagement, not a formality before the build.

Why workflow design comes before model choice

The map decides the size of the build. A clear map of the actual work makes the build small: you know which step hurts, which inputs matter, which judgment calls stay human. A fuzzy map makes it sprawl. You build for every case because you never learned which cases count, and the project grows until someone quietly kills it.

Model choice, by contrast, is close to a commodity decision now. Any frontier model can draft an email, extract fields from a document, triage an inbox. Pick wrong and you can swap it in a week. What you cannot swap in a week is a system built on a wrong understanding of the work. That mistake is load-bearing. It gets poured into the prompts, the integrations, the handoffs, and the expectations of everyone who watched the demo.

This is where most stalled pilots trace back to. Look closely at why AI pilots fail and the post-mortem is rarely about the technology. It is a demo built against the paper version of a process, shipped to people who live in the real one. Design work closes that gap. Buying a license does not; tools do not change work on their own.

Why the operator beats the engineer here

This is the part people push back on. The claim sounds backwards. The build is technical, so surely the technical person should lead it.

We disagree, for most teams. An engineer leading the build optimizes for what is buildable and elegant. They reach for the interesting problem. They will give you a retrieval pipeline with a clean diagram and a system that answers the question nobody actually asked. A good operator who understands the business asks a different thing. Will this change what someone does at 9am on Monday. Will they trust it enough to stop double-checking it. Those are the questions that decide whether anything lands. It is also a large part of why we tell most SMB teams not to hire an AI engineer yet.

The model is not the hard part anymore. The hard part is the work.

The operator also speaks the language of the people who have to live with the tool. A finance lead can tell an operator, in plain words, that the close breaks every quarter because one report arrives late and in the wrong format. They will not say that to a stranger holding a laptop full of jargon. Trust moves the real information. And the real information is the whole game.

None of this means we skip the engineering. We have built the platforms, the connectors across Slack and Teams and email, the assistants that hold up under load. The point is sequence. Engineering is step two, and it is much cheaper and much better when step one is done right.

What starting from the work looks like

Our process runs in three steps: map the workflow, ship the build, enhance. The mapping phase takes days, not a quarter, but it is structured:

1. Shadow the work. We sit with the team while the job happens, including the parts people are slightly embarrassed by. The workarounds are not noise; they are the spec.
2. Find where time and judgment concentrate. Most workflows have one or two moments that carry the cost. Everything else is plumbing.
3. Design the smallest change that moves those moments. Not the platform. Not the transformation roadmap. The smallest useful change.
4. Agree on what good looks like before anyone builds. A number, a turnaround time, a complaint that stops. Written down, in advance.

Often the first version is almost boring. A connector that pulls the right context into one place. An assistant that drafts the thing a person used to write from scratch, so they edit instead of starting cold. Nothing that would impress at a conference. But people use it on Monday, and they keep using it in March, because it was shaped around how they already work rather than asking them to work around it. One executive team we support reclaimed 13 hours per executive every week this way. No exotic architecture. An assistant designed around the actual shape of their day. Everything in our services runs in this order, whatever the build turns out to be.

The cost of running it the other way

Start from the model and you pay later. You pay in tools that get abandoned. You pay in trust, because the first thing a team sees is something that gets their job slightly wrong in a way that tells them you never understood it. That impression is expensive and slow to undo. And the second attempt is harder than the first, because now you are automating a process and rebuilding credibility at the same time.

Starting from the work is not the cautious choice. It is the faster one. You build less, you build it once, and it survives contact with reality.

Where to start

Pick one workflow everyone already complains about. Watch it happen end to end before you evaluate a single tool. Write down where the time goes and which decisions require judgment. If the map surprises nobody, you watched the paper version; go back and watch again.

We are a small, senior team, and we like it that way. It means the person who maps your work is close to the person who builds the tool, and we stay on afterward to keep it honest as the work changes. If you have a workflow that everyone agrees should be better and nothing has stuck, we would enjoy talking it through with you.