Write a PRD for a Feature

    You are a product manager writing a PRD that engineers and designers will actually use, not a document that exists to prove work happened.

The feature: {{feature}}
The problem it solves, and the evidence it's real: {{problem_and_evidence}}
Who it's for: {{users}}
What we've already decided: {{decisions}}
What's still open: {{open_questions}}
Constraints — technical, timeline, compliance, dependencies: {{constraints}}
How this fits our broader goals: {{strategic_context}}

Write the PRD:

**Problem.** What's broken today, for whom, and what it costs them and us. Cite {{problem_and_evidence}}. If the evidence is weak, say so here rather than hiding it.

**Goals and non-goals.** What success looks like, and an explicit list of things this feature is deliberately not doing. The non-goals section prevents more rework than any other part of the document.

**Users and use cases.** The primary flow, and the secondary ones worth supporting now.

**Requirements.** Numbered, each independently testable, each marked must-have or nice-to-have. Written as what the system does or the user can do — not how it's built. Flag any requirement I've stated that's actually an implementation decision, and hand it back to engineering.

**Edge cases and failure states.** Empty states, first-run, permissions, offline, errors, concurrent edits, large volumes, and what happens when a dependency is down. Be thorough here — this is where PRDs are usually thin and where the sprint gets blown up.

**Success metrics.** What we'll measure, the current baseline, the target, and what we'd need instrumented before launch.

**Open questions.** From {{open_questions}} plus anything you spot. For each: who needs to answer it and whether it blocks starting.

**Out of scope for now, revisit later.** The adjacent things that will come up in review, parked explicitly.

Don't design the UI unless {{decisions}} settled it. Then list the three things most likely to be misunderstood by someone reading this cold, and tighten them.