The Right Way to Think About AI in Your Product (Most Teams Get This Wrong)

Every product team I talk to is either rushing to add AI features or paralyzed trying to figure out how. Both reactions are understandable. Neither produces good software.

The teams that are rushing usually end up bolting a chatbot onto an existing product and calling it AI-powered. The teams that are paralyzed usually have an honest engineering instinct — they can see that the chatbot doesn't actually help users do what they came to do — but no framework for figuring out where AI actually belongs.

Here's how we think about it.

The Wrong Framing: "We Need an AI Feature"

The conversation usually starts in the wrong place: leadership wants to be able to say the product uses AI. That's a marketing goal, not an engineering goal. When you build backwards from a marketing goal, you get features that exist to be mentioned in a press release rather than to solve a user problem.

The right question isn't "where can we add AI?" It's "where in our product does a user currently have to do something that AI is better at than humans?"

AI is not a product category. It's a capability. The question is whether that capability solves a real problem your users actually have.

What AI Is Actually Good At

Large language models are genuinely excellent at a specific set of things:

• Generating first drafts of text-based content (emails, reports, descriptions, summaries)
• Classifying and categorizing large volumes of unstructured input
• Extracting structured information from messy, freeform text
• Surfacing patterns in data that a human analyst would take much longer to find
• Translating between formats (natural language to SQL, text to structured JSON, etc.)
• Answering questions against a specific knowledge base (when retrieval is done right)

If your product has users doing any of these things manually at scale, that's where AI belongs.

What AI Is Terrible At

This list is shorter but more important, because it's where teams get into trouble:

• Making high-stakes decisions that require accountability (who's responsible when the AI is wrong?)
• Maintaining factual accuracy without hallucination in domains where errors are costly
• Exercising judgment in genuinely ambiguous situations where context matters deeply
• Replacing the human relationship in high-trust, high-sensitivity interactions

The accountability problem is the most underestimated one. If an AI system makes a wrong call in your product, who is responsible? If the answer isn't clear, that's a sign you're using AI in a place where it shouldn't be making autonomous decisions.

The Integration Question: Where Does It Belong?

The best AI integrations are ones that remove friction from something a user already wants to do — not ones that create a new interaction pattern the user has to learn. Think of AI as a capable assistant that works in the background of your existing workflow, not a new feature that demands the user's attention.

In OpsFlow, we've explored using AI to: automatically categorize incoming maintenance requests by type and urgency, generate work order descriptions from a few keywords, and surface patterns in maintenance history that predict equipment failures. In every case, the AI output is a suggestion that a human confirms — not an autonomous action.

The Test

Before building any AI feature, ask: would this be valuable without AI? If the answer is yes — if the feature is genuinely useful and AI just makes it faster or easier — build it. If the answer is no — if the only reason the feature exists is because it uses AI — don't build it.

The features that survive this test are the ones worth shipping.