Picture the Friday afternoon call. Someone on your team found a tool. It drafts proposals, or sorts support tickets, or writes the weekly report. They demo it, it looks great, and by the end of the call three people have volunteered to build it out over the weekend.
Nobody has asked the only question that matters: what problem does this solve, and what is solving it worth?
I have watched that scene play out in companies of every size, including my own. It is the moment most AI projects fail, and it happens before anyone writes a single prompt. The failure is not in the model. The failure is that nobody wrote the brief.
The one page that decides whether anything gets built
No workflow gets built without a one-page brief covering five Ds
At Edge8 we run one rule on this, and I put it in writing on our method page: "No workflow gets built without a one-page brief covering five Ds."
That page shows the whole method in one sweep. This post slows down on the first step, the one that comes before any building, because it is the step teams skip when they are excited about a tool.
Here are the five Ds in one sentence. Define the problem and a FAST goal, name every Datasource, Diagram the flow end to end, Determine the ROI, and plan how to Deploy it through three stage gates.
Each D is a question a team can fail. That is the point of the brief. Failing a question on paper costs you an afternoon. Failing it in production costs you a build, a rollout, a team that stops trusting the next AI idea, and a founder who concludes that AI does not work for a company like theirs. It usually does. It just never had a brief.
Two of the five belong to humans alone
AI helps with three of the five Ds. It can go find the data, it can draw the flow, and it can help plan the rollout. I will come back to those.
The other two belong to people, and no model changes that. Only a person can say what problem is worth solving. Only a person can decide that the return justifies the work. Those two are Define and Determine ROI, and they are the ones teams skip most often, for an obvious reason: they are the hard part, and the tool is the fun part.
That order is the whole argument of this post. The three shared Ds are cheap to redo if you get them wrong. The two human Ds decide whether the other three are worth doing at all, and they are the only two a tool demo cannot answer for you.
So that is the exercise for today. Not a strategy offsite, not a vendor review. Two lines.
The exercise: pick one workflow and write two lines
Take one workflow you want to hand to AI. The one from that Friday call is a good candidate. Open a blank document and write two lines for it: the Define line and the Determine ROI line. If both lines write cleanly, you have the spine of a brief and you can move on to the other three Ds. If either one will not write, the workflow is not ready to build, and you just found that out for free.
Line one: Define the problem and a FAST goal
a workflow that cannot name its problem is a solution looking for one
The Define line has two halves. The first is a problem statement. The second is a FAST goal: a goal that is frequently discussed, ambitious, specific and transparent, so the whole team can see it and measure it rather than file it away.
Start with the problem, and be strict about what counts as one. "We want to use AI for customer support" is not a problem. It is a tool with a department attached. "Support tickets that need a human sit unread until someone gets around to the queue" is a problem. You can see who feels it, you can see when it happens, and you can imagine measuring it.
A good test: cover up the tool name and read the sentence again. If it still describes something that hurts the business, you have a problem statement. If it collapses into nothing without the tool in it, the method page has a line for that: a workflow that cannot name its problem is a solution looking for one.
Then write the goal. Make it specific enough to measure, ambitious enough to matter, and visible enough that the team talks about it. The shape is simple: move this measure from where it is today to where you want it by a date you name. Put your own numbers in. If you do not know where the measure is today, write that down too. It is the first thing the brief just told you.
Line two: Determine the ROI
if the return cannot be determined, the program does not start
ROI is return on investment. In plain words: what the workflow saves or earns, set against what it costs to build and run. The Determine line is one sentence that puts a number on the return side.
There are only a few places that number can come from. Hours of someone's time the workflow gives back, and whose hours they are. Revenue it unlocks because something now happens that did not happen before, like every lead getting followed up. Errors or rework it removes. Pick the one that fits, estimate it honestly, and write it down.
Then apply the rule from the method page without softening it: if the return cannot be determined, the program does not start.
That sounds harsh in a room full of people who want to build. It is the kindest rule in the method. It protects the team from months of work on something nobody can defend at the next budget conversation, and it protects you from the slow disappointment of an AI project that is technically running and changing nothing.
What it means when a line will not write
A line that will not write is not a failure. It is the filter doing its job. In my experience it comes down to one of three things.
The problem is a tool in disguise. The team wants to use the thing and has not found the pain it removes. Shelve it until the pain shows up, or go look for the pain in the workflow you actually have.
The number depends on data you do not have. You cannot say how long tickets wait because nobody tracks it. That is not a dead end. It is a Datasource question surfacing early, which is exactly where you want it to surface, and it tells you the first build might be measurement rather than automation.
The return is real but too small to justify the work. This one stings, because the demo was good. Write the small number down anyway and move on to a workflow where the number is bigger. The brief exists so you spend your team's time on the second kind.
In every case you are learning on paper what you would otherwise learn in production, and paper is cheaper.
The other three Ds, and where AI actually helps
Once the two human lines are written, the rest of the brief is shared work between your people and the AI. For each one, here is what the AI does and what the person still decides.
Datasources. Name every piece of data the workflow needs, where it lives, whether it is clean, and whether AI can reach it. The AI can help find where the data sits across your tools and test whether it can get to it. The person decides which data is in scope and whether it is clean enough to trust.
Diagram. Document the workflow end to end and draw it. The AI can take a plain description of how the work happens today and produce a first draft of the flow. The person corrects it, adds the exceptions the AI never saw, and signs off that the drawing matches reality.
Deploy. Plan the rollout through three stage gates: S1 is the prototype, S2 is the pilot, run on a real slice of work and measured against a baseline, and S3 is production. The AI can help plan the sequence and track the measures. The person decides whether the workflow passes each gate, and the Determine ROI line from earlier is what they measure it against. That is why the line has to exist before the build starts: the pilot has nothing to beat without it.
All three of those are easier than the first two, and all three are safer, because they happen after a human has decided the problem is real and the return is worth it.
Why a brief and not a backlog
Most companies keep a list of AI ideas. Very few keep briefs. The difference is that a list grows and a brief filters. The 5D brief is less a planning document than a gate: a workflow either names its problem and its return, or it does not get built. That is a position, and I hold it because I have seen what happens without it, both at clients and in my own company.
This is the same method we teach in the AI Officer certification and the same one we apply at Edge8. We do not run workflows we could not write a brief for. It keeps the team honest, and it keeps the founder from buying tools to find out what they are for.
Your next step
Today, before the next tool demo, take one workflow you want to hand to AI and write two lines: the Define line, with the problem and a FAST goal, and the Determine ROI line, with the number it saves or earns. If both write, you have a workflow worth taking through the other three Ds. If either will not, you just saved yourself a build.
Then go back to the method page for the Datasources, Diagram and Deploy lines, and for the rest of the method that sits around the brief: the seven elements, the Centaur Map, the New Hire Test and the three stage gates.
Reply and tell me which workflow you picked and which line would not write. The stuck line is usually the more interesting of the two, and it is the right place to start the next conversation.
FAQ
How do I decide which AI workflow is worth building before my team starts on the tool?
Before anyone touches the tool, open a blank document and write two lines for the workflow: a Define line that states the problem and a FAST goal (frequently discussed, ambitious, specific, transparent), and a Determine ROI line that puts a number on what it saves or earns. These are the two of the five Ds that belong to people alone, and the ones teams skip most often because the tool is the fun part. If both lines write cleanly you have the spine of a brief and can move on to the other three Ds; if either will not write, the workflow is not ready to build and you found that out for free, which is the rule Dave Hajdu set on the Edge8 method page.
What should a one-page brief for an AI project cover before anyone builds it?
The Edge8 method page puts it in one sentence: no workflow gets built without a one-page brief covering five Ds. Define the problem and a FAST goal, name every Datasource, Diagram the flow end to end, Determine the ROI, and plan how to Deploy it through three stage gates. Each D is a question a team can fail, and failing one on paper costs an afternoon while failing it in production costs a build, a rollout and a team that stops trusting the next AI idea.
Which parts of planning an AI workflow should people do themselves instead of handing to AI?
AI helps with three of the five Ds: it can find where the data sits, draft the flow diagram from a plain description, and help plan and track the rollout. The other two, Define and Determine ROI, belong to humans alone, because only a person can say what problem is worth solving and only a person can decide the return justifies the work. Those two human Ds decide whether the other three are worth doing at all, and they are the only two a tool demo cannot answer for you.
What should I do if I can't put a number on the ROI of an AI project?
Apply the rule from the Edge8 method page without softening it: if the return cannot be determined, the program does not start. In Dave Hajdu's experience a line that will not write comes down to one of three things: the problem is a tool in disguise, the number depends on data nobody tracks, or the return is real but too small to justify the work. The second case is not a dead end; it means your first build may be measurement rather than automation, and you learned that on paper instead of in production.
How do I roll out a new AI workflow to my team without it falling over in production?
Plan the rollout through three stage gates: S1 is the prototype, S2 is the pilot, run on a real slice of work and measured against a baseline, and S3 is production. AI can help plan the sequence and track the measures, but a person decides whether the workflow passes each gate, using the Determine ROI line written before the build started. That is why the ROI line has to exist first: without it the pilot has nothing to beat.