How to deal with AI slop generated by colleagues (if you're a product manager)
Polished AI drafts need human ownership: PMs must enforce checklists, review gates, and line-by-line reasoning before work starts.
Here’s the short answer: if a document will change roadmap, scope, budget, or build work, I treat it as unfinished until a person can explain the facts, assumptions, risks, and trade-offs behind it.
AI slop is usually easy to spot once I stop looking at polish and start looking at proof. The main point is this: AI is not the problem; unchecked output is. And for PMs, that often means more rework, more meetings, and more cleanup.
What you will take away from this article:
- Polished does not mean ready
- Generic language is a warning sign
- Missing sources, non-goals, and edge cases are common tells
- Research that feels too neat may be hiding conflict
- PRDs, specs, and exec updates need stricter review
- Feedback should focus on the draft, not the person
- Every work-starting doc needs one human owner
- A simple pass/fail checklist can stop weak docs from spreading
In this article, I'm spearating useful AI help from AI slop based on one test: did a human do the thinking? It also points out where PMs feel the hit first - PRDs, research summaries, roadmaps, and status updates. In those cases, one weak draft can waste days of engineering time or send a team into the wrong discussion.
I like the review model because it is based on risk, not on whether AI was used at all. Notes may need a light scan. But docs tied to leadership calls, shipping work, pricing, legal, or safety need a much harder manual check.
AI drafts can save time, but only if someone owns the output. If no one can defend the logic line by line, the document is not done.
How a Marketing Leader Ended AI Slop With One Document
How to Spot Low-Quality AI Output Before It Spreads
Now that the line between useful AI and slop is clear, use these checks on the documents that land on your desk. PMs should screen for work that looks finished but shows no product judgment underneath. The point isn't to figure out whether AI touched it. The point is to see whether a person actually did the thinking.
AI-Assisted Work vs. AI Slop: A Side-by-Side Comparison
Use this table to judge how much trust a document deserves before it gets in front of engineering, leadership, or customers.
Feature | Useful AI-Assisted Work | AI Slop |
|---|---|---|
Product Context | Grounded in specific OKRs, user segments, and current constraints | Generic observations that could apply to any product or industry |
Evidence | Includes outlier quotes and contradictory signals from raw data | Smooths over inconvenient data to create a clean but false narrative |
Reasoning | Flags trade-offs, confidence gaps, and explicit non-goals | Presents a linear path with no risks, tensions, or open questions |
Requirements | Testable acceptance criteria tied to real outcomes | Vague feature lists without measurable impact |
Specificity | Human-refined; adds organizational context, named constraints, and traceable decisions | Looks polished but lacks depth or traceability |
Ownership | PM owns the final call and explains the trade-offs | PM acts as a pass-through without review |
One warning sign deserves extra attention: smoothing over contradictions. AI models often flatten inconvenient or conflicting data points. But that's usually where the best product insight lives. If a research summary feels a little too neat, go back to the raw data.
Red Flags in PRDs, Specs, Research Summaries, and Updates
Weak output usually shows up in the same patterns, no matter the document type. In PRDs and specs, watch for goals that could fit almost any product, customer claims with no source, feature lists with no defined outcomes, and acceptance criteria that can't be tested. Missing non-goals and unresolved questions are another giveaway. AI loves to fill empty space, so a document that looks complete may just be faking certainty where none exists.
Research summaries have their own tell. Real user research is messy. People disagree. Signals clash. If every theme points in one clean direction, someone - or something - may have sanded off the rough edges. In stakeholder updates, pay attention to busy-sounding language like "we completed", "we shipped", and "we aligned" when there's no mention of actual risks, choices made, or business impact. That's often a sign of weak automated synthesis.
"AI cannot set strategy for you. You still decide what to build, why to build it, and when. Its role is to save you time and hassle in the process." - Julie Price, Senior Director of PM/UX, Aha!
How to Apply a Risk-Based Review Standard
Not every document needs the same level of review. The right standard depends on what happens next and how much it could cost the team if the document is wrong.
Document Type | Review Depth | Focus Area |
|---|---|---|
Brainstorming / Notes | Light scan | Diversity of ideas, creative range |
Research Summaries | Moderate check | Cross-reference AI themes against raw customer quotes |
PRDs / Build Specs | Deep logic check | Edge cases, non-goals, testable criteria, technical constraints |
Executive Updates | Deep fact check | Strategic alignment, OKR mapping, risk framing |
Pricing / Legal / Safety | Mandatory manual gate | Compliance, revenue risk, ethical guardrails |
Anything that kicks off engineering work or shapes leadership decisions should get the toughest review. For everything else, a fast read for specificity and evidence is often enough.
A simple test helps: did a person make real decisions here, or did AI just pad the page?
Once you can spot the pattern, the next move is knowing how to push back without hurting trust.
How to Challenge the Work Without Damaging Trust
Push back on weak work by testing the logic, evidence, and choices in the document, not the tool or the person behind it. That keeps weak drafts from drifting downstream and turning into bigger problems later.
A good review sounds concrete. It asks: Where are the sources? What are the non-goals? What happens if this assumption is wrong? If a draft is missing evidence, labeled assumptions, or open questions, send it back for revision. The goal isn't to make feedback softer. It's to make it useful.
Give Feedback on the Output, Not the Person or the Tool
For PRDs, research, and strategy docs, use language that asks for evidence and trade-offs.
Feedback Focus | Instead of saying... | Try asking... |
|---|---|---|
Logic | "This looks like AI slop." | "What are the failure modes or non-goals for this feature?" |
Evidence | "Did you actually read the data?" | "Can we label the assumptions here and link them to the raw interview transcripts?" |
Ownership | "You're over-relying on AI." | "Which parts are final decisions, and which are early AI drafts?" |
Rubric fit | "This is too generic." | "How does this draft align with our PRD quality standard?" |
One script is worth keeping close for research and strategy docs: "Assume this feature failed after 3 months - what went wrong?" That pre-mortem framing pushes the author past surface-level optimism and into delivery risk, trade-offs, and weak spots that need work.
If the same gaps keep showing up, one-off feedback isn't enough. At that point, the issue isn't just the draft. It's the system around the draft.
Short Feedback Scripts That Lower Defensiveness
A single weak draft is a coaching moment. A repeated pattern of missing sources, unlabeled assumptions, or unresolved questions is a team problem.
Shared standards should spell out what review-ready means before a document starts circulating. A simple checklist can do the job:
- Labeled assumptions
- Links to raw inputs
- Explicit non-goals
- A named human owner
That last part matters. Every work-starting document should have a person attached to it who can explain the reasoning and stand behind the calls being made.
From there, turn the standard into a checklist and review gate.
"Governance turns AI output into a reviewable team standard." - Product Management Society Member
How to Fix AI Slop Fast: Checklists, Quality Gates, and Team Standards
Review Checklists and Pass/Fail Quality Gates
If a document will shape work, it needs a hard gate before it reaches Engineering or leadership.
Loose checks like “Does this look done?” sound fine, but they miss the stuff that later blows up. They depend too much on gut feel. A pass/fail gate works better because it forces the basics into the open: the item is either there and can be checked, or the document stops.
Before any work-starting document goes out, it should clear these checks:
- Problem statement: Is the main problem tied to user evidence, or is it coming only from an AI summary?
- Target users: Are the user segments named, or is the audience described in broad, generic terms?
- Dated evidence: Does the document link to raw, dated customer quotes or data, instead of polished summaries?
- Assumptions vs. facts: Are AI-generated assumptions clearly labeled and kept separate from verified information?
- Goals and non-goals: Does the document say what the feature will not do?
- Constraints and risks: Are technical, legal, and privacy risks covered?
- Edge cases: Does it include failure modes and “what if this breaks” scenarios?
- Named owner: Is one specific person accountable for the document’s accuracy?
A missing non-goals section or an unlabeled assumption isn’t some small oversight. It’s the kind of gap that turns into a bad call later. A document can look polished and still send a broken assumption straight into Engineering.
Prompting Standards and Document Ownership
Better gates usually start with better prompts.
AI-assisted drafts are only as good as what the writer gives the model. A strong prompt should include the audience - who will read the document and act on it. It should also spell out the purpose, meaning the decision the document is meant to support.
Then comes the part many teams skip: customer context. That means real quotes, ticket data, or interview notes. Not vague summaries. Not a cleaned-up description that sounds nice but loses the edge of what customers said.
It also helps to include exclusions - what the AI should leave out - and a direct instruction to flag uncertainty whenever it is making an assumption instead of pulling from the source material.
That last part matters a lot. If the model is told to show its gaps, those gaps become visible. If not, they tend to disappear into smooth, confident prose.
Every work-starting document also needs a named human owner. That person should be able to explain the reasoning, defend the trade-offs, and fix the document if something is off. AI can draft. It cannot own.
How to Repair Weak Documents That Already Circulated
If a weak draft is already out in the wild, fix it in place before it shapes decisions.
- Pause distribution: Stop forwarding the document while the repair is in progress.
- Restate the decision, then label facts vs. assumptions line by line: Remove anything that is neither.
- Strip filler: Delete generic summaries, vague benefit statements, and any sentence that sounds polished but says nothing specific.
- Add missing constraints and risks: Manually put back the technical or business constraints the draft left out.
- Run a focused cross-functional review: Do a quick sync with Engineering and Design to spot logic gaps.
The point is simple: the document should make clear what is known, what is assumed, and who owns the call.
Conclusion: The Standard Is Human Ownership, Not AI Avoidance
The goal isn't to avoid AI. The goal is to make sure a human reviews AI output before anyone treats it as finished.
That means stopping weak work before it spreads. It also means assigning one named owner who can explain it, stand behind it, and fix it when needed.
In day-to-day work, that comes down to a few plain review rules the whole team follows. Use the checklist. Set prompt standards. Fix weak drafts where they are instead of letting them drift. And when the same problems keep showing up, turn them into a team rule everyone understands.
"AI makes production cheap and judgment more valuable, so the edge shifts from PMs who were fast at output to PMs who decide what is worth producing." - Arnould Joseph, Product Marketing Manager
What Stronger AI Norms Should Look Like Going Forward
The working rule is simple: AI drafts, humans decide. People still need to verify claims, surface assumptions, own trade-offs, and protect product decisions from polished but weak output.
That doesn't mean every AI-assisted document should be treated with suspicion. It means no AI-assisted document should become a final reference until a human owner signs off on it. A polished doc can still be wrong. Review is the step that catches that.
"AI cannot set strategy for you. You still decide what to build, why to build it, and when. Its role is to save you time and hassle in the process." - Julie Price, Senior Director of PM/UX, Aha!
That's the PM standard now. The job hasn't changed. Weak output just moves through teams faster than it used to. So the bar stays simple: clear ownership, checked facts, visible assumptions, and one accountable human.
FAQs
How can I tell if a polished doc is actually unfinished?
A polished document can still be unfinished. If it leans on generic framing, skips key constraints, or uses polished business language to cover thin reasoning, don’t treat it like the final word. Treat it like a proposal.
Pressure-test it. Push on the weak spots. Ask where the logic breaks, which assumptions are doing too much work, and what’s missing from the picture. That kind of stress test tends to show whether the document has substance or just a smooth surface.
Then run it through your quality rubric. If it doesn’t spell out clear boundaries, target users, or the context it depends on, there’s a good chance you’re looking at polished nonsense.
What should I say when I think a coworker shared AI slop?
Focus on the work, not the tool. That’s how you avoid chipping away at trust.
A better approach is to treat the output like a draft, not a finished piece. Read it with a critical eye, refine what’s there, and ask questions that pressure-test the thinking behind it.
A few simple prompts can help:
- Where could this fail?
- What assumptions is this making?
- What is missing?
- What would someone on the other side argue?
That kind of feedback keeps the conversation collaborative instead of accusatory. It shifts the tone from blame to problem-solving, which usually leads to better work and better judgment.
Which AI-assisted docs need the strictest review?
AI-assisted docs need the strictest human review when they deal with high-risk areas, ethical guardrails, or critical business decisions.
Use strict approval gates for pricing changes, legal disclosures, and account deletion flows. The same goes for any doc that shapes final decisions, such as success metrics, strategic constraints, or roadmap trade-offs.
The rule is simple: treat AI output as a draft, not the final word. Check it for hallucinations, shaky reasoning, and missing context before it goes anywhere important.
If you’re finding this blog valuable, consider sharing it with friends, or subscribing if you aren’t already. Also, consider coming to one of our Meetups and following us on LinkedIn ✨ And check out our official website.
Connect with the founder on LinkedIn. 🚀
About the Product Management Society
The Product Management Society is an international community for product managers, founders, designers, and career-switchers, with 2,400+ members across active chapters in Lisbon, Berlin, Frankfurt, and Mexico City. The community runs more than 50 in-person meetups per year, a Slack network, an invite-only WhatsApp group, a blog, and a growing suite of free tools for product leaders. More information is available at www.productmanagementsociety.com.
About Gabriela Naumnik
Gabriela Naumnik is an AI product leader and the founder of the Product Management Society. A Staff Product Manager working at the intersection of AI and enterprise product, she focuses on AI-powered platforms serving Fortune 500 companies. She is a regular speaker at product conferences, publishes on product management at the Product Management Society's blog, and has built the PM Society into one of the most influential product communities in Europe and Latin America. She holds a B.S. from NYU/NYU Shanghai and an M.S. from Columbia University. More information is available at gabriela-naumnik.com.
