When the answer sounds confident—but you still feel uneasy
You paste a question into an AI tool and get back a clean, decisive answer—bullets, steps, maybe even a recommendation. Then you hesitate. The uneasiness usually shows up when you can’t tell what the answer is built on: real facts, a reasonable guess, or a smooth rewrite of uncertainty.
This happens a lot in work settings because your question often carries hidden gaps. “Should we enter this market?” depends on budget, timing, risk tolerance, and what “success” means. If those aren’t stated, the tool still has to pick a direction, and it can sound sure even when it’s filling in blanks.
The goal isn’t to stop using AI. It’s to learn when your question doesn’t have a single knowable “right answer,” and how to force the unknowns into the open.
What kind of ‘unknown’ are you actually asking about?
Forcing the unknowns into the open starts by naming what kind of unknown you’ve handed the tool. In practice, you’re usually asking one of three things, but phrasing it like a single question.
Sometimes it’s a missing-facts unknown: “What’s our churn?” “Who owns this budget?” The answer exists, but not in the prompt, and the model may “complete” it with something that sounds plausible. Sometimes it’s an interpretation unknown: “Is this email too direct?” Reasonable people can read the same words and disagree because values and context drive the call. And sometimes it’s a future unknown: “Will this feature reduce support tickets?” That depends on adoption, edge cases, and what changes after launch.
If you can label the unknown, you can ask for the right kind of output—and avoid paying real money for a confident guess.
A quick gut-check: could two reasonable experts disagree here?
That’s the point where a fast gut-check helps: could two reasonable experts look at the same situation and land on different answers? Picture asking, “Is this a good time to raise?” One investor weighs runway and valuation multiples. Another cares more about dilution, growth rate, and your plan if the round drags. Both can be smart, both can be right, and the “best” answer depends on priorities you haven’t named.
If disagreement is plausible, treat the output as an argument, not a verdict. Ask the tool to give two opposing recommendations with the strongest case for each, then list what facts would swing the decision. This also exposes a common cost: you may need to gather data you don’t currently track (win/loss notes, sales cycle by segment, support drivers) before the advice becomes actionable.
Once you see where reasonable people diverge, the next move is to force assumptions into plain language.
Turning ‘give me the answer’ into ‘state your assumptions’
In a typical Slack thread, someone asks, “So what should we do?” and the room goes quiet because everyone realizes the answer depends on a few unstated choices. An AI tool has the opposite reflex: it will answer anyway, and it will quietly choose those missing details for you.
So change the request. Instead of “What’s the right move?” ask: “State the assumptions you need to make to answer this, then answer under each assumption.” For a pricing question, that might mean: current conversion rate, target margin, whether you’re optimizing for revenue or adoption, and whether competitors can react quickly. For a hiring question, it might mean: what work is slipping today, what the role owns, and how you’ll measure success in 60 days.
If you don’t have a clear budget range, risk limit, or timeline, the model can only offer generic plans. Ask it to list the top five unknowns that would change the recommendation, then pick one to clarify next.
If it’s future-facing, ask for scenarios—not predictions
That “top five unknowns” list matters most when the question is about what happens next. You ask, “Will churn drop if we ship this?” and the model can only lean on patterns and tidy logic. It might sound like a forecast, but it can’t see your rollout plan, your users’ habits this quarter, or the competitor who could launch a copycat feature in six weeks.
So don’t ask for a prediction. Ask for scenarios with conditions. Try: “Give me three plausible outcomes (best/base/worst). For each, list the assumptions that would make it true, early signals I can watch in the first two weeks, and the decision I should make if those signals show up.” Now the output becomes testable: adoption rate, ticket mix, activation steps that stall, and whether usage shifts to the new flow.
You may not have the instrumentation to see those signals quickly, or the team may not agree on what counts as “working.” Make the tool propose the minimum tracking and a stop/continue rule before you ship.
Before you act: small verification moves that change everything
That stop/continue rule is where a few quick checks can save you from acting on a polished guess. Before you forward the output to your team or bake it into a plan, ask for sources—or, if sources aren’t possible, ask what evidence would be needed. Then do one small reality check: open the linked docs, pull the last 30 days of metrics, or read five raw customer tickets yourself.
Make the tool earn specifics. Ask: “What would you look up first, and what result would change your recommendation?” If it claims “most companies,” force a range and an example. If it recommends a tactic, ask for the prerequisites (data access, permissions, lead time) and the quickest way to confirm each. The downside is time: even a 20-minute spot check can feel slow when a decision is urgent, but it’s often the cheapest way to catch a wrong assumption.
Once you’ve verified one or two load-bearing facts, you can decide with clearer eyes—without pretending the rest was knowable.
Making a decision anyway—without pretending it was knowable
In a real meeting, you often still have to choose—budget is due, a launch date is set, the hiring pipeline won’t pause. The mistake is acting like the remaining unknowns were resolved because the answer sounded crisp. Name what you verified, what you’re assuming, and what you’re explicitly not solving today. Put it in one sentence you can repeat: “If X stays true, we’ll do Y for 30 days, and we’ll reverse if Z shows up.”
This can feel uncomfortable because it makes risk visible, and some stakeholders will push for certainty anyway. Give them a decision log, not a debate: the trigger metrics, the check-in date, and the one thing that would force a change. Then you’re not predicting. You’re running a controlled test with a clear exit.
