Feedback · How-to

How to handle feature requests as a small team

Once people use your product, they'll ask for things. That's a good sign. The hard part is that you can't build them all, and the loudest request isn't always the most important one.

Write every request down, in one place

Requests arrive everywhere: email, the contact form, a comment under your post, a call. If they stay there, you'll remember the latest one and forget the rest. Keep one list. A spreadsheet, a notes file or an ideas board all work. Having one place matters more than the tool.

For each request, note what they asked for, who asked, and, most important, why they want it.

Ask “why” before “when”

“Can you add CSV export?” might really mean “I need to send numbers to my accountant.” Maybe a monthly PDF report solves that better. Maybe the real problem is that totals are hard to find.

When you reply, ask one question: “What would you do with it?” The answer often changes what you build, or shows it's already possible.

Count people, not messages

One customer asking five times is one request. Five customers asking once each is five. Merge duplicates and count different people. Note who they are, too: a paying customer about to leave weighs more than someone who signed up yesterday.

A simple way to decide

You don't need a scoring system with ten columns. For each request, ask three questions:

1. How many people want it, and do they pay, or would they?
2. Does it fit what the product is for? Say no to things that turn it into a different product.
3. How big is it? A one-hour fix that ten people asked for should just happen.

Look at the list every week or two, not every time a message arrives. Deciding in batches stops you from changing direction every day.

Answer everyone, even with a no

People who ask for features care about your product. Don't leave them in silence.

• Yes: “Good idea. It's on the list for the next few weeks. I'll tell you when it's live.”
• Maybe: “It's not planned yet, but I've noted it. How would you use it?”
• No: “We're keeping [Product] focused on X, so we won't build this. For now, [workaround] can help.”

A friendly no with a reason beats a vague “we'll consider it” that never ends.

Close the loop

When you ship something people asked for, tell them. A one-line email like “You asked for CSV export in March. It's live now.” turns a user into a fan. It's also the easiest way to show the product is alive.

MVPKit gives each project a public ideas board. Customers suggest ideas and vote without an account, you approve suggestions before they appear, and the most-voted ideas rise to the top. It's one place for requests, next to your help and contact form.