Widespread use, uneven safeguards
Two 2025 surveys provide context for that advice, though each covered a specific sample. General Assembly surveyed 117 product managers in the United States, United Kingdom, Canada and Singapore from October 2 to 13, 2025. The findings, published November 6, showed that 98% used AI at work, averaging 11 uses a day, and 78% already used AI agents. Unapproved tools, often called "shadow AI," were used by 66%, while just 39% reported receiving comprehensive AI training tailored to their jobs.
Productboard and research firm UserEvidence surveyed 379 product professionals at organizations with at least 500 employees. In results published October 22, 2025, all respondents reported using AI tools, 96% used them consistently and 88% used at least two different AI models. Only 65% said their employer had a documented AI policy.
Adoption also extends to engineering. GitHub reported on September 22, 2025, that Copilot had more than 20 million users across 77,000 enterprises. Gartner predicts that AI code assistants will be used by 90% of enterprise software engineers by 2028, compared with less than 14% in early 2024.
Define the assignment before generating the draft
The guide treats Copilot as a junior analyst that needs a clear assignment, not as a substitute for product judgment. A broad request to summarize feedback or create user stories can produce generic proposals that overlook engineering limits. Unless supplied with the relevant context, the model lacks knowledge of the team's codebase, quarterly objectives and legacy technical debt. It may invent customer motivations or recommend work that does not fit the roadmap.
For interview synthesis, the guide proposes assigning the role of senior product manager and asking for three principal customer pain points with corresponding feature requirements. The prompt should restrict the analysis to the supplied notes, prohibit unsupported assumptions and request a bulleted output with Impact, Frequency and Suggested Requirement fields. The raw notes then provide the evidence for the task.
The same approach applies across discovery, backlog refinement and stakeholder communication, but the requested output should change with the assignment. Structured backlog practices, such as those used in Azure DevOps, help keep work traceable and clearly scoped; targeted prompts can help connect product intent to engineering tasks.
Discovery and requirements: keep the evidence attached
The guide's ten examples use hypothetical scenarios rather than reported product outcomes. The first asks Copilot to act as a UX researcher and identify three mobile-checkout friction points, each supported by an exact transcript quote and a frequency indicator. The sample notes concern slow payment screens and confusing errors. Reviewers must compare the quotations with the transcript and check that the draft has not exaggerated customer sentiment.
A second example converts a verified problem, such as customers abandoning checkout after silent address-validation failures, into an Agile user story with four explicit acceptance criteria. The review must cover both successful interactions and error handling, rather than accepting criteria that describe only the happy path.
A third asks for three security gaps in password-reset criteria that currently cover entering an email address, receiving a link and choosing a new password. The expected issues are expired tokens, request rate limiting and termination of concurrent sessions. These suggestions still need to be checked against the team's security policies and authentication standards.
Planning: proposed priorities are not final decisions
For bug triage, the example asks Copilot to assign severity levels from P1 through P4 using reported impact and frequency. The hypothetical reports include tablet buttons being clipped and an app crashing at startup on iOS 17. Although the expected draft puts crashes in P1 and cosmetic problems in P4, a reviewer must reassess those assignments using actual usage metrics and business impact.
For sprint planning, another prompt combines five committed backlog items into one value-focused sentence. The sample work includes a login redesign, a password-reset fix and a session-timeout adjustment, suggesting a goal centered on a more secure, streamlined authentication experience. The check is whether that goal represents the selected work's main theme.
A retrospective example asks the model to organize 20 sticky notes into three themes and propose one team experiment for each. Notes about unclear acceptance criteria, late QA testing and excessive meetings are grouped under Process, Communication and Planning. The engineering team should assess whether the proposed experiments are practical and useful.
Communication: preserve constraints and business risks
An executive-summary exercise reduces a hypothetical five-page product requirements document about mobile offline sync to three sentences addressing user value and estimated development scope. The result should explain the problem, proposed solution and main trade-off without dropping technical constraints or overstating how quickly the team can deliver.
For release notes, the guide asks Copilot to turn engineering commit logs into two concise, customer-facing points. Its hypothetical logs mention authentication-service refactoring and database-indexing improvements; the expected benefits are faster login and more stable sessions. Review focuses on removing internal jargon and making the customer benefit understandable.
A stakeholder FAQ exercise requests five difficult questions and neutral answers about moving enterprise customers from monthly subscriptions to usage-based billing. Revenue predictability, migration effort and churn risk belong in the discussion. Reviewers should reject answers that obscure those risks with optimistic language.
The final communication example is an API deprecation email directing developers to move from v1 to v2 within 90 days. It should include the deadline, migration guidance and a support contact. Before sending it, the product manager must confirm that the schedule matches engineering commitments and that the support link works.
Match the method to the task
The guide distinguishes between quick, ad-hoc requests, reusable templates and fine-tuned domain models. Ad-hoc prompting can serve as a low-risk starting point for a short email or single user story when manual checking is quick. Its weaknesses are inconsistent results, missing context and possible hallucinations.
For recurring work such as interview analysis and requirements summaries, the guide favors structured templates. They take effort to design and maintain, but provide a more consistent output format for daily workflows. Fine-tuned domain models are presented as an option for large organizations with strict compliance requirements, historical-data needs and dedicated machine-learning engineering support. Their costs include complex maintenance and potential data-privacy overhead.
Review the evidence, not just the wording
A well-formed prompt does not eliminate fabricated metrics, mistaken interpretations of urgency or overlooked architectural limits. The guide calls for treating generated documents as drafts and checking whether synthesis has erased minority feedback or missed an edge case involving a serious security flaw. Requirements should remain traceable to the underlying notes and documents.
OpenAI research published September 5, 2025, argues that standard training and evaluation methods encourage hallucinations by rewarding guesses over admissions of uncertainty. On SimpleQA, gpt-5-thinking-mini declined to give a specific answer 52% of the time and had a 26% error rate. OpenAI o4-mini had a 1% abstention rate and a 75% error rate.
The guide's final review covers four responsibilities: supply relevant background, target-user definitions and explicit constraints; compare generated insights, stories and acceptance criteria with the original evidence; check technical limits, security rules and team capacity; and obtain an experienced product manager's approval before sharing deliverables with engineers or executive stakeholders.
