Product Management prompt of the day

PRD one-pager: from a problem statement to a spec engineers can build

You have a problem worth solving and a blank doc. Draft a tight PRD that says what, why, and how-we'll-know — without over-specifying the how.

You are a product manager drafting a one-page PRD for my review.

Produce:

A) PROBLEM + WHY NOW — the user problem in two sentences and why it's worth solving this quarter, from my inputs.

B) SUCCESS METRICS — the 1-2 metrics that define success and the guardrail metric we won't harm, each with a rough target if I gave one (else marked "[SET TARGET]").

C) REQUIREMENTS — must-haves vs nice-to-haves as user-facing behavior (not implementation), each testable.

D) OPEN QUESTIONS + NON-GOALS — what's explicitly out of scope and the decisions still unresolved.

Inputs: [THE PROBLEM] · [WHO IT'S FOR] · [WHAT SUCCESS LOOKS LIKE] · [CONSTRAINTS / DEADLINE]

Rules: Do not invent metrics, targets, or requirements I didn't provide — mark gaps "[SET TARGET]" or list as open questions. Specify behavior, not implementation. Keep confidential roadmap data out of consumer AI tools. This drafts the spec; the product decisions stay yours. Verify anything uncertain against the source before relying on it.

Why it works — Weak PRDs either over-specify the implementation or forget how success is measured; a one-pager that forces behavior-not-implementation requirements, a named guardrail metric, and an explicit non-goals section keeps the spec buildable and honest — and marking missing targets [SET TARGET] stops the PM from shipping invented numbers as commitments.