Pick the boring problem first.

Every company we work with comes in wanting the exciting AI use case and leaves shipping the boring one. There is a reason this happens, and it is not what most operators expect.

The exciting problem is the one in the pitch deck. The agent that books meetings. The chatbot that handles customer support. The tool that drafts proposals or writes outbound or summarizes board materials. It is the problem the founder gets excited about on a Tuesday afternoon when they have just read a Twitter thread about agents.

Exciting problems have three properties. They are visible. They are external. And they are hard to measure honestly because everyone has an opinion about whether the output sounds good.

Boring problems are the opposite. Internal. Invisible. Painfully easy to measure because they are already costing someone hours every week.

The reason boring problems are valuable is the same reason nobody wants to own them. They leak time every single day, in small enough amounts that no single person feels obligated to fix them.

A boring problem usually has these costs hiding inside it:

• Someone copies data between two systems every morning, because no one wired the integration.
• Someone reconciles two reports that were supposed to match, because upstream they never did.
• Someone manually flags exceptions in a queue, because the rules engine handles 80% and the rest looks too messy to automate.
• Someone writes the weekly status update, because pulling it from the data is harder than asking around.

Each of these tasks takes 30 minutes. None of them has a single owner. All of them happen every week. Add it up across the team and you are losing 4 to 8 hours of someone's salary every week to work that an integration could do in milliseconds.

We worked with an ops team that had a 7am ritual. Someone on the team checked three systems, copied numbers from each into a Google Sheet, ran a formula, and posted a single line into Slack at 8am. That line told the rest of the team what to expect for the day.

The exciting AI project on their roadmap was a customer-facing chatbot. The boring one was that 7am ritual. We shipped the boring one in two weeks. The team got an extra hour every morning. The Slack message arrives at 6:55am now, before the office is even open. Six months later they still call it the most valuable thing we have built for them.

The framework we use is simple. Three questions, in order:

1. 01What is the most repetitive task someone on your team did this week, and how long did it take?
2. 02What gets blamed when it goes wrong, but never gets fixed because no one wants to be the person who fixes it?
3. 03What manual step happens between two systems that already have the data?

If you can answer those three questions in two minutes, you have just identified your boring problem. The team already knows what it is. They just have not been asked the question in a way that makes it answerable.

Boring projects do something exciting projects cannot. They build trust. The team feels the impact the next week. The operator who asked for the project sees the hours saved show up in their team's calendar. The CFO sees the cost. Word spreads.

By the time you are ready for the exciting customer-facing project, the team is already aligned, the data is already clean, the integrations are already built. The exciting project ships faster because the boring project did the unglamorous work of getting the house in order first.

Exciting problems get pilots. Boring problems get budget. We always start with the second.

If you are sitting on a list of AI initiatives and you are not sure which one to fund, sort them by how boring they are. Lead with the most boring one. Ship it in four weeks. Then ask the team what changed in their week. The answer will tell you what to build next.