How I Approach Feature Requests

Receiving feature requests is part of running a software team. Here’s how I handle them.

What are Feature Requests?

Feature requests are requests for behavior in a software product. Sometimes bugs get lumped in, too; it’s often a little messy.

Feature requests come from both inside and outside your company. Some are valuable, some aren’t, others contradict things we’ve already built, or may want to build. Some come from customers who are about to churn. Others might make sense for one customer but would confuse others.

Ideas are cheap. Every feature is possible, but none of them are free. I want my teams to be funnels for ideas. And I want the neck of that funnel to be narrow with intentionality.

How I Approach Feature Requests

Here’s the policy:

  • Listen
  • Say “Thank you” (no promises)
  • Document (optional)
  • Follow-up (optional)

Listen

When a feature request comes in, listen and record as much information as you can. What is the customer trying to do? Why does it matter to them?

Use the “Five Whys”:

  • They want to add a new filter to the employees table… why?
  • Because they have one employee they don’t want to see in the table… why?

This is a chance to listen, show empathy, and strengthen a relationship. And sometimes, this conversation goes in surprising directions.

Say “Thank you”

Say: “Thank you very much for this suggestion; I’ll bring it to the engineering team.”

No promises. No timelines. If a ticket was opened by the customer, close it.

Document (Optional)

If the idea is clear, compelling, or well-articulated, make a ticket on your feature board. Note: this is not your backlog! It’s important to isolate these ideas from actionable work.

Fill this ticket with details. Who asked for it? How should it work? Why do they care? Is there any way they’re currently working around it?

Stay high-level; we want to “Keep the clay wet” with an artifact that captures the spirit of the idea but doesn’t over-prescribe the implementation.

What if you don’t document? That’s fine. Good ideas come back around. It’s up to management to revisit this list of features and decide which ones to build.

Follow-Up (Optional)

If the feature gets built, let the customer know. This is a “Nice to have”— often time passes and it’s hard to reconnect. I’ve almost never seen this done in practice, but if it’s something you want to try to do, go for it.

Conclusion

I’d like to give credit to Shape Up by Ryan Singer; it gave me a language for these and other product lessons I’ve learned.

That’s it! You’ve listened, shown gratitude, documented, and maybe followed up. Great job.