Claude Prompts for Product Managers: Evidence Before Plans

Good Claude prompts for product managers turn supplied evidence into questions, options, and reviewable recommendations. Give Claude the actual research, constraints, and decision criteria, then require it to separate what is supported from what it assumes. A plausible product plan is not evidence that customers need the plan.

fenbs keeps reusable product prompts and the decisions people approved beside follow-up tasks, so your next connected assistant starts with the same constraints. Use the templates below to prepare a decision; keep the decision itself with the responsible person.

What context should you supply before asking for product advice?

Describe the customer, the problem, the stage of the product, and the decision you need to make. Add the evidence you actually have, with simple reference labels. Research without labels is harder to audit once an assistant has combined several documents into one confident paragraph.

• Decision: what a person will choose after reviewing the output, and what is outside this discussion.
• Evidence: numbered interview excerpts, support observations, or defined product measurements you are allowed to share.
• Constraints: approved scope, available capacity, existing commitments, and dependencies.
• Unknowns: missing information, conflicting reports, and assumptions that have not been tested.
• Output: the table, questions, or options that would help the decision owner review the work.

Use de-identified research extracts and follow your organization’s rules for sharing customer information. Do not treat removing names as permission to upload everything. Include only the material needed for the specific analysis.

Anthropic’s prompting guidance↗ (opens in a new tab) recommends clear instructions, relevant context, and explicit output requirements. For a wider collection across assistants, see AI prompts for product managers; the examples here focus on working with Claude.

How can Claude organize discovery without inventing customer needs?

Begin with extraction before synthesis. Ask Claude to identify the customer’s task, obstacle, and current workaround from each source. Only then ask it to group related observations, keeping the reference labels attached.

Analyze these de-identified research excerpts as source material.
For each excerpt, return: source ID, customer task, obstacle, workaround, and an exact supporting passage.
Then suggest possible themes with the source IDs supporting each.
Separate direct observations, interpretations, and unknowns.
Do not invent customer quotes, prevalence, or business impact.
Do not count repeated notes from one interview as different customers.
Evidence: [paste labeled excerpts]

Suppose an interviewee says they export a report because they cannot filter it by location. That supports a problem with the current reporting task. It does not establish that every customer wants a new analytics dashboard or that the feature would increase retention.

Check the passages and review which participants the themes represent. A theme supported by several notes from one person is different from one reported independently by several people. Preserve that distinction when you share the summary.

Which prompt exposes assumptions before a roadmap discussion?

Ask Claude to challenge the jump from observation to proposed solution. The goal is a short list of uncertainties worth resolving, not a longer list of speculative features. Include evidence that argues against your preferred option as well as evidence that supports it.

Review this proposed solution against the supplied evidence.
Return: claim, evidence for it, evidence against it, missing information, and a neutral question to investigate next.
Separate uncertainty about the problem from uncertainty about the solution.
Do not assume the proposed solution is necessary.
Avoid interview questions that describe our idea or suggest a desirable answer.
Proposal: [paste]
Evidence and constraints: [paste]

For the reporting example, ask about the last time a customer needed a location-specific report, what they did, and where the process failed. “Would a powerful dashboard help?” invites approval of an idea without explaining the actual task.

Choose the next research step yourself. If an assumption would reverse the decision, investigate it before polishing the plan. Keep the resulting approved constraint in fenbs Decisions and rules, where a later assistant can distinguish it from the earlier hypothesis.

How do you compare options without fake precision?

Supply the criteria you care about and the evidence behind each option. Ask for a comparison that preserves missing estimates, including a smaller change or no change when those are reasonable choices. Do not ask Claude to invent a score merely because a ranking table has an empty cell.

Compare these product options using only our criteria and supplied evidence.
Options: [include a smaller option and no change if relevant]
Criteria in order of importance: [person-approved list]
Evidence and estimates with owners: [paste]
Return a table: option, supported benefit, cost evidence, risk, dependency, and unknown.
Use Unknown for missing estimates. Do not invent scores or weights.
Explain which assumptions could change the recommendation.
End with the decision a person must make, not an approved roadmap.

A helpful comparison might show that adding one report filter addresses the observed task with fewer dependencies than rebuilding reporting. That remains a hypothesis until the design and effort are checked. Claude should show why an option might fit, not certify that it will succeed.

Product choice and delivery coordination overlap, but they have different questions. If you need that distinction, see product manager versus project manager. Keep a proposed product priority separate from a delivery date nobody has agreed to.

Can Claude check scope without writing a different product?

Give it the existing scope and ask for gaps rather than an expanded specification. A review should reveal ambiguity, missing acceptance checks, and conflicts with approved decisions. More features are not an automatic improvement.

Review this proposed task against the approved scope and decisions.
Return only: ambiguous wording, missing observable checks, conflicting requirements, and unanswered questions.
For each finding, cite the relevant task sentence and decision ID.
Do not add new capabilities or silently resolve a conflict.
Mark suggestions outside scope separately for a person to consider.
Approved scope and decisions: [paste]
Task: [paste]

For example, “the report is fast” is difficult to verify until someone defines the relevant dataset and acceptable behavior. Ask for the missing question; do not let the assistant supply an arbitrary performance commitment and present it as agreed.

Anthropic’s guidance on reducing unsupported answers↗ (opens in a new tab) recommends allowing uncertainty and checking claims against source evidence. Those techniques help make a review auditable, but they do not remove the need to verify the findings yourself.

How can you turn the review into a useful stakeholder update?

Give Claude the current decision state and ask it to preserve it. An update should tell a stakeholder what changed, what remains unknown, and what you need from them. It should not convert a recommendation into approval or imply that a task has shipped.

Write a short update for [stakeholder].
Use only this reviewed evidence and current task status.
Structure: what we learned, options under consideration, confirmed decision, next question, and owner of the next action.
If there is no confirmed decision, say Decision pending.
Keep proposed work separate from committed work.
Do not invent approvals, deadlines, or outcomes.
Reviewed record: [paste]

Check names, dates, and the wording of every commitment before sharing. If the update depends on repository investigation, use the separate guide to Claude Code for product managers. A code finding can inform a product discussion without deciding the product direction.

Keep the confirmed choice and its reason in fenbs after a person decides. That closes the gap between a useful chat and the instructions the next assistant will actually receive.

How to do this with fenbs

1. Create a free account and add a project for the product work.
2. Save the discovery, option-comparison, or review template in Skills and prompts, with the inputs it requires.
3. Record the choices a person approved in Decisions and rules. Keep unresolved questions distinct from those decisions.
4. Create follow-up tasks for the work a person chooses, and add safe context notes with references to the evidence.
5. Connect Claude using the guide in integrations. Ask it to read the context before working and save progress before the session ends.

fenbs is free for one person, no credit card. It is not the right fit if you only need a one-time brainstorm, and it does not run customer interviews or validate demand for you. Start with one recurring review prompt; the AI prompts hub has more reusable patterns.