Feature request triage for small teams
The short answer
To triage feature requests, keep them in one list, merge duplicates, link each to the customer's words, then rank by what is broken and how many accounts need it. Say no with a reason and tell people when it ships. Annsa groups matching requests and ranks them. You decide.
Feature request triage is deciding, for each request, whether it is a duplicate, a bug, a yes, a later or a no, and telling the person who asked.
TL;DR
- One list. Merge duplicates. Link every request to the customer and their words.
- Rank by what is broken first, then by how many accounts and how much revenue. Votes are one input.
- Say no with a reason, and tell people when it ships.
When to use it: as soon as requests arrive from more than one place. When not: with a handful of requests, a short list you read each week is enough.
How do I triage feature requests?
Six steps. Most small teams skip steps 2, 3 and 6, and those are where the value is.
- One list. Requests come in through Slack, support chat, calls, surveys, a spreadsheet nobody updates. Pull them into one place, or you will rank the ones you remember.
- Merge duplicates. Ten people ask for the same thing in ten ways. One row, ten quotes. Now you can count.
- Link to the evidence. The person, the account, their exact words and what the account pays. Without it, "export to CSV" could be a nice-to-have or the reason a customer is leaving.
- Rank. Broken things first. Then what customers asked for, by how many accounts and how much revenue. Then ideas.
- Say no with a reason. A clear no is kinder than a yes you will not keep.
- Tell them when it ships. The person who asked is the first one to tell.
What is the difference between a bug, a request and an idea?
- Bug: something that is meant to work and does not. It goes ahead of most requests.
- Request: something a customer asked for. Keep their words.
- Idea: something you, your team or your agents think of. It has no customer behind it yet, and that is fine. Keep it in the same list, below what customers asked for.
Mix them in one list, and mark which is which.
Why do voting boards favor loud users?
Voting is a voluntary choice, and voluntary choices skew. In statistics this is self-selection bias: when people choose to take part, the sample is skewed. In practice:
- The loud and the early win. The people who vote are not your whole customer base. Customers who struggle quietly, or who left, never vote.
- All votes weigh the same. A free user's vote counts as much as your biggest account's.
- Votes attach to solutions. People vote for the feature they thought of, not the problem behind it.
- Counts feed on themselves. A high count draws more votes.
A board is still useful as one source. Treat the count as a signal, then check who is behind it. Your agents can read the ranked list too, so what you decide gets built.
How do I say no?
Short and specific, in your voice.
- Say it early. A slow maybe is worse than a no.
- Give the reason: it does not fit your bets, it is too big for now, or a different fix solves the same problem.
- Say what you will do instead, or what would change your mind.
- Send it to the person who asked, not to a board.
Use the notes below.
## Triage note
- Request: [one line, in the customer's words]
- Evidence: [name, account, what the account pays]
- Their words: "[exact quote]"
- Merged with: [other requests that mean the same]
- Type: bug / request / idea
- Decision: now / next / later / no
- Why: [one line]
- Tell: [who to tell, and when]
## A no, in three lines
Hi [name], thanks for asking for [thing]. We are not building it, because [reason]. For now, [what to do instead, or what would change our mind].
## The "it shipped" note
Hi [name], you asked for [thing] on [date]. It is live: [one line on what changed, and where to find it].
How does Annsa do it?
Annsa is the source of direction for your agents. Requests become one list you can triage.
- Requests come in from Slack, Intercom, call transcripts, surveys, CSV and Google Sheets imports, GitHub, typed in by hand, and an API. Each keeps the customer behind it, their exact words, the account and its revenue.
- Annsa groups matching requests, so duplicates merge into one row.
- It ranks priorities. Within your bets, what a person marked broken (P0 or P1) comes first, then what customers asked for, then ideas. Then severity, how many accounts, revenue and urgency. A person's severity always wins.
- Ideas from you, your team and your agents' findings sit in the same list. Agents file findings with a severity and a reason.
- Each priority moves open, ready, built, shipped, shared. When it ships, Share Back drafts a note to each person who asked. You send it.
You choose what to build. Annsa never decides for you. See Priorities.
Source: Self-selection bias, Wikipedia.