You asked for advice—why does it sound like everyone else’s?
You paste a messy situation into a chat—launch timing, a pricing change, a customer blow-up—and the reply comes back sounding like a blog post: “clarify goals,” “align stakeholders,” “iterate.” It’s not wrong. It’s just not your problem.
That happens because your prompt often leaves room for five different interpretations, so the safest output is the most widely acceptable one. When details are missing, the model fills gaps with defaults that usually fit: common roles, typical risks, standard processes.
You can spend 20 minutes reading advice that never touches your constraints—budget, politics, data limits, or what you’ve already tried—unless you force the question to mean one thing.
What the model is optimizing for (and why that sounds like consensus)
You ask for “the best approach,” and you get something that would survive being forwarded to almost anyone. That’s not an accident. A chat model is trained to produce responses that look helpful across many situations, so when your context is thin, it leans toward answers that are broadly safe, widely repeated, and easy to agree with.
If you don’t pin down what “best” means, the model will usually optimize for low-regret guidance: avoid risky claims, stick to common playbooks, and present balanced pros and cons. For a product manager, that often means “talk to users” and “define success metrics” instead of “cut onboarding steps 3–5 because your trial activation drops at day two.” The sharper claim needs your numbers, your funnel, and your constraints.
You can push against consensus by forcing a target: ask for a recommendation “for a B2B SaaS with 6-week sales cycles and no new headcount,” then request two credible alternatives and the assumptions each depends on.
Common knowledge shows up most when the question could mean five different things
You ask, “How should we improve retention?” and the model has to guess what you mean by retention, which users you care about, and what “improve” can realistically touch. Is this a consumer app fighting week-one drop-off, or an enterprise product losing renewals because procurement drags? Those are different problems, but the prompt points to both, so you get advice that covers neither.
This is why common knowledge shows up hardest on vague verbs: “optimize,” “fix,” “grow,” “message,” “position.” Each can map to multiple jobs—diagnosis, strategy, tactics, or internal alignment—so the model chooses the broadest path. The cost is real: you’ll get a checklist when you needed a decision, and it won’t account for hard constraints like no engineering time, a frozen budget, or a legal review step that adds two weeks.
Make the question mean one thing by naming the metric, the segment, the lever you can pull, and the time window—then ask for the one highest-impact move under those limits.
Under-specification: the moment your real constraints get replaced by defaults
You ask for a plan, but you don’t say what you can’t do. The model still has to produce something, so it quietly swaps in “normal” constraints: you can run experiments, pull clean data, get stakeholder time, ship small changes weekly. That’s how you end up with recommendations that sound reasonable yet collide with your reality—like suggesting a cohort analysis when your events aren’t reliable, or “message tests” when legal needs two weeks per revision.
Under-specification shows up fastest around resources and boundaries. If you don’t state “no engineering this quarter,” you’ll get product fixes. If you don’t state “we can’t change pricing,” you’ll get pricing ideas. If you don’t say what you’ve already tried, you’ll get the same starter playbook again, because it’s the safest guess.
Make your constraints impossible to miss: list the three hard limits, the one lever you can pull, and what success looks like by a specific date. Then the model has something real to optimize for, not a generic version of your job.
How to ask for specificity without getting a longer version of the same thing
You tighten the prompt, and the model still replies with a longer checklist—just with your keywords sprinkled in. That usually means you asked for “more detail” instead of forcing a choice. If you want specificity, ask for an output that can be wrong: “Pick one recommendation, then tell me what would make it the wrong call.” It pushes the model to commit, not expand.
Give it a small set of options to compare. “We can do A (email nudges), B (in-app walkthrough), or C (sales enablement). Rank them for impact in 30 days, assuming zero engineering.” Then require it to show its assumptions in plain language: “List the 3 assumptions you’re making about our users and data; ask 5 questions that would change your answer.”
This feels slower upfront, and you may need two rounds. But you’ll stop paying in wasted reading time, and you’ll have the missing inputs for the next prompt.
When prompting won’t fix it: you need your docs, data, or live context
You can do everything “right” in a prompt and still hit a ceiling when the answer depends on facts the model doesn’t have. Ask for “the best Q2 positioning,” and it can’t see your win/loss notes, the five objections Sales hears every week, or the exact language Legal will strike. It will fill the gap with market-shaped defaults, because that’s all that fits.
This is the point where you stop refining wording and start supplying evidence. Paste the inputs you’re basing the decision on: a few call transcripts, last month’s funnel by segment, your current landing page, the roadmap constraint everyone tiptoes around. If the details live somewhere else, use a workflow that can retrieve them—internal docs, a spreadsheet export, even a small table you hand it in-chat.
Keeping docs current, redacting sensitive data, and accepting that “live context” can change mid-week. Once you have that pipeline, the model can argue with your reality instead of echoing common sense—and then you can pressure-test the recommendation before it spreads.
Before you ship the answer: a quick sanity check for ‘generic gravity’
You’re about to paste the response into a doc, a Slack thread, or a deck, and it reads smoothly—but it could have been written for any company. Do a fast check: underline every noun that should be specific (customer segment, channel, metric, constraint) and see if any are still placeholders like “users,” “conversion,” or “stakeholders.” If they are, the advice will drift toward the obvious when it hits the real world.
Then ask for two failure modes tied to your limits: “What breaks if we can’t ship for 30 days?” “What breaks if the data is wrong?” If it can’t name concrete breakpoints, don’t ship it yet—feed it one more artifact or number and rerun.
