What is a feature request?

What is a feature request?

A feature request is a message from a customer asking the product to do something it does not do today, or to do something it does differently. It often starts as a short sentence such as "Please add CSV import" or "I need to invite my whole team at once." Feature requests are one of the three common kinds of product feedback, next to bug reports and praise. They are also the kind most likely to arrive as a solution instead of a problem.

The request itself is rarely the thing you should build. The customer is describing a workaround they picked, based on what they know about the product today. Your job is to find the need underneath it, decide whether that need matters to enough of your users, and record the request so the next decision is easier.

What should a good feature request contain?

A useful feature request answers three questions: what the person is trying to do, what gets in the way, and who is asking. A message that answers none of them is a wish. A message that answers all three is evidence you can work with.

• The goal. What the person wants to achieve in their own work, such as "send the same report to five clients every Monday."
• The obstacle. What they do today, or why they cannot finish. This is often where the real problem lives.
• The context. Their role, team size, or the part of the product the request belongs to, if they share it.

Context changes how much a request weighs. Ten requests from people who run teams of twenty are a different signal from ten requests by solo users who tried the product once. Keep the sender's ID and any details you collected, so the pattern is visible later.

How do you log a feature request so it stays useful?

Logging is where most teams lose detail. A request typed into a chat window and forgotten has no value to anyone. Log each one as its own item, next to bugs and praise, and keep the customer's words as close to the original as you can.

1. Capture the message as written. Do not rewrite it into your own feature name yet.
2. Set the type to idea so it is counted apart from bugs.
3. Add an internal note with your first read of the problem, and label it as a guess.
4. Leave the status at new until someone has made a decision.

Keep the note short. A line such as "Probably wants to reuse saved filters across products" is more useful than a paragraph. When another customer asks for the same thing later, search for a word from the request and add to the existing thread of thought instead of starting over.

How do you answer a feature request?

The answer matters as much as the build. A customer who asks for something and hears nothing will assume the message went into a void. Reply within a few days, even when the answer is no, and say what you understood. Explain the decision in plain words: "We are not building this yet, because most people solve it with a filter, but we have noted that the filter is hard to find."

Each answer should fall into one of three groups:

• Planned. You will build it or are seriously considering it. Set the status to planned and say you recorded the need.
• Not now. The need is real, but the timing is wrong. Keep the item open or note the reason so the next triage can revisit it.
• Not for this product. Say so kindly and point to a workaround where one exists. The guide on saying no to feature requests covers the wording.

Why does the problem behind a request matter more than the feature?

Two customers can ask for the same feature for different reasons. One wants a faster way to export data for an accountant. The other wants a backup they can open in a spreadsheet. A single export button may satisfy the first and fail the second. One more question before deciding is cheap, and it prevents building the wrong thing.

When you reply, ask a short question such as "What do you do with the export after you download it?" Many customers answer, and their answer becomes the note that speeds up triage for everyone who follows. The article on finding the problem behind a feature request has more questions to borrow.

Doing it with Escuta Produto in ten minutes

Escuta Produto gives feature requests their own type, so ideas are filtered apart from bugs and praise. The widget can open directly on the idea type when a button carries the attribute data-escuta-open="idea". The same form is available on a hosted page at /f/your-product-slug, and developers can send the same fields through the REST API. Every item has a status of new, planned, in progress, done or closed, plus private internal notes for your reasoning.

Filter the inbox by idea and new once a week, read each message, and use the notes to record the problem behind it. Escuta Produto has no tags and no duplicate merge, so search by a keyword from the request and mention the related items in your notes. The widget documentation explains each entry point. For the weekly routine, read how to triage customer feedback and how to design a feedback status workflow.