In-Product Feature Request & Roadmap Voting: Chat Prompts

⬅️ Back to 6. Grow

A feature-request board lets customers submit ideas, vote on others' ideas, and see what's coming. Done well, it surfaces real demand signals (the 50 customers asking for "API webhooks" outweighs the 1 enterprise customer asking for "white-label SSO"); reduces support tickets ("when is X coming?" → see roadmap); creates community engagement; and gives PM a defensible decision tool. Done poorly, it becomes a stale graveyard of ignored ideas, or worse, a public commitment to features you'll never ship.

This is distinct from a public roadmap display (which is one-way communication) and a customer feedback widget (which is a one-off submission form). A voting board is interactive: customers submit, vote, comment, see status, get notified.

When This Belongs

Use feature-request voting when:

• You have 100+ active customers
• You ship features regularly
• Customers are technical / engaged enough to participate
• You'll actually use the data to inform roadmap

Don't bother when:

• Pre-PMF (you should be talking to customers 1:1, not crowdsourcing)
• Solo founder building intuition (community voting can lead astray vs depth interviews)
• Customers don't speak your language (B2B with non-engineering buyer; voters dominated by power users not buyers)

Build vs Buy

You can buy this off-the-shelf or build it. The decision:

For most teams, Canny is the default. It's polished, integrates with Slack/Jira/Linear, supports SSO, and costs reasonable for the value.

Build in-product when:

• You need data ownership (regulated, compliance, sensitive industries)
• You want voting tied to in-product behavior (only paying customers vote; weight by ARR)
• You want unique UI tied to your brand
• Native integration with your in-app navigation matters

In-Product Build: Data Model

I'm building feature-request voting in-product. Help me design the data model.

Schema (Drizzle):
```sql
features:
  id, title, description, status (idea | planned | in_progress | shipped | closed),
  category (e.g. 'integrations', 'api', 'ui'), 
  votes_count (denormalized),
  created_by_user_id, created_at,
  shipped_at (nullable), shipped_release_url (nullable)

feature_votes:
  user_id, feature_id, weight (1 default; can scale by tier),
  voted_at,
  primary_key: (user_id, feature_id)

feature_comments:
  id, feature_id, user_id, body (markdown),
  created_at, edited_at, parent_comment_id (for threading)

feature_subscriptions:
  user_id, feature_id, subscribed_at
  (notify when status changes)

Indexes:

• features (status, votes_count desc) for the public board
• feature_votes (user_id) for "what I voted on" lookups
• feature_comments (feature_id, created_at) for thread display

Seed: backfill from your existing feedback channels (support tickets, Slack mentions, sales notes).

Stack: Next.js + Drizzle + Postgres.

## The Public Board Page

Build the /roadmap page where customers see + vote:

Layout:

• Header with categories filter + status filter + sort (top votes / recent / trending)
• List of features:
  • Title + brief description
  • Vote count + upvote button (large, primary action)
  • Status badge (Planning / In Progress / Shipped)
  • Comment count
  • Submitter info
• "Submit a feature request" CTA at top

Behavior:

• Voting requires sign in
• Click upvote → optimistic UI; vote persists; vote count animates
• Click feature → detail page with full description + comments
• Detail page allows commenting + subscribing for status updates
• Search across feature titles + descriptions

Layout patterns:

• Grouped by status (Planning / In Progress / Shipped sections)
• OR flat list sorted by vote count
• Pick one — Canny defaults to grouped; pick what fits your culture

Stack: Next.js + Drizzle + TanStack Query + shadcn/ui.

## Submission Flow

Build the "submit a feature request" form:

UX:

1. Click "Submit feature" button
2. Modal opens: title, description, category, optional screenshot
3. As user types title, search existing features for duplicates
4. If duplicate found, prompt: "Looks like '[existing]' is similar — vote there instead?"
5. On submit, create feature with status='idea'
6. Confirmation + share link

Anti-spam:

• Rate limit submissions (5 per user per day)
• Block known spam keywords
• Optional admin moderation queue for first-time submitters

Stack: Next.js + Drizzle + zod for validation.

## Status Transitions + Notifications

Implement status transitions + email notifications:

Statuses: idea → planning → in_progress → shipped (or closed)

When PM moves feature from idea → planning:

• Update feature.status
• Email all subscribers: "Status updated: [feature] moved to Planning"
• Add a status-change comment showing date + actor

When shipped:

• Update feature.status to 'shipped'; populate shipped_at + shipped_release_url
• Email all subscribers + voters: "Shipped! [feature] is live. [link]"
• Optional: in-product banner

When closed (won't ship):

• Update feature.status to 'closed' with closed_reason
• Email subscribers with explanation
• Be specific about why (off-roadmap; technical infeasibility; conflicts with other priorities)

Don't:

• Silently change status without notification
• Mark "shipped" without an actual link to the live feature
• Close requests without explanation

Stack: Next.js + Drizzle + Resend.

## Admin / PM View

Build the admin view at /admin/features:

Features:

• All features (any status)
• Sort by votes / age / status
• Filter by category
• Bulk operations (move multiple to "planning"; close stale ones)
• Per-feature: see all voters + commenters; tag tags; merge duplicates; assign to PM owner

Decision support:

• Vote count weighted by customer plan tier (e.g., enterprise vote = 5x; pro = 2x; free = 1x)
• ARR impact: total ARR of voters
• Show duplicate suggestions (similar titles)
• Show recent activity (new votes / comments in last 7 days)

Workflow:

• Triage queue: new submissions need review
• Backlog: triaged but not committed
• Active: in planning / in progress
• Shipped + closed archives

Stack: Next.js + Drizzle.

## Vote Weighting (Optional but Powerful)

Naive vote-counting (every vote = 1) gives loud voices outsize influence. Weight by customer tier or engagement.

Implement vote weighting based on customer attributes:

Options:

1. Plan tier: Free = 1; Pro = 2; Enterprise = 5
2. ARR: weight = log(ARR) — bigger customers get more weight but not linearly
3. Engagement: active customers (>7 days/month) get full weight; inactive get half
4. No weighting: pure democracy — every vote = 1

Most useful: combine plan tier + active status. Engineer-PM hybrid weighting.

Implementation:

• vote.weight calculated at vote time (or recomputed nightly)
• Display "Votes" as the weighted total OR show both raw + weighted
• Be transparent in admin UI; consider exposing to customers if it builds trust

Stack: Next.js + Drizzle.

Be careful — vote weighting can feel undemocratic. If you weight, be transparent about how (or don't expose externally).

## Public vs Customer-Only

Decide who can see + submit:

**Public (anyone can see + vote):**
- Pros: SEO benefit; community signal for prospects; low-friction
- Cons: spam risk; pollution from non-customers; competitive intel exposure

**Login-required (must have account):**
- Pros: real customers; spam-controlled; private to your business
- Cons: slower discovery; less community feel

**Hybrid (read public; write requires login):**
- Most common pattern. Accessible browsing + accountable contribution.

Pick based on your product + audience. B2B SaaS with sensitive features → login-required. Developer tools / community-driven → public.

## Avoiding Common Anti-Patterns

Help me avoid common roadmap-voting failures:

Anti-pattern 1: Stale roadmap

• 200 features in "idea" status from 2 years ago; nothing closed; feels abandoned
• Fix: weekly triage; close stale items with explanation
• Show "active" features prominently; archive stale into a dimmer "backlog" view

Anti-pattern 2: Over-promising

• Customer's top-voted feature shows "in progress"; six months later, still "in progress"
• Fix: only mark "in progress" when actually being worked on; deprecate "in progress" if scope changes
• Mark "won't ship" with explanation rather than silent rotting

Anti-pattern 3: Duplicates

• Same idea submitted 5 times; votes split; PM can't see real demand
• Fix: duplicate detection on submit; admin merge; treat votes as transferred

Anti-pattern 4: Voting board as PM substitute

• PM uses votes as the only roadmap input; ignores qualitative customer interviews
• Fix: votes are one signal; combine with sales pipeline themes, support volume, strategic direction

Anti-pattern 5: Public commitment to features that don't ship

• Status "Shipping Q2" → Q2 passes → still not shipped → embarrassment
• Fix: vague status descriptions; "in progress" without time commitments unless certain

Anti-pattern 6: Negative feedback channel

• Customers post complaints + competitor comparisons; signal lost in noise
• Fix: clear submission guidelines; moderation; redirect complaints to support tickets

Show me the operational checklist + workflow for avoiding these.

## Integration with Product Operations

Hook the roadmap into your product operations:

1. Sales sees real-time: "When is [feature] coming?" → AE looks at roadmap board
2. CSM uses for QBR: list features the customer voted on; show progress
3. Support links: "We've heard this from many customers. Vote here to track progress: [link]"
4. Product team uses: weekly triage of new submissions; quarterly review of top-voted
5. Slack integration: new high-vote feature pings #product channel
6. Linear / Jira sync: feature accepted → creates ticket; ticket shipped → updates feature status

Implement Slack + Linear sync as the highest-leverage integration.

Stack: Next.js + Slack webhooks + Linear API + Drizzle.

## Common Pitfalls

**No moderation queue.** Spam, duplicates, complaints flood the board. Moderate first submissions.

**Vague status meanings.** Customers see "Planning" — does that mean Q1? Q4? Never? Define + document statuses.

**Dead board.** New submissions every week; PM never triages; feels abandoned. Weekly cadence is non-negotiable.

**No closed-loop feedback.** Customer votes; never hears anything; assumes ignored. Notify subscribers on status change.

**Duplicate explosion.** Three versions of "API webhooks" each with 50 votes. Merge them; honor the votes.

**Public commitment to dates.** "Shipping Q2 2026" → reality slips. Avoid date commitments on the board.

**Vote-weighting opaque.** Customers see their vote "counts more" but don't know why. Be transparent or don't expose.

**Top-voted = always built.** PM gets locked into chasing votes; misses strategic features that aren't yet known to customers. Votes are signal, not mandate.

**Features shipped without notifying voters.** Customer voted; feature shipped silently; customer never realizes. Always notify on ship.

**Status manually managed in spreadsheet.** PM forgets to update; board out of sync. Tie to engineering ticket system.

**Feature board feels like noise.** No personality; no narrative; doesn't communicate company direction. Add context; group; explain.

**Voting board for things customers shouldn't decide.** "What programming language should our SDK be in?" — engineering decision. Constrain to user-facing features.

**Allowing competitors / haters to dominate.** Public boards become forum for competitor reviews. Moderation + clear submission guidelines.

**No segmentation in admin view.** PM sees raw vote count without ARR / segment context. Segment-aware admin.

**Notification spam.** Customer subscribed to 20 features; gets daily emails. Digest by default; per-feature opt-in for individual notifications.

**Forgetting to backfill.** Launching the board with 0 features feels empty. Pre-seed from existing feedback (support, sales, Slack mentions).

**No "shipped" celebration.** Features ship; status changes silently. Make ship moments visible — banner, email, "what's new" item.

**Trying to ship every top-voted feature.** Strategic discipline says no to many even if popular. Communicate that some popular requests are intentionally not on the roadmap (and why).

## See Also

- [Changelog & Roadmap](./changelog-roadmap-chat.md) — public-facing changelog (different)
- [In-Product Release Notes / What's New](./in-product-release-notes-whats-new-chat.md)
- [Customer Feedback Widget](./customer-feedback-widget-chat.md)
- [Customer Feedback Surveys](./customer-feedback-surveys-chat.md)
- [Activity Feed / Timeline Implementation](./activity-feed-timeline-implementation-chat.md)
- [Comments / Threading / Mentions](./comments-threading-mentions-chat.md)
- [In-App Notifications](./in-app-notifications-chat.md)
- [Notification Preferences & Unsubscribe](./notification-preferences-unsubscribe-chat.md)
- [Microcopy & Product Copy Systems](./microcopy-product-copy-systems-chat.md)
- [Customer Reports & Scheduled Exports](./customer-reports-scheduled-exports-chat.md)
- [Email Template Implementation](./email-template-implementation-chat.md)
- [Audit Logs](./audit-logs-chat.md)
- [Roles & Permissions](./roles-permissions-chat.md)
- [Onboarding Checklist & Setup Progress UI](./onboarding-checklist-setup-progress-chat.md)
- [In-App Status Banners & System Notifications](./in-app-status-banners-system-notifications-chat.md)
- [Settings & Account Pages](./settings-account-pages-chat.md)
- [Customer Feedback & Feature Request Tools (VibeReference)](https://viberef.dev/product-and-design/customer-feedback-feature-request-tools.md) — Canny / Productboard / Frill / FeedBear comparison
- [Public Roadmap (LaunchWeek)](https://launchweek.dev/content/2-content/public-roadmap.md)
- [Customer Advisory Board (LaunchWeek)](https://launchweek.dev/content/4-convert/customer-advisory-board.md)
- [Voice of Customer Program (LaunchWeek)](https://launchweek.dev/content/4-convert/voice-of-customer-program.md)