Feature requests

A preview of how this template lays out — the boards, their custom workflow states, and where the sample issues land. WIP caps show a badge.

• Bulk edit issues from the board view

  Linked from 4 customer conversations.

  • customer-ask
  P25pt

• Calendar view for cycles

  P28pt

• Granular notification preferences

  P33pt

These rules aren't created when you apply the template — they're recipes you can wire up in Settings → Automations once your board exists.

• When

  Issue created with label 'customer-ask'

  Then

  Add to the Requests list and apply a source label

• When

  Request moves to 'Shipped'

  Then

  Notify everyone who linked a conversation to it

New, Under review, Planned, Building, Shipped. Planned is the column that will get you in trouble, because the moment a request lands there somebody in sales will tell a customer it is coming. The board is designed around that risk: Under review exists so that 'we are considering it' is a real, visible state that is not a promise, and the source labels exist so the queue can be read as weighted demand rather than as a popularity contest won by whoever files the most tickets.

1. 1.Deduplicate on the problem, not the wording

   Three requests asking for an export button, a scheduled report, and an API endpoint are often one problem: getting data out. Merge on the underlying need and keep every original phrasing on the card, because the phrasings are evidence about who wants it and why. A queue deduplicated on titles alone will hide your biggest theme.

2. 2.Attach the requester to every card, always

   The card should record who asked — the account, the conversation, the support ticket. This is what makes the close-the-loop notification possible at Shipped, and that notification is the single highest-return thing this board does. It is also the only way to answer 'who actually wants this' when the request reaches prioritisation.

3. 3.Weigh demand rather than counting it

   Ten requests from trial users and two from accounts that renew next quarter are not comparable, and a raw count treats them as if they were. Label the source and the segment so you can sort by the thing you actually care about. Counting alone reliably prioritises whichever customer segment is loudest, which is rarely the one whose retention pays for the work.

4. 4.Say no in Under review, explicitly and in writing

   Declining is a real outcome and it deserves a state and a sentence. A request that will never be built should be closed with a reason, not left in the queue to keep the requester hopeful. The reason matters more than the decision: 'this conflicts with how the model works' teaches your team something, 'not now' teaches nobody anything.

5. 5.Close the loop the day it ships, not in the newsletter

   When a request reaches Shipped, tell everyone who asked for it, individually, with a link. This is unglamorous and it is the reason customers keep filing requests instead of quietly deciding you do not listen. A feedback queue whose contributors never hear back stops receiving contributions within about two quarters.

This board encodes one opinion about how the work should run. Here is where that opinion is wrong and something else fits better.

• You want customers to see and vote on requests. This board is internal. Public voting portals change the dynamic entirely — they provide social proof, deduplicate at intake, and let customers subscribe themselves — and simulating that with an internal board plus manual updates is a lot of work for a worse result.
• Requests are contractual commitments. If a feature ask is a condition of a renewal or a signed deal, it is not a request, it is a deliverable with a date, and it belongs in the roadmap and the account plan rather than in a queue of maybes.
• Nobody will do the review pass. The queue only stays useful if someone works through New on a rhythm. Without that, this becomes a place where feedback goes to be filed, which is worse than having nowhere to put it, because it consumes the goodwill of everyone who contributed.
• You have five customers. Talk to them. A queue is a way of coping with more feedback than you can hold in your head, and at that scale you can hold all of it, with far more context than a card carries.

Honest comparisons, including where the other tool wins. Planoda is pre-launch, so nothing below is a benchmark — it is a description of how each product approaches this job.

• Canny

  Canny is the mainstream purpose-built version of this: a public board where customers post, vote and subscribe, with automatic notification when something ships and a changelog attached. That public loop does work this template cannot — deduplication happens at intake because people find the existing post.

  Where Canny is better: For customer-facing feedback collection with voting and self-service subscription, Canny is better and the gap is structural, not cosmetic. This board makes you do that fan-out by hand every time.

• Productboard

  Productboard connects raw feedback to features to roadmap, with per-segment demand analysis and a prioritisation scoring model on top. It is aimed squarely at the problem of synthesising many inputs into a defensible plan, which is more machinery than five columns and a label.

  Where Productboard is better: If you need to show which segment is driving demand for what, with evidence attached to each feature, its insight-to-feature model does that natively. This board's segment labels are a much cruder instrument.

• Linear

  Linear's customer request feature attaches requests directly to issues, with the requesting customer and their revenue on the issue itself, so demand is visible where the work happens rather than in a parallel queue. Structurally that is a tighter design than a separate intake board.

  Where Linear is better: Having the request live on the issue means nobody has to keep two records in sync, and the close-the-loop notification comes from the same object engineers move to done. That synchronisation is manual here.