Create a product-feedback triage workflow that scales

Start with a small workflow

Use only the states your team can keep current. A simple workflow reduces ambiguity and makes your board readable during a quick weekly review.

Suggested internal workflow

New → Reviewing → Planned → In progress → Done

Optional: Needs more context

Classify the incoming item

During triage, first decide whether the item is a bug, feature request, or general feedback. Then add labels for the affected area, customer segment, platform, or urgency. Classification makes later analysis possible without turning every submission into a lengthy form.

• Use a small stable label set such as Billing, Mobile, Onboarding, and Integrations.
• Reserve urgent for genuine time-sensitive customer impact.
• Keep customer wording in the original item rather than rewriting away useful context.

Find duplicate demand

Search before creating a new canonical request. When several people ask for the same outcome, consolidate their demand around one item, retain the useful details, and use the vote total as a clear signal. Do not delete a report that contains distinct reproduction steps or customer context.

Ask for the missing decision context

A request such as make exports better is not enough to plan. Ask what the customer is trying to accomplish, what happens today, who is affected, and how often. Add the answer as a comment or internal note before moving the item to Planned.

Useful follow-up questions

• What outcome are you trying to achieve?
• What is the current workaround?
• How often does this block you?
• Which part of the product are you using when it happens?

Prioritize with a repeatable decision

Use votes as one input, then compare reach, impact, confidence, effort, strategic fit, and urgency. For comparable feature requests, put the assumptions into a RICE score so the team can discuss the inputs rather than argue about a mysterious ranking.

• Use the RICE calculator for a quick shared score.
• Treat bugs with severe customer impact separately from feature scoring.
• Document why an item was deferred when that context will matter later.

Create implementation work without leaking it

When a request is selected, create an internal development task and link its purpose to the customer-facing request. Keep the public item readable; implementation subtasks, estimates, and investigation notes belong on the internal board.

Close the loop after shipping

Mark the request Done, add a brief release note or comment, and thank the people who raised it when appropriate. This makes voting feel worthwhile and trains customers to keep sharing higher-quality feedback.