Why Does AI Keep Getting It Wrong? It's Not Dumb — You Didn't Say It Clearly

Let me start with a scene you’ve almost certainly lived through.

You ask AI to build something, wait eagerly for it to deliver, and what comes back is a universe away from what you had in mind. You fix one line, it breaks another, back and forth a few rounds, until you finally get fed up and mutter to yourself: “This AI is nothing special.”

These past few months I’ve been using AI to get work done nearly every day, and I’ve fallen into this pit every day too. But after enough of it, I changed my mind. Because I noticed a pattern that stings a little: the same requirement, phrased a different way, and it gets it right the first time.

Once or twice is a coincidence. Eight or nine times is not. Slowly I had to admit something: when AI gets it wrong, most of the time it isn’t dumb — I didn’t say it clearly.

This isn’t mysticism. Underneath it is a very plain truth, plain to the point of being a little cruel:

AI can’t read minds. It only does what you “said,” not what you “meant.”

The requirement in your head is three-dimensional — it has context, it has default assumptions you’re not even aware of, it has a whole set of “well, obviously” common sense. But the sentence you type into the chat box is often just a thin outer layer of skin. That layer of skin is all AI gets; the rest it has to guess. Guess right and you got lucky; guess wrong and you go and call it stupid.

Once I understood this, I stopped fussing over “which AI is smarter” and turned to practicing something far more valuable: how to move that three-dimensional requirement in my head, complete, into the chat box. This piece is that whole method. All of it is copy-pasteable — not one line of it is some talent-only secret technique.

And I have to say, this is fantastic news for product managers. Describing requirements has always been a PM’s bread and butter. You used to explain the requirement to engineers; now you explain it to AI — the only difference is that engineers use experience to fill in what you left out, and they come back to ask you, while AI is more obedient and more “literal,” doing exactly as much as you say. So with AI, you have to say it a little more clearly than you would to an engineer. That little bit is the threshold, and it’s the dividing line.

A requirement that lets AI get it right the first time has five parts

I pulled apart the requirements I’d “said clearly” and found they always had five things in place. Leave one out, and that’s exactly where AI decides for me.

You don’t have to write all five every time and turn it into a formula. But you need those five slots in your head — before you hit send, scan them: whichever slot is empty, that’s where AI will improvise.

Part one: what you want — nail the noun first

The most basic, and the easiest to skate past.

You say “help me build a user-management thing” — what is this “thing”? A page? A table? A whole back office? AI can only pick one and guess.

Change it to: “Build a user list page, one table, showing avatar, name, email, sign-up date, and status.” — now it knows exactly where to start.

The whole trick is one line: swap vague words like “thing,” “feature,” “module” for concrete nouns. Page, table, button, form, chart, modal. Once you can say what it actually is, AI can catch it.

Part two: for whom, and why — the part most often skipped, and the most valuable

This is the part people from a technical background tend to skip, and it happens to be the PM’s home turf — you’re wired to care about “who uses it and why.”

Compare. You say “build a dashboard, put all kinds of data on it,” and it hands you a screen full of charts you probably won’t even look at.

Change it to: “Build a dashboard for the store manager to check every morning. What he cares about most is how much sold yesterday, up or down versus the day before, and which category sells best — put those three front and center, everything else secondary.”

See the difference? Add “who uses it + what they care about most,” and AI knows what to emphasize and what to dial down — it starts having “priorities,” instead of laying all the information out flat on the floor.

I’ve basically made it a habit now: after every requirement, I tack on one line about “who this is for, and what problem they’re trying to solve.” That one line is often worth more than everything I said before it combined.

Part three: the concrete form — say what it “looks like”

The idea has a picture to it in your head, but all you tossed out was an abstract word.

“Build a filter feature” — AI doesn’t know what you want to filter by or how.

“Above the table, add a row of filters: a date-range picker, a ‘status’ dropdown (All / Active / Disabled), and a search box (search by name or email); filtering is instant — it refreshes the moment you pick, no confirm button.” — now it can reproduce it one-to-one.

You don’t need to know design. You just need to describe the picture in your head in plain words: which blocks there are, what each one is, where it goes, how it’s used. Describe it and it can reproduce it; can’t describe it, and that means you haven’t thought it through yourself — which is perfect, because that’s a signal, and later I’ll cover how to use it to think things through in reverse.

Part four: the boundaries — the dividing line between “looks like it runs” and “actually works”

I need to spend a little longer on this one, because it’s the real difference between a beginner and a PM.

Beginners describe only the “normal case”: the user fills it in obediently, the data is all clean, the network never drops. But in the real world, users type nonsense, data comes back empty, the network cuts out, inputs run too long. These are the “edge cases,” and they’re what a PM should worry about most — and what you most need to spell out for AI.

You say “build a feedback form with name, email, content, and a submit button,” and it hands you the happy path and calls it done.

If instead you say this:

“…watch out for these cases: when the email format is wrong, show a red hint under the field and don’t let it submit; when the content is empty, the submit button stays disabled; on success, clear the form and show ‘Thanks for the feedback’; on failure (say, no network), don’t clear what the user already typed — show ‘Submission failed, please try again.’”

Those few extra lines are the PM’s professionalism. AI is fully capable of handling all of this, but if you don’t say it, it defaults to just the “happy path.” List the boundaries, and it builds them all in the first time.

By the way, “what counts as done” and “what not to build” are boundaries too, and just as worth saying. A single line — “this version does only the list and the filters, no create/edit/delete yet” — blocks a whole pile of things you didn’t want this round.

Part five: a reference — hand it a ruler

Style, colors, feel — these “vibe” things are the hardest to pin down in words. The easiest move: give it a reference.

“Make the colors nice, make it look professional” — a hundred people have a hundred readings of “nice” and “professional.”

“Use brand blue #3B82F6 as the primary color; for the overall palette and whitespace, follow the clean, restrained style of the Stripe website.” — now it has a ruler and doesn’t have to guess at the “nice” in your head.

A reference can be a color value, a product you like (“like Notion”), a standard. Give it a reference, and AI doesn’t have to bet on your taste.

Five most common ways of “not saying it clearly,” and how to fix each

The above was the constructive breakdown. Below are the five pits I see most, and fall into most myself — go down them one by one as a checklist.

Pit one: too vague. “Build a nice-looking page” — it hands you something mediocre and you can’t even say what’s wrong. Fix: push it one level more concrete, swap adjectives for nouns and details.

Pit two: giving orders with no context. “Add an export feature” — export what? Export to where? What format? Add it where? Fix: fill in “where + what to export + what format,” e.g. “on the reports page, add an ‘Export’ button top-right; clicking it exports the table under the current filters as a CSV download.”

Pit three: dumping a whole pile at once. Cram fifteen requirements into one message, and what comes back is a mess you don’t even know where to start fixing. Fix: small steps, fast — one at a time. First put up the skeleton, run it, see the result, then add on one by one. This is the most important of them all, no contest.

Pit four: no reference, leaving it to guess your taste. Fix: see part five — give a color value, a reference product, a standard.

Pit five: only saying the normal case, not the abnormal. The demo runs smooth, then real users touch it and everything breaks. Fix: before you send the requirement, ask yourself three questions — what happens if the data is empty? what happens if the user types nonsense? what happens if the network drops? Write the answers into the requirement.

Three moves: turning AI from a hand into a brain

Get the above down and you’re already ahead of most people. The three moves below are what I use to turn AI from “an obedient pair of hands” into “a brain that helps me think.”

Move one: have it ask you questions first, don’t rush it into building. This is the one I use most, and the most counterintuitive: the more important the requirement, the less you should have it build right away — have it question you first.

“I have an idea: build a tool to collect and analyze customer feedback. Don’t start yet — first ask me the five most critical questions, and pin down the target user, the core use, the must-have features, and the boundaries.”

The questions it asks are, nine times out of ten, exactly the spots you haven’t thought through yourself. The process of answering is the process of forcing the requirement from “a fuzzy blob” into “a clear line.” By the time you’re done answering, it’s holding a complete requirement, so of course what it builds is right. The essence of this move is using AI to help you think clearly, not just to help you build — think it through, and getting it right comes for free.

Move two: give a good example and a bad one. When words fall short, an example is fastest — especially “I want this kind, not that kind.”

“Help me write the message that shows after this button is clicked. Make it like this: short, casual, reassuring — ‘Saved, you’re good.’ Not like this: stiff, wordy — ‘Your operation has been successfully submitted to the server and persisted to storage.’”

One good example plus one bad one beats three lines of adjectives.

Move three: have it restate to confirm, then build. When the requirement is complex, have it restate its understanding first, and only build once you’ve confirmed it’s right.

“The requirement I just gave you — don’t build it yet. Confirm it back to me in three sentences: what you’re about to build, how many parts, and anything you’re unsure about. Once I confirm, then start.”

Thirty seconds here saves you half an hour of rework. As it restates, you’ll often catch on the spot that “wait, what I said here isn’t what I meant” — fix it right then, before it’s touched anything.

One full run-through: from a fuzzy sentence to it getting it right the first time

Let’s string the above together and watch a real run. Say all I have in my head is one fuzzy sentence: “I want a thing that lets me look at user feedback.”

Step one, I don’t rush it into building — I have it help me think first (move one): I have it ask me five key questions. It asks: who uses it (my ops colleague)? where does the feedback come from (a CSV file)? what do I most want to get out of it (quickly see what everyone complains about most)? do I want it sorted by severity (yes)? do we need filters this version (not yet)?

Step two, fold the answers into one complete requirement, and the five parts line up perfectly: for ops to look at, the goal being to quickly see what users complain about most (for whom, why); an upload area up top to load the CSV, and below it auto-display the feedback grouped by theme, how many items per theme, the share of each, sorted by count (what, form); when the CSV is empty or the format is wrong, show “Read failed, please check the format,” and no filters or search this version (boundaries); clean and restrained, primary color #3B82F6, layout following Notion (reference). Build it out with fake data first, and spin up a local server so I can preview.

Step three, run it, see the result, then add in small steps (the fix for pit three): one at a time — “add a progress bar after each theme to show the share,” “clicking a theme expands to show three raw feedback items in that category,” “color themes by severity — red for high frequency, yellow for medium, gray for low.”

Step four, have it find the problems itself: “click through everything clickable, find the errors, hangs, and anything not behaving as expected, and give me a list.”

The whole way through I didn’t write a single line of code, but every step I said clearly. This is the daily reality now — you’re in charge of thinking it through and saying it clearly, it’s in charge of building it.

Finally

Before I hit enter, I usually spend ten seconds running these slots through my head: what I want (is it a concrete noun?), for whom and why, what it looks like, boundaries (empty data, garbage input, failure, what not to build — did I cover them?), reference, and — is this just one requirement this time. Get four or five of the six, and it basically gets it right the first time.

More and more people know how to use AI, but the people who can say the requirement clearly have always been the minority. The first thing is a threshold — everyone can cross it; the second is a dividing line — it splits people into two camps.

And you, as a product manager, already understand users best, understand priorities best, understand the very boundaries no one else will worry about for you. What you’ve been missing was never those things — it’s the habit of saying them out loud. Practice for a month, and you’ll find it’s not that AI got smarter — it’s that you finally learned how to hand over that requirement in your head, complete.