AI Can Help You Do the Wrong Work Faster
AI is usually positioned as a way to finish tasks faster. Write the email, build the spreadsheet, summarize the document, create the presentation, automate the workflow. Those capabilities are real, and I use them.
But most of the time I don’t need AI to do the work. I need help understanding the work before I start.
That distinction matters because a lot of business problems arrive disguised as execution requests. A team asks for another automation tool when the actual problem is an inconsistent process. A leader asks for a dashboard when nobody has agreed on the decision the dashboard is supposed to support. Sales asks for faster routing while ownership rules are still unresolved. Marketing asks for a new nurture program when lifecycle stages mean different things to different teams.
Every one of those sounds like work that needs to get done. Every one of them is actually a diagnosis problem.
And if the request is poorly framed, executing it faster doesn’t produce productivity. It produces accelerated misalignment.
The Task-Completion Framing
Most conversations about AI start with output. What can it write, what can it summarize, what can it automate, how much time does it save?
That framing makes sense. Task completion is easy to understand and easy to measure. A draft that took two hours takes twenty minutes. A report that required six manual steps runs on its own. A meeting transcript becomes a summary before the room clears. Those are real benefits.
They also rest on an assumption that usually goes unexamined: that the task is worth doing.
Sometimes the request is premature. Sometimes the problem is misdiagnosed. Sometimes the team is treating a symptom as the cause, or the deliverable is perfectly clear while the decision behind it is still vague. AI will produce something impressive under every one of those conditions, and that’s the part I find genuinely risky. A polished answer makes weak thinking look finished. The output arrives formatted, confident, and complete — which is exactly what a bad premise needs in order to survive review.
Speed was always a manageable problem. Fluency is harder. Doing the wrong work faster costs you a quarter. Doing it convincingly enough that nobody questions the premise can cost you a roadmap.
When the Request Is the Problem
Some of the most expensive operational mistakes start with a request that sounds completely reasonable.
“We need a lead-scoring model.” Maybe. But what decision is the score supposed to improve? Whether sales calls this account first? Whether marketing moves a lead into a different program? Whether a scarce resource gets allocated at all? And is the score predicting fit, intent, or readiness — because those are three different signals, and one number rarely carries all three honestly. If nobody can answer, the organization doesn’t have a scoring problem. It has a decision-definition problem, and building the model first produces a sophisticated number that nobody knows how to act on.
“We need better attribution.” Possibly. But attribution for what: budget allocation, campaign evaluation, channel planning, executive reporting, or settling a recurring argument between sales and marketing? Those decisions tolerate very different levels of precision. If leadership hasn’t agreed on the question, a more sophisticated model won’t resolve the disagreement. It will make the disagreement more technical.
“We need faster lead routing.” Often true. But routing speed sits downstream of decisions nobody has made yet. Who owns the account? Which rule wins when territory, product, and account ownership conflict? What happens when the data is incomplete? Which submissions route automatically, which require review, and what’s the fallback when the logic can’t resolve? Automate before answering those and you haven’t removed the uncertainty. You’ve moved it into the system, where it’s harder to see and harder to argue with.
“We need another nurture campaign.” Maybe the content is weak. Or leads are entering nurture too early, or never existing, or receiving contradictory messages because segmentation is thin, or sales and marketing are working from different lifecycle definitions. The request may still turn out to be the right one. It shouldn’t be accepted without inspection.
Using AI to Find the Actual Problem
Most of my ideas don’t arrive fully formed. They start as a reaction. Something about a process feels wrong. An accepted practice seems incomplete. I notice a pattern I can’t yet explain, or I disagree with a recommendation and can’t immediately say why.
That’'s usually when I open ChatGPT — not to get an answer, but to find out what I’m arguing.
I describe what I observed, give the context I think matters, explain what I currently believe, and then ask it to attack the framing. The most useful prompts are unglamorous:
What am I missing?
Which assumption here is weakest?
What would someone who disagrees say?
Am I treating a symptom as the cause?
What other explanation fits the same evidence?
What would have to be true for this recommendation to work?
Which part of this is evidence and which part is my interpretation?
What decision is this work supposed to support?
The value isn’t that the answers are right. Often, they aren’t. The value is that the hidden structure of the problem ends up on the page where I can look at it. Once the assumptions are written down, I can test them. Once competing explanations sit side-by-side, I can compare them. Once the tradeoffs are explicit, I can choose one deliberately instead of by default.
The most useful output is usually a better question, not an answer.
The sequence I keep returning to
Start with the observation, not the conclusion. “Lead response time is inconsistent” is a starting point. “We need AI-based lead routing” is a solution wearing the costume of a problem. The first leaves room for diagnosis. The second has already closed it.
Separate the symptom from its causes. Slow lead response can come from manual review, poor data quality, unclear ownership, weak notifications, territory conflicts, staffing limits, or the simplest absence of an agreed response-time expectation. Usually several are operating at once. AI is genuinely good at widening that list before you commit to the first explanation that fits.
Surface the assumptions. A dashboard request assumes the data is trustworthy, the metric definitions are shared, the audience agrees on the decision, and the report will change someone’s behavior. A new automation assumes the underlying process is coherent, the exceptions are understood, ownership is clear, and the cost of a wrong automated decision is acceptable. Those assumptions usually matter more than the deliverable does.
Generate competing explanations. This is where I get the most value. If sales isn’t following up on leads, the obvious read is that sales is ignoring marketing. It could also be that the leads are poorly qualified, that the context handed over is insufficient, that ownership is ambiguous, that the follow-up process is inconvenient, that compensation rewards other work, or that the system produces enough false positives that reps have learned to discount it. The first plausible story is rarely the whole diagnosis.
Name the decision. Every deliverable should map to a decision someone will make differently because it exists. A dashboard supports a budget decision. A score supports a prioritization decision. An attribution model supports an investment decision. A routing workflow supports an ownership decision. If nobody can name the decision, the work isn’t defined yet, and now amount of build quality will fix that.
What Stays Human
Once the problem is clear, the automation question gets easier, because you’re no longer deciding whether to automate a task. You’re deciding which parts of a process you now understand can run without judgment.
AI handles a lot of the diagnostic labor well: summarizing patterns, comparing options, identifying missing information, drafting alternatives, classifying routine inputs. What it can’t take on is accountability.
I still have to decide whether the context I gave it was complete. I have to verify the facts, judge whether my examples are representative, weigh the constraints the organization is operating under, choose which tradeoff the business should accept, and own the recommendation when it turns out to be wrong. ChatGPT can challenge an assumption, but it doesn’t know that an executive already rejected that approach last year. It can propose a cleaner process without understanding the political cost of moving ownership. It can build a persuasive argument that has nothing to do with anything I’ve seen.
That last one is why I read my own drafts skeptically. A model can make weak thinking sound finished, including mine.
The goals isn’t to keep a human in every step. It’s to keep human accountability where judgment, context, ethics, or consequence matter — and to decide where that line sits in advance, rather than discovering it after something goes wrong.
Where This Goes Wrong
The obvious failure mode of this argument is diagnosis that never ends.
Problem definition can become a way to avoid committing to anything: another round of alignment, another attempt to get every stakeholder to agree on a term. That’s it’s own kind of waste, and it’s harder to call out because it looks like rigor.
Some problems are also better understood by building something small and watching what breaks. If a team genuinely can’t agree on what a dashboard is for, a rough version in front of them will often produce the argument that settles it faster than another working session will.
The diagnostic work I’m describing is meant to be short. Hours, not weeks. And it should end with a decision about what to build, not a longer list of questions. The test I use is simple: has the conversation changed what I’m going to do? If two rounds of pressure-testing haven’t changed the plan, the plan was probably fine, and I should go execute it.
Direction Before Speed
The business case for AI is almost always framed as time saved, because time saved is visible and easy to put on a slide. It’s also the least interesting item on the list.
The larger returns don’t show up as artifacts: the project that gets stopped because the requested deliverable solves the wrong problem, the assumption caught before it was built into a workflow, the moment a team moves from “build this” to “what are we trying to decide?” None of that produces something you can point at in a status update. All of it is worth more than a faster draft.
Speed only becomes an advantage once the direction is right. Pointed at the wrong problem, a faster tool just gets you there sooner, with better formatting.
