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."

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.