How To Know If An AI Project Is Worth Starting

Taras Tymoshchuk, the Founder & CEO of Geniusee.

According to McKinsey's "The State of AI In 2025," 88% of organizations regularly use AI in at least one business function, but only 39% can point to any impact on earnings before interest and taxes.

From my discussions with leadership teams, I've found this lack of ROI is often caused by leaders having a strategy for using AI but not an operating model that reflects that strategy. ​

For instance, I often hear leaders say they ​want to find places to plug AI in. That's not the right place to begin. You first need to ask: Would AI change the cost, speed or quality of a specific piece of work? Without knowing what you want to achieve from the outset, pilots will continue to struggle to demonstrate meaningful value.

While understanding the technology itself is important, I've found that many leaders tend to make three common mistakes that have nothing to do with the models.

First, many leaders start by asking where to implement AI rather than looking at what work is expensive and time-consuming. In other words, they build toward whether something looks credible in a board meeting: a list of use cases ranked by visibility, not by what they cost the business.

Then, compounding the first problem, they track AI usage the way they track CRM logins: queries, active users, hours of "AI time." However, if a team spends a year enthusiastically using AI on the wrong workflows, they will still have nothing to show for it.​

Finally, the third mistake—and often the one that prevents most AI projects from getting off the ground—is skipping the unit economics. By looking at model accuracy, they ignore the labor cost of the current process: how long one execution takes, how often it runs and how many people run it in parallel. Without that math, you're often spending more to build and maintain the automation than the work it replaces.​

Before we understood this problem, my company's teams were using AI on personal productivity and small shortcuts. Then, we added a corporate account and, while usage went up, we saw the same issue that most other companies in the McKinsey survey are seeing: Nothing changed in the business.​

However, by approaching AI like product discovery, we were able to see more meaningful results. Instead of asking where to use AI, we estimated labor costs across three components: net time per execution, frequency of a process and the number of people running it in parallel.

With these metrics, you can understand the financial impact of an AI project before determining whether to build it. If a project involves too many exceptions, too little repetition or too much ongoing maintenance, it will likely not show financial value regardless of how interesting the use case sounds.

In the recruiting department, for instance, one workflow that survived this filter now grades inbound résumés against 12 criteria and saves the team roughly 120 hours per month. A side effect we did not predict: The automated rejection emails turned out to be more thoughtful than the templates recruiters used to send manually.

In sales, a follow-up generator now drafts roughly 100 hours per month of personalized outreach for engagement managers, capacity that can be redeployed into new presales rather than administrative writing.

These projects are small and measurable automations that compound, which is the whole point.

The order of implementation matters more than most leaders realize. Below is the step-by-step framework to implement this model:

1. Start by identifying the processes that run constantly, follow a pattern and don't require a judgment call every time. Don't think about which AI to use until you've picked the process.

2. Then do the labor math. How long does one process take, how often does it run and how many people are involved? If the number is small, move on. If it's large, you have something worth building.

3. Filter hard. If the AI requires too many exceptions, skip it. If it's too infrequent of a process, it's not worth automating. If it involves too much ongoing tuning, it will cost more than it saves. Most use cases fail this filter. That's fine. Better to know before you build.

4. Once you have a real candidate, design the process around the AI, not the reverse. The mistake I see most often at this stage is dropping AI into an existing process without changing the process itself. In these cases, the system produces output nobody acts on or a human re-does the work anyway. The AI-enabled process is doomed to fail because nobody agreed upfront on how to measure whether it's working.

5. Measure business outcomes. Some of these outcomes include cycle time, throughput, conversion and redeployed hours.

Gartner's survey of 782 leaders found only 28% of AI use cases in infrastructure and operations fully meet ROI expectations, and 20% fail outright.

The rest stall somewhere in between. However, in my experience, if the AI cannot be traced to a line in the profit and loss statement, it will likely get cut.​

One important thing to remember: Don't treat any single automation as the win. Each one that pays back frees up capacity for the next. That's where the real return comes from: not one big project, but ten small ones.

Getting real returns from AI does not involve doing anything dramatic, only picking processes where the math works and then building small, measuring results and moving to the next one.​

AI becomes valuable when someone elaborates upon a specific process, runs the numbers and decides whether to build or move on. That's where it either pays off or doesn't.​​

Forbes Technology Council is an invitation-only community for world-class CIOs, CTOs and technology executives. Do I qualify?