The “Quick Win”

When beginning an AI effort in an organization, the usual mantra is to get a “quick win” as quickly as possible. This is usually for good reasons. It may be important to prove out the value of AI to a skeptical executive, or perhaps a “quick win” will be necessary in order to get the funding that your AI project deserves.

These are good reasons to go for the “quick win.” A typical project along these lines could be an AI or machine learning analysis presented to an executive, or a single one-off batch job that attaches some sort of score to an existing customer base. But whatever your business does, a “quick win” project almost always has the following characteristics:

• Little involvement from engineering, and probably no new technical infrastructure
• Very little automation in favor of human-in-the-loop processes
• Minimal adoption of engineering best practices

Basically, any corner that can be cut is cut. Your team will minimize expense and time to get to some measurable value. At the end of a successful project, that value will be an important proof point for an argument for further investment in AI, or whatever else was the motivation for going this route.

I’m always skeptical of “quick win” projects, although from an organizational change perspective, there is sometimes no way to avoid them. But of all these projects I’ve seen, the vast majority end up producing no value whatsoever, even when the project is deemed a success. There are a few reasons for this. Most often, it turns out that you’ve had to stitch together a very fragile pipeline for getting the output of your work implemented in the real world. That pipeline fails because of some unforeseen obstacle or because a key person stops cooperating. Fixing the pipeline is seen as too costly, which turns out to be true because the project never promised to produce tremendous value in the first place.

But sometimes these projects do succeed. What next? The business has two options. You can move on to another “quick win” project, or transition into a more ambitious project that is more likely to produce long-term value and help transform the organization.

It is amazing to witness the allure of a second, and then a third, “quick win” project. Following the success and praise of the first project, the AI leader is under pressure to duplicate the result. The end result is a lot of ad-hoc work that produces a little bit of value for the business, but fails to justify the existence of the team. Eventually, the appetite for AI diminishes, the team experiences too much turnover, and gradually withers.

Lay the Foundations for the Big Project

The alternative is to make a seamless transition to ambitious long-term projects that justify the investment in AI. But in order to make such a transition, you have to plan for it early — before the “quick win” project has even started.

The right way to choose your “quick win” project is to look beyond the short-term value it could produce. Instead, think about an AI-driven capability that you can’t build yet, but would be very valuable. It should be ambitious enough to have some skeptics, but feasible in the long run.

For example, suppose it would be great if your business could predict the lifetime value of each customer who calls into your service department, at the moment that they make the call. That lifetime value information could be used to prioritize calls, or select customers who should be offered some incentive for staying with your business. That would be a powerful capability.

Now ask the question, “Is there a more modest approximation of this project that’s feasible in the short-term?” For example, perhaps your team could generate a list of lifetime value predictions for the customers in one of your databases. Let’s assume that this smaller, more modest version of the ambitious project is something your team could accomplish fairly quickly. If so, then it’s a good candidate for a “quick win” project.

But now comes the harder part. You should not longer think of the “quick win” project as a self-contained effort. Instead, you need to think of it as the first step toward achieving the much more ambitious goal of (e.g.) a real-time customer service prioritization system.

Thinking of your project as one step toward a more ambitious goal has important implications. First, you need to communicate this vision to stakeholders, and you need to do this often. The ambitious goal should really be the identity of the entire project. This way, you help stakeholders envision a future where AI truly transforms the business, and you get buy-in early for future investments. Additionally, when it comes time to discuss something more ambitious, this topic will not feel like it’s coming from out of the blue.

Second, it has impact on how you plan and execute the initial project. You should be looking for opportunities to lay the technical foundations for something bigger. For example, instead of writing one-off code that you plan to never use again, you could spend a bit more time writing something more flexible, tested, and reusable. Instead of making do with infrastructure that’s not well-suited for the project, you could set up something that will scale better when it’s time to take on more ambitious goals. Of course, the details will vary depending on the context, but the point is the same. Look for opportunities to lay the foundations for the big project while you’re doing the small one.

There are huge benefits of using the “quick win” to transition to ambitious projects. You’ve helped your stakeholders think about the power of AI in the right way. In a business, AI should be transformative, not tied to incremental value. AI is also a long-term investment, and so this process will help everyone to think more strategically and less tactically. On the technical side, you’ll be constantly paving the way for building the capabilities that a truly transformative AI effort will require.