product-requirements

Create a PRD by starting with a template structure covering vision, problem statement, user personas, journeys, acceptance criteria, and success metrics. Fill each section systematically to define what you're building, why it matters, who uses it, and how to measure success.

A complete PRD validates that WHAT you're building, WHY it solves a problem, WHO your users are, their JOURNEYS through the product, specific acceptance criteria, measurable metrics, and clear implementation boundaries are all documented and cross-reviewed.

Frame acceptance criteria as specific, testable conditions tied to user outcomes. Define them from multiple perspectives—engineer, product, and user—ensuring each criterion has a clear success state and relates directly to documented user journeys and metrics.

Yes. Use multi-perspective review to validate problem statements and requirements with stakeholders from different functions. This ensures the PRD reflects engineering feasibility, business value, and user needs before implementation begins.

Map user journeys by documenting the steps users take to achieve their goals, the context they're in, and the problem they face at each stage. Link journeys directly to acceptance criteria so requirements stay grounded in real user behavior.

Yes. Use a formal validation checklist covering vision, problem, value proposition, personas, journeys, acceptance criteria, metrics, and implementation boundaries. This systematic approach catches gaps before handoff to development.