Feature request tracker, and what has to be in one

A feature request tracker is the place where requests are kept, counted and answered in public. That is the whole definition, and the phrase doing the work in it is in public.

A private list of requests is a backlog. You almost certainly already have one, inside your issue tracker, and it is not what people mean when they search for this.

What they mean is the thing that closes the loop: somebody asks, other people agree, and the answer is visible to all of them without anybody sending an email.

What has to be in a feature request tracker?

Four parts, and a tracker missing any of them stops working within about two months.

A place to put the request. A form the person hits at the moment they want the thing, not a support address they have to remember.

A count. Without one you have a list, and a list has no order except whoever shouted most recently. The count is what turns eleven separate opinions into one argument.

A status on every request. Ours has five by default: Suggested, Denied, In Review, In Progress and Completed. Denied is the one most trackers leave out, and leaving it out is why people stop filing: silence reads as neglect, and a written no reads as an answer. It is on here unless you turn it off.

A way to tell the person it shipped. A tracker that never reports back is a suggestion box with better typography.

Does somebody need an account to file a request?

Not here, and this is the decision that changes how much you collect.

A signed out visitor gets an anonymous identity minted in their own browser the first time they do anything. Filing, voting and commenting all work from that first page load. There is no form in front of the form.

Every step between a person having an opinion and that opinion being recorded loses some of the people, and the ones who push through are not a representative sample. They are the unusually motivated, which means a tracker that requires an account is measuring persistence.

Requiring an account buys you attribution in exchange, which is a real thing to want. What that trade costs, and where it fights with weighting, is a page of its own.

Every suggestion from a visitor is held for review before it appears. That cannot be switched off, so the tracker your customers read has always been looked at by a person, and a person has to look.

Where does the tracker actually live?

Three places, and you can use all three at once.

On a page of ours. A public board at its own address that you can hand somebody in a link. On the higher plan it answers on your own domain instead.

Inside your own product. Seven widgets put the board, the roadmap, the changelog or a single vote control for one feature on a screen you already own, with one script tag. None of them is held back for the higher plan.

From your own code. Twenty one API endpoints read a board, list requests, file one, vote, comment and take a vote back. That is the PRO plan, because the API is a PRO capability and Lite does not include it. The widgets above are a different thing and need no API key, which is why they work on the nine dollar plan.

The third one matters more than it looks. A public tracker mostly reaches people who went looking for it. A vote control on a screen inside your paid product reaches somebody you already know is paying, at the moment they hit the thing that is missing.

Can you track feature requests in a spreadsheet, or in GitHub issues?

Yes to both, and for a while either is the right answer.

A spreadsheet holds requests perfectly well. What it cannot do is show the count to the person who asked, and that is the mechanism the whole category exists to provide. If nobody outside your company can see the sheet, you have a backlog with a different file format.

GitHub issues with a thumbs up reaction is the version most engineering teams reach for, and it is genuinely a tracker. It works when the people filing requests already have GitHub accounts and are comfortable in them, which is true for developer tools and untrue for almost everything else. It also puts your customers in the same room as your bug reports and your internal arguments, which is a choice rather than an accident.

The question that decides it is not which is more powerful. It is whether the people you need to hear from will show up in the place you picked.

What does a feature request tracker cost here?

Nine dollars a month for one project, and thirty nine for more projects, a custom domain, a team and the secret key.

There is no meter on the number of people who participate. A tracker with fifty voters and one with fifty thousand cost the same, and no widget sits behind the higher plan. The price and billing unit for every tool in the category is in one table, and it names the ones that are cheaper than us.

We do not have a free tier. A card is required to start the fourteen day trial.

14 days, a card at signup, then $9 or $39 a month.

What separates a tracker people use from one that goes quiet?

Five habits, and every one of them is about the answer rather than the collection.

Answer the denied ones out loud. A written no, with the reason, keeps a tracker alive. An unanswered request is the thing that teaches people not to bother next time.

Move a card the same week you decide. The status is a promise about how current the board is, and a status that lags by a month is worse than no status.

Close the loop by hand at the start. The changelog emails the people whose own vote is in the release, and there is no subscriber list, which means nobody gets told about something they did not ask for.

Read the comments, not just the counts. A vote says somebody agrees. A comment says why, and the why is the half that changes what you build rather than only what order you build it in.

Decide whose vote counts for what before the board gets big. A plain count answers how many people want this. If your customers pay you different amounts, that is the wrong question, and the information that separates two cards with twelve votes each was never recorded unless you set it up first.

When is a tracker the wrong tool?

Two cases, and being honest about them costs us nothing.

If you have no paying customers yet, a tracker sorts demand you already have and does not create any. Ten conversations will teach you more than a hundred votes.

If your roadmap is already full for a year and the constraint is engineering time rather than certainty, a public tracker is a place for requests to queue and go stale, which reads as neglect and is worse than not having one.

There is also no artificial intelligence anywhere in this product, no outgoing webhooks, no Slack app and nothing that writes an issue into your tracker. The integrations page leads with the absences for the same reason this section does.