Decided
Issue 20 — June 2, 2026
CONTEXT
I recently built a custom calculator tool using AI. I am not a developer.
The tool cross-references video wall specifications against controller hardware limits, something I had been doing manually for years. The manual process was slow and left room for error. I described the problem to AI and asked it to build a solution. It did.
That story is not about AI capability. It is about what had to happen before the AI was involved at all. I already knew the exact inputs, the exact output I needed, and where the manual process was breaking down. That knowledge existed before I opened any AI tool.
The AI did not diagnose the problem. I did. That is why it worked.
"The AI did not diagnose the problem. I did.
That is why it worked."
STRUCTURAL ANALYSIS
There is a consistent pattern in AI attempts that fail early. The owner brings a frustration, not a problem. "I want to save time on client communication." "I need to be more consistent with follow-up." "I want AI to help with marketing." These are categories of discomfort. They are not problems.
A frustration points at an area. A problem describes a specific breakdown: what fails, when it fails, what a working version would produce. That distinction determines whether AI can help at all.
When the input is vague, the output is vague. The owner gets a generic result, adjusts it manually, and decides AI is not quite right for their situation. They are correct. It is not right for that situation, because the situation was never defined.
There is a second failure pattern that follows. The owner assumes the gap is technical. They look for a better tool, a better prompt, a better configuration.
The gap is not technical.
It is diagnostic.
They skipped the work that makes the tool useful.
The calculator works precisely because the problem was already solved before AI was involved. I knew the inputs. I knew the edge cases. I knew what accurate looked like. AI executed a specification that thirty years of field work had already written. That is the actual model.
ORDER CHECK
Before using any AI tool to build, automate, or assist with a process, answer these questions with specifics, not categories.
1. What exactly fails, and when does it fail?
Not "communication is inconsistent." Identify the specific moment: which handoff, which step, which output is wrong or missing.
2. What would a correct output look like?
If you cannot describe the result you want, you cannot evaluate whether AI produced it. Vague success criteria produce vague results.
3. Have you done this manually enough to recognize the edge cases?
The calculator works because I had worked the problem by hand for years. That knowledge is what made the AI output trustworthy. If you have never worked the process manually, you cannot catch the tool's mistakes.
4. Is this a process problem or an upstream problem?
Some failures look like execution gaps but are caused by a broken step earlier in the workflow. Automating the execution does not fix the upstream cause. Identify which one you are actually dealing with.
If you cannot answer all four with documented specifics, you are not ready to use AI on this problem. Define the problem first.
"The tool did not solve the problem.
The problem definition did. Build that first."
THE DECISION
Do the diagnostic work before opening a tool.
That work is not glamorous. It involves writing down exactly what breaks, exactly what the correct version looks like, and exactly where the boundary is between what you know and what you are guessing. It takes longer than running a prompt. It produces better results.
The owners who get useful results from AI are rarely the most technical. They are usually the most precise.
The tool did not solve the problem. The problem definition did. Build that first.
Decide well,
Chuck
Decided
Weekly AI guidance for business owners making operational decisions.