AI Strategies is failing. If you’re in IT leadership right now, there’s a decent chance this sounds familiar: the board wants an AI strategy, every department has an opinion on where AI should be used, and somehow it’s landed on your desk to make sense of it all, how much to invest, what to expect back, and where to actually start.
Marketing wants it for content. Finance wants it for reporting. Ops wants it for the manual work nobody enjoys doing. Everyone’s pointing at AI as the answer, but nobody’s quite said the question it’s meant to answer. And IT is left holding the job of turning “we should be doing something with AI” into an actual plan, usually with no extra budget and no extra time. It’s the kind of gap Technofy IT gets called in to help close.
We sat in on a strategy conversation with a client recently that had exactly this shape (details changed to protect client confidentiality). Architects, data engineers, and the project manager were all in the room, all genuinely excited, all pitching in with ideas, what to build, what to automate, what was technically possible. There was no shortage of enthusiasm or use cases.
So we asked one question: if we did everything we’d just discussed, how would we measure success?
The room went quiet. For about three minutes, nobody had an answer.
That silence is more common than you’d think, and it’s worth paying attention to, because it’s usually the moment a business finds out its AI strategies were never really a strategy. It was a list of exciting possibilities, built under pressure to “do something,” with no clear way to judge whether any of it was actually working.
Once the silence broke, the conversation changed. Instead of debating which tools or architecture to use, the room started working backwards from outcomes, and gradually, a real strategy started to take shape.
The trap of starting with “How”
It’s an easy trap to fall into. AI is everywhere in the business press, every vendor has a pitch, and the pressure to “have an AI strategy” is real. So organisations jump straight to the how: which platform, which architecture, who governs the data, who do we need to hire.
The problem is that none of those questions can be answered properly until you know why you’re doing this in the first place. Architecture, data governance, and hiring are all downstream decisions. They should be shaped by your objective, not the other way around.
Without an objective, AI strategies aren’t a strategy. It’s a shopping list.
What makes a good AI business objective?
Here’s where most of these conversations go sideways: people reach for something that sounds like an objective but is actually a solution. “Build a digital twin,” “deploy a chatbot,” “roll out an AI platform”- these belong on the shopping list too, not above it.
A genuine objective stays at the business level. It doesn’t mention AI, a platform, or an architecture at all; it names a change the business wants to see, measured in terms the business already understands: time, cost, revenue, satisfaction.
A weak version sounds like “implement AI across the business”: no measure, no deadline, no way to check in six months whether it worked. A strong one is specific enough that anyone in the room could mark it done or not done, without an argument about what “done” means:
- Cut customer response time on product questions from two days to under two hours, without adding headcount to the support team.
- Reduce operating expenses by 3% year on year by automating the laborious, repetitive work that eats staff time without adding value.
- Reduce the number of jobs that run late or get missed, so customers stop chasing the business for updates.
Notice these three sit in completely different parts of the business, and none of them assume a solution. Any one of them could be solved without AI at all: a process fix, a better roster, a simpler form. That’s exactly the point: the objective has to earn its place first, before anyone decides what solves it.
From business objective to AI opportunities
This is where AI actually re-enters the conversation, as an opportunity, not the objective itself. Once you know what the business is trying to achieve, you can ask a much sharper question: which of the ways we could achieve this involve AI, and which don’t?
Take “reduce operating expenses by 3%.” A handful of AI opportunities might genuinely serve that objective, automating data entry, flagging invoices that need review, summarising reports that currently take someone half a day. But so might things that have nothing to do with AI: renegotiating a supplier contract, cutting a subscription nobody uses, adjusting a roster. The objective doesn’t rule AI in or out. It just puts every option, AI and non-AI, on the same footing, judged by whether it actually moves the number.
Once you’ve got a shortlist of opportunities against an objective, the next question is which one to start with. Weigh each on two things: how much value it delivers, and how easy it is to get moving. The best starting point is usually high value and low effort, not necessarily the most exciting idea in the room. That first project is your hero use case: it proves the model, builds internal confidence, and gives you a real number before you commit further spend. Testing one opportunity properly tells you far more about expected ROI than a strategy document trying to cover every department at once.
Why this changes everything downstream
Once the objective is set and the opportunities are weighed, the rest of the conversation gets a lot easier:
- Data governance stops being a generic “let’s tidy up all our data” exercise and becomes “what data does this specific opportunity actually depend on?”
- Architecture decisions get simpler because you’re building toward a defined outcome, not a hypothetical future need.
- Hiring and skills questions answer themselves; you know what capability gap you’re actually trying to fill.
Skip the earlier steps, and you end up with expensive infrastructure, a data governance team with no clear mandate, and a business case nobody can defend at budget review time. We’ve seen this play out, not because the people involved weren’t capable, but because the sequence was backwards.
A simple starting point
Before your next AI strategy conversation, try answering these first:
- What business objective are we actually trying to move not “use AI,” but what number or outcome changes if this works?
- Which options, AI or otherwise, could realistically move it, and which one is worth testing first?
- How would we know it’s working, and what’s the smallest way to prove that before committing to a full build?
If you can’t answer those with something concrete, it’s worth pausing before spending on architecture, data cleanup, or new hires.
Where this fits for SMBs
For a business with 10 to 100 staff, this matters even more than it does for a large enterprise. You don’t have the budget to build the wrong thing twice. Getting the objective right first is the cheapest part of the whole exercise, and the part most likely to be skipped.
If your organisation is having this conversation and finding the room goes quiet in the same place ours did, that’s a reasonable point to bring in an outside perspective. Technofy IT’s IT Strategy & Virtual CTO service is built around exactly this, helping SMBs settle the objective, weigh the real opportunities against it, and only then commit to the architecture, the data work, or the hire. If that sounds like where you’re at, we’re happy to have a chat and see if it fits your business.
