How to Write a Feature Request That Actually Gets Built
The short answer
A feature request gets built when the product manager can see the problem behind it. Say what you are trying to achieve and why it matters, then explain why the obvious workaround does not solve it. Those few extra seconds are the difference between a request that gets prioritized and one that sits in a backlog.
Why Most Feature Requests Go Nowhere
We all know that when building digital products, feedback is extremely valuable.
The Lean Methodology often talks about shipping MVPs, listening to feedback, and iterating. The issue is that the average user isn’t trained on how to provide feedback in a way that makes it easy for the receiving Product Manager to understand the problem, prioritize it, and get it actually worked on. This can be frustrating on both sides - users don’t get their ideas worked on, and Product Managers aren’t getting enough information to be incentivized or prioritize the idea, and all it took was a bit more information when providing a feature request.
I’m sure you’ve come across feedback forms in many products you have used and love. Here’s an example of a tiny box from Fathom, a growing AI meeting notetaker.
Spotify has a more built out feedback system, built around their community. It’s a forum where you can see if your idea was already submitted and you can upvote ideas, which reduces duplicates, and adds more data to ideas.
Canny takes this idea further, building out a full product for a feedback system that any company can add.
As Product Manager’s, we review these ideas all the time. They often come in as “I want a way to listen to all of an artist’s songs”. Sometimes new Product Managers don’t know the whole system too, so they understand the idea, but not how painful the problem is, how frequently it occurs, and what workarounds are at disposal to the user. They need extra steps to chase that information down.
As a user, it only takes a few more seconds to make your idea more likely to be worked on. Imagine being the receiving Product Manager, pitching the idea internally. Here are some aspects that would be extremely helpful.
Fathom’s feature request form
Spotify’s feature request form
1. What You Are Trying to Achieve With This Feature
I want X, so that I can do Y, so that I can do Z…
This is the classic why you need this feature. You are uncovering the core problem. For B2B Products, it might even be how it is impacting your bottom line. Sometimes, a Product Manager is just guessing what this is, so by including this, you are giving way more insight, and even letting the Product Manager empathize with your situation. They spend a few more seconds in your shoes.
2. Why the Workaround Does Not Solve Your Problem
A Product Manager may dismiss an idea because they believe there are workarounds. As a user, you have to show why that workaround is not sufficiently solving your problem.
Here are some improved examples of feature ideas:
For Spotify, I am saying why I want this feature. It’s going to let me discover more artists and songs. This is in the best interest of Spotify, I helped connect the dots, and the PM has an easier time prioritizing this idea. I also mention why the workaround, the “This is Artist” playlist, fails, if the PM didn’t know about this.
For Fathom, I am explaining that easier skipping will save me time if I am reviewing an entire video. It is up to Fathom’s PM to decide maybe they don’t want to do this, because they’re focusing on showing highlights which reduces this need. But I showed them I have a use case of reviewing an entire video, that perhaps they didn’t know about or know it was that frequent.
Spotify feature request
Fathom feature request
Submit More Feedback
We hope to nudge feedback submissions in this direction for the whole system to run more smoothly. This will result in higher quality products with a bit of extra time and thought.
If you are on the receiving side of this, collecting requests rather than sending them, the product readiness assessment is a quick check on where your product actually stands.
Thoughts?
Submitted a feature request recently that you can’t wait until it’s built?
What did you write in the request itself?
Anything we missed?
About the Author
Hi, I’m Ryan.
I’m a Technical Product Leader that has built and scaled products that have positively impacted millions of lives.
I run Rigoris Digital, where we help high growth companies navigate product strategy, UX/UI design and development.
Common questions
Two things beyond the feature itself. First, what you are trying to achieve and why it matters, in the form of I want X so that I can do Y. Second, the workarounds you already tried and why they are not good enough. Both give the product manager something to pitch internally.
Usually not because the idea is bad. A request written as a single sentence does not say how painful the problem is, how often it happens, or what the user is doing instead today. Without that, the product manager has to go and find it, and most requests do not survive that step.
Yes. A product manager will often park an idea because they believe a workaround already covers it. Naming the workaround and explaining exactly where it falls short removes the easiest reason to say no.
It does. Forums like Spotify's community let you find a request before you file a duplicate and add your vote to it instead. That keeps the signal in one place and gives the product manager real demand data rather than scattered one-off asks.