product

User stories

Format: As a , I want so that . Acceptance criteria in Given/When/Then, 3–7 per story; more means the story needs splitting. Stories are vertical slices a user could notice — "build the database table" is a task, not a story. INVEST check on every story: independent, negotiable, valuable, estimable, small, testable.

Prioritization discipline

• RICE: reach (users/quarter), impact (3=massive, 2=high, 1=medium, 0.5=low, 0.25=minimal), confidence (100/80/50%; below 50% means go validate, not guess), effort (person-weeks). Show the arithmetic.
• The loudest stakeholder's request enters the same scoring as everything else — provenance is not priority.
• Kano lens when the roadmap looks all-maintenance: basics must work before delighters earn their slot.
• Cut scope by shipping the smallest thing that tests the riskiest assumption, not the smallest thing that's easy.

Metrics

• One north-star per product, 2–4 guardrails per launch (latency, churn, support volume, revenue).
• Leading over lagging where possible; define the counter-metric for every growth metric (activation up + support tickets up = not a win).
• Pre-register the decision rule: "if metric doesn't move X% in Y weeks, we roll back / iterate / kill."

AI features — the eval is the spec

Model behavior can't be fully specified in prose, so acceptance criteria become an eval set: 50–200 real or realistic inputs (include known failure modes, edge cases, and adversarial or unsafe requests) with expected outputs or graded rubrics. Set the quality bar per dimension (correctness, groundedness, tone, refusal behavior) before building; add cost and latency per task as guardrails. Write a first draft, then refine it after reading real failure traces, because the useful failure categories only show up in actual outputs. LLM-as-judge scores count only once they are calibrated against human labels. Launch gate = eval threshold met + a human-reviewed sample; after launch, production failures feed back into the set. Include a human fallback for low-confidence cases.

Judgment defaults

• Feedback is data about problems, not instructions about solutions. Five customers asking for dashboards may be one problem (no visibility) with a better fix.
• Distinguish reversible from irreversible decisions — spend discovery effort proportional to reversibility.
• When evidence is thin, say so and propose the cheapest experiment (fake door, concierge, prototype interview) instead of padding the PRD with confident prose. AI prototyping tools make a clickable prototype a same-day artifact — put it in front of users before writing the long PRD, and treat the prototype as a discovery tool, not as the spec.