Potential new features must be go through a triage process before we can determine (a) whether the cost of the feature is worth the benefit it provides and (b) how highly to prioritize the work. The Dev Planning Trello board is used to track features as they make their way from un-vetted requests to completion.
On roughly a weekly basis, feature requests on the Triage list are evaluated by the whole team. Advocates can explain why they think it's valuable and developers can estimate costs of various approaches. Everyone should understand the root problem addressed by the feature, discover alternate approaches, and consider how "core" the functionality is to the value we provide.
This triage meeting may be part of a weekly stand-up, or it may be a dedicated meeting, depending on the volume.
Incoming Feature Requests
Features may be requested by customers, suggested by Underdog, or conceived of in-house. In any case, they'll start on the Triage list. When adding an item to the list, make sure to explain all necessary context, including screenshots, quotes from customers, and insight you've gained while talking to them or thinking about their problems. Your teammates should be able to understand the gist of the feature along with its potential benefits by reading the Trello card.
The card should also include (a) the customer(s) requesting the feature and (b) a 1-5 star estimate of its importance to them. (Is it in their top two?)
Preparation for the Triage Meeting
Everyone should spend some time before the Triage meeting reading the board and understanding the features being proposed. That way the meeting can be spent discussing the merits of each feature, rather than simply understanding what they are.
Triage Meeting
Each item in the Triage list is discussed, and a decision is made on whether it's worth pursuing. If it's something we want to develop, it'll move into one of the Backlog lists below. Otherwise, it'll be archived. Don't worry about "losing" a request by archiving it. If it gets requested again in coming weeks, it can always be considered again. Through repetition, the team may be persuaded to value it more highly.
Project Backlog
This is for development items that will take more than a few days. There will be items here that are top priorities for the company as a whole, as well as significant enhancements we think will be appreciated by many customers.
Fruit Backlog
The name is from "low-hanging fruit," and it refers to items that are cheaper to develop (1-2 days) but will nonetheless make at least one customer happier. Because the dev investment is much less, the "value" bar is lower here. It's nice to have some good fruit features in the queue because (a) it lets us give customers a little jolt of satisfaction and (b) it lets devs diversify their time rather than simply hammering away at a top-priority project that progresses slowly. Many of these are going to be too small to announce to the entire customer base when complete, so it's crucial that we track which customers are interested in these.
Prioritization
The backlog lists should be roughly ordered according to priority, with the most important items being on top. This is especially important for the Project Backlog, since development on large projects must be carefully prioritized. Fruit features can be picked off according to opportunity, dev scheduling, satisfaction levels of particular customers, or even dev enthusiasm.
Progress
As design or dev begins, cards are moved into the "In Progress" list. Once they're ready to release, they can move either into "In Beta" or "Done" depending on whether they're going to be released to the whole customer base. When a feature shows up in a release email, the Trello card can be referenced (along with email / Freshdesk records if necessary) to figure out who's interested in the feature. Every few weeks, cards in the Done list can be archived.