Ask a team for AI ideas and you’ll get a long list fast. Most of it won’t survive contact with reality — not because the ideas are bad, but because they aren’t actually problems AI is good at.

In our experience, somewhere between 60 and 70% of the ideas on a first brainstorm list fall into that category. That’s not a criticism of the people writing the list. It’s a predictable result of how AI gets marketed: the demos that go viral are the impressive ones, not the useful ones, so that’s what people picture when they hear "AI."

The pattern we see

Teams gravitate toward the demo that looks impressive in a meeting: a chatbot that answers anything, a dashboard that "uses AI." The work that actually moves the business is quieter — a follow-up that never gets sent, a quote that takes three days, an intake step a human copies between two systems.

There’s a reason for the mismatch. The impressive demo is about AI, so it feels like progress on the AI question. The useful project is about quotes, or intake, or follow-up — the AI inside it is almost invisible. But invisible is what working looks like. Nobody at a well-run company talks about their "database strategy" either; the database just quietly makes everything work.

A simple filter

Before scoping anything, we run each idea through three questions:

  • Is there a real, repeated task behind it? Not a hypothetical — something a person does often enough to measure.
  • Is the input mostly language or judgment? That’s where today’s models earn their keep. Deterministic math and exact lookups usually don’t need AI.
  • Would a small win be obviously valuable? If the first version has to be perfect to matter, it’s the wrong first version.

Ideas that pass all three become candidates. The rest get parked — honestly, and on purpose.

Three ideas, run through the filter

Here’s how the filter plays out on the kinds of ideas we hear most often.

"A dashboard that uses AI to predict next quarter’s revenue." Fails the second question. Forecasting is mostly math over your historical data — a spreadsheet discipline problem, not a language problem. Bolting a model onto messy pipeline data doesn’t make the data less messy; it makes the messiness harder to see. If the underlying records are clean, a simple projection gets you most of the value with none of the mystery. Parked — and usually replaced with a smaller, better question: "why don’t we trust the pipeline numbers?"

"A chatbot on our website that can answer anything about our company." Fails the first and third questions at once. "Answer anything" isn’t a repeated task — it’s an unbounded surface, which means the first version has to be nearly perfect or it embarrasses you in public. There’s often a real use case hiding underneath (the same five questions arrive by email every week), but the honest version of that project is narrow, internal, and much less demo-friendly.

"Draft the first reply to inbound customer emails, using our past responses." Passes all three. The task is real and repeated — someone answers those emails every day, and you can count them. The input is language and judgment, exactly what models are good at. And a small win is obviously valuable: even if a human edits every draft, cutting response time from hours to minutes changes how customers experience you. This is the shape of a first project worth funding.

The pattern behind the pattern: ideas that pass tend to sound boring in a meeting and feel great in the second week of using them. Ideas that fail tend to sound great in a meeting and die quietly in month two.

What to do with the ideas that fail

Don’t throw them away — sort them. Some "AI ideas" are actually process problems wearing an AI costume, and naming that is worth real money. Some are good ideas waiting on a prerequisite (usually cleaner data or a decision about where records live). And some belong in the parking lot until the first win earns the trust to attempt them.

The sorting itself is most of the value — and it’s exactly what our Use Case Discovery engagement does, with your team’s list, on a whiteboard, before anyone writes a line of code.

Why this saves money

Finding the right use case is cheaper than building the wrong one well. The wrong project costs three times: the build itself, the credibility hit when it stalls, and the delay before anyone is willing to try again. The goal isn’t to say no to AI — it’s to point the effort where it pays off.

If you have a list like this — and almost everyone does — start by running it through the three questions. Then pick the most boring idea that passed and ship it in a month. That’s the subject of our 30-day playbook, and it’s usually the moment AI stops being a debate and starts being a tool.

Want a second opinion on your list? That’s a 30-minute conversation — and if the honest answer is "you don’t need AI for this," that’s the answer you’ll get.