Products
Solutions
Ecosystems
Resources
Partners
Stop Overengineering Problems You Don't Have
The most clarifying thing I've read about AI wasn't in a research paper or an analyst report. It was a comment in a Reddit thread. The gist: every problem organizations are trying to use AI to solve today could have been solved ten years ago by cleaning up their data and writing a Python script.
I've thought about that sentence in a lot of customer conversations since.
This is part of an ongoing series. Find the last post here and follow along for more.
The Chatbot Request Is Never Really About the Chatbot
Almost every one of those conversations starts the same way. Someone has a budget and a mandate. They've been told to go find a problem to solve with it. By the time they get to me, they've already decided what the answer looks like: which model, which platform, what integrations, which features.
Then they ask for a chatbot.
I've learned to treat that request as a signal rather than a specification. When I ask what the chatbot is supposed to do, what it would need to know, what decisions it would actually support, the conversation usually changes direction. What surfaces when it does is almost never a chatbot problem.
A chatbot responds to what you ask it. If you haven't worked out what you're trying to decide, the chatbot hasn't either. You get a fast, confident response to a question you hadn't fully formed, and you still don't know what to do with it. The uncertainty doesn't go anywhere; it just has a response attached to it now.
The chatbot would fail for the same reason the Python script was never written. Nobody stopped to ask what they were actually trying to do.
Three Questions Worth Asking Before You Pick Up Any Tool
The three questions I've found most useful in these conversations have nothing to do with AI. They're the questions you answer before you pick up anything.
What does your business do? Specifically, operationally, in the sense of what happens every day that produces the outcomes you exist to produce?
How does your team support that? Not in job-description terms, but in terms of what you actually produce and how it connects to those outcomes?
What do you need to know in order to do that well? Not what data exists, but what information would actually make your decisions better?
Most teams can answer the first one without much trouble. The second takes longer. The third is where things genuinely stall, and it's worth understanding why: knowing what information you need requires having already decided what you're trying to accomplish. If that hasn't been worked out, the third question stays open indefinitely, and anything built on top of it, be it a chatbot, dashboard, or AI model, is built on an open question.
These aren't hard questions to say out loud. They're hard to answer honestly, and harder still to get consistent answers to across an organization. When you can, the tool conversation changes. The chatbot request either becomes a real specification or turns into a better question.
When you can't, the AI budget gets spent on tooling that moves fast in a direction nobody fully committed to. Somewhere in the next budget cycle, somebody opens a Reddit thread and describes exactly what happened.
AI Usage Is Not AI Value
AI usage is not AI value. You need to know where you're going before you can get there. Without a destination, you're just moving in a direction and hoping no one asks if it's where you wanted to end up.
Answer the three questions in this post before the next demo, the next budget conversation, the next chatbot request. Not for your organization. For yourself.
If you want to see what it looks like when those answers are built into your data,
Frequently Asked Questions
How do you tell whether a chatbot request is the right solution or a symptom of something else?
Ask what the chatbot is supposed to help someone decide. If the answer is specific, such as this function needs to answer these questions, against this data, to make these calls faster, that's a real specification and worth building toward. If the answer is vague, or if it takes a meeting to produce, the chatbot request is a symptom. Something upstream hasn't been worked out yet, and the chatbot will inherit whatever that is.
How do I know if my AI request is worth scoping?
Start with the three questions in this post. If you can answer all three consistently, and the people around you can answer them the same way, you have enough to scope something real. If you can't get through the third one without a working group and a month of alignment meetings, the scoping conversation is premature. The prior work hasn't been done yet and doing it will either sharpen the AI request into something worth building or surface a better answer that doesn't require AI at all.
Why do most chatbot projects stall before they reach end users?
Because the tool gets built before the use case gets owned. The most experienced users can work around an imprecise question. They know enough to rephrase, probe, and interpret. End users don't have that context and shouldn't need it. When a chatbot requires users to know how to ask in order to get a useful answer, the problem isn't the prompts; it's that nobody defined what the tool was supposed to help people decide before it was built.
How do you answer the three questions if your organization doesn't have a clear strategy?
Start with what you know rather than what's been officially stated. The three questions aren't asking for a strategy document. They're asking what actually happens every day, how your work connects to it, and what you'd need to know to do it better. Those answers exist even in organizations with unclear strategy. The gap between what you know to be true and what's been formally agreed is often exactly where the AI conversation needs to start.
What does it mean to answer these questions for yourself rather than for your organization?
Most AI conversations happen at the organizational level: what does the business need, what does the team need, what does the platform need. That framing makes it easy to defer the harder question, which is personal: what are you actually trying to accomplish, and do you know that clearly enough to recognize whether a tool is helping you get there? Answering for yourself means being honest about what you're trying to do before the organizational framing gets applied. It's harder and it's faster. Organizations that get value from AI tend to have people in them who've done that work.
Juliana Schoettler
Juliana Schoettler is Senior Product Marketing Manager at Strategy. She's spent the last several years inside enterprise AI building it, breaking it, and figuring out why most of it doesn't stick. She writes weekly on the questions most organizations aren't asking yet. Follow her on LinkedIn.
Related posts
You're not data-driven. You're decision-driven. The reconciliation meeting, the AI outputs nobody trusts, the dashboards that tell three different stories: these aren't data problems. They're decisions that were never made. Strategy Software on what honest data governance actually requires.
Juliana Schoettler
June 1, 2026
New Omdia research reveals 69% of organizations say AI agent governance is a critical challenge, while 56% have already experienced governance-related incidents. Learn why traditional oversight fails for autonomous AI and what enterprises need for real-time, governed AI operations.
Beata Socha
June 1, 2026
Enterprise AI adoption is a data governance question before it is a model question. Strategy Software on what a room of CIOs got right at the IDC Summit.
Lauren O’Connor
May 20, 2026
Semantic layers for AI go beyond metadata — they enforce business logic before any model touches the data. See how Strategy Mosaic eliminates AI inconsistency and cuts LLM token costs by up to 50%.
Lauren O’Connor
May 27, 2026