PRD Template for Feedback Collection

Example: "Our product decisions are informed by three unreliable sources: sales team anecdotes (biased toward enterprise requests), support tickets (biased toward complaints), and quarterly NPS surveys (too infrequent and too vague to be actionable). We have no way for users to submit feature requests, vote on priorities, or provide contextual feedback on specific features. A post-launch survey of our last 5 features revealed that 2 were not what users actually wanted — the requirements were based on misinterpreted support tickets."

Example: "Primary: Collect structured, contextual feedback from 20% of monthly active users. Quality: 80% of feedback items are actionable (specific enough to inform a product decision). Response rate: In-app micro-surveys achieve 30%+ completion rate. Decision influence: Every product decision in the roadmap references at least one piece of user feedback. Closing the loop: 100% of feature requests receive a status update when the feature ships or is deprioritized."

Example: "As a user, I want to submit a feature request from within the product so that I can describe what I need in the context of my workflow. Acceptance criteria: I can open a feedback form from any page via a persistent widget; the form captures my request, my use case, and an urgency level; I can optionally attach a screenshot; I receive a confirmation that my request was received; I can view the status of my past requests."

Example: "FR-1: A persistent feedback widget must be accessible from every page via a floating button. FR-2: The feedback form must support three types: feature request, bug report, and general feedback. FR-3: In-app NPS surveys must be triggerable on a schedule (every 90 days per user) and after key actions (post-onboarding, post-first-project). FR-4: All feedback must be categorized by feature area (auto-suggested based on the page where feedback was submitted). FR-5: Users must be able to vote on existing feature requests to signal demand. FR-6: The PM dashboard must show feedback volume by category, trending requests, and sentiment over time."

Example: "NFR-1: The feedback widget must load within 200ms and not impact page performance. NFR-2: Feedback submission must complete within 1 second. NFR-3: No feedback submission should ever be lost — submissions are queued locally if the server is unavailable. NFR-4: NPS surveys must not appear more frequently than once per 90 days per user. NFR-5: All feedback data must be accessible via API for integration with product management tools."

Example: "Metric 1: Monthly feedback participation rate. Target: 20% of MAU. Metric 2: NPS survey response rate. Target: 30%+. Metric 3: Actionable feedback rate (feedback specific enough to inform a decision). Target: 80%. Metric 4: Product decisions referencing user feedback. Target: 100%. Metric 5: User satisfaction with feedback experience. Target: 4/5+."

Example: "The feedback widget is a lightweight React component embedded in the application shell. Submissions are sent to a dedicated API endpoint and stored in a feedback table with full-text search indexing. Auto-categorization uses keyword matching against a feature taxonomy. NPS survey eligibility is tracked per-user with last-survey-date in the user record. The feedback dashboard aggregates submissions by category, sentiment (basic NLP classification), and time period. API export supports integration with Linear, Jira, and Productboard."

Example: "Risk: Only frustrated users submit feedback, biasing the data toward complaints. Likelihood: High. Impact: Medium. Mitigation: Use triggered micro-surveys after positive actions (completing a task, upgrading) to capture satisfaction alongside complaints. Include NPS to measure overall sentiment. Risk: Product team is overwhelmed by feedback volume and stops reviewing it. Likelihood: Medium. Impact: High. Mitigation: Auto-categorize and surface trending topics. Weekly digest of top feedback themes, not individual items."