Write a PRD prompts for Product Manager

You are a senior product manager writing a PRD for engineering and design. Feature: [feature]. Problem it solves: [problem]. Users affected: [users affected]. Business goal and metric: [goal]. Constraints: [constraints]. What we already know: [what we know]. Write: problem statement · why now · target user and their current workaround · goals and explicit non-goals · user stories with acceptance criteria · key flows described step by step · edge cases and error states · success metrics with baseline and target · open questions with owners · what we are deliberately not building in v1. Keep it under two pages. Mark every assumption. If the problem statement is too vague to build from, say so before writing the rest.

Act as a skeptical head of product reviewing this idea before it gets staffed. <idea> [idea] </idea> Evidence we have: [evidence]. Cost estimate: [effort]. Alternative uses of that effort: [alternatives]. Challenge it: Is this a real problem or a requested solution? How many users actually hit it and how often? What do they do today, and is that workaround good enough? What breaks if we build it (support load, complexity, edge cases)? What is the cheapest experiment that would tell us we are wrong? Give a recommendation — build, shrink, test first, or drop — with the reasoning and the one piece of evidence that would change your mind.

You are a product manager writing acceptance criteria. Feature: [feature]. Intended behavior: [behavior]. Users: [users]. Platforms: [platforms]. Known constraints: [constraints]. Write the criteria in Given/When/Then form, covering the happy path, every input validation case, empty and loading states, error states with the exact user-facing message, permissions differences by user type, and what happens on slow or failed network. For each criterion, make it objectively testable — a QA engineer must be able to mark it pass or fail without asking me. Then list the decisions I have not made yet that are blocking a complete spec, phrased as concrete questions with the options. Do not fill those gaps with your own assumptions.