Go-to framework for prioritizing features based on feedback
Issue 17 πͺ: How to consider building features based on feedback + Adding new features is not going to make the product better.
Hey everyoneπ, welcome to the 36th newsletter.
As my product was growing many users start giving me feature requests. In fact, I wanted this to happen because I was building the product for them. Initially, the product roadmap was different as it was heavy on what I thought would be the best fit for the product in long term.
And to make the users happy I created a huge list of backlogs that every time a user requested a new feature. The difficulty arises when you have no idea which features to give priority. If not done right, it can quickly turn into a mess.
Most of us need more discipline for building and adding features to the product. Because thereβs nothing more wrong than building an inefficient product.
Hereβs my simple go-to framework for adding features, it doesnβt necessarily need to have everything but I consider these points:
Iβll wait till many people request a similar feature.
Build a prototype, let everyone try and see for how long users use it.
Prioritize features based on the revenue it brings.
Following my guts that this feature request can improve the product in long term.
Each feature should be taken by understanding its role. How impactful the feature becomes once added to the product and how a feature will improve the product. The product shouldnβt bend towards how perfect it looks instead it should connect by solving the right problem.
Knowing if the feature is worth pursuing?
Factor the list of ideas in 3 ways:
Strikeout features that you have planned to add and your users also asked for. If you can add it fast, then do it now. You can do it by conducting customer interviews and satisfaction surveys.
Features that your users want but you havenβt thought about it. Try to find out all the possible ways they will be using it & if it connects with the core problem.
Features you have planned to add for the long term vision.
Prioritize adding feature
Keep your decisions based on actual testing/reality than filled with emotion, see whatβs improving your product, helping you build a brand identity and keeping the users happy. Kill the idea that doesnβt weigh on the overall product, itβs better not to have an underperforming feature.
Now, there are two types of things to avoid most of the time:
What you think will look good but doesnβt connect with the overall business goal.
What an unhappy or free user is asking for which is far from the original problem.
When you question your users about what features they want, most of the time theyβll have a list. Try to figure out how a simple feature can work with the core problem. Your job is to stay away from irrelevant things that donβt affect the core problem youβre solving.
Understand why a user is asking for a feature
The first and foremost thing to do after a user requests a feature is to engage with them. Itβs mostly true, a user will ask for a feature and you should follow up by asking why they need it. How will it improve their experience using the product? How is their life without that feature?
Asking direct open-ended questions will give you insights and an understanding of the problem space. Customers usually donβt spend the whole day figuring out the solution to the problem but they do know their problem very well. You have to try to spill the beans out and guide them to the solution.
What Iβve found, on a scale from point A (happy customers) to B (unhappy customers), the further the distance of an unhappy customer to becoming a happy customer, the more likely they are to ask for features that are not worthy for your product or are out of scope.
The definition of unhappy customers is different all the time. Some might be unhappy because what they were looking for isnβt what your product offer. Some might be comparing your product with different alternatives in the market. Some might have newly faced the problem & donβt know whatβs best for them.
Psychology for a new feature to succeed
If you want to make your new feature a successful event, try adding creative emotions to it. Donβt just look at how youβre going to solve the problem through your product rather see how the audience is emotional with it. How do they feel, what are their desires?
Letβs say, you order food online, and you track on the map how far it is, how long will it take and when will it arrive. You can see itβs moving. The key insight here is people hate not knowing where their order is. The map keeps their anxiety away and makes them powerful with complete transparency.
Each time I use Figma or Webflow, it keeps me at ease that I just need to drag & drop to build something & donβt have to download it on my desktop to access it, which makes working with it very each.
Experiment to understand the requirement better
Experimenting doesnβt go to waste, you learn, move on, find a better fit and hit for bigger opportunities. The thing is, once you have an idea, build a prototype and test it. The outcome will give you if the idea is worth pursuing. I have 2 ways to work on the features:
Integrate with whatβs already out there. So, I can see if that feature will actually be useful & if in future I should build with-in. Ex - integrate with other note-taking or to-do list apps.
Build a smaller version (MVP) of the feature. Ex - have just a section where users and add a few lines as a note.
I keep a rule all the time: Consider adding a new big feature only when there is an increase of 15% of new users from the last added feature.
This way I also know Iβm not adding features without having enough people to use it.
When you measure how each of the features performs, donβt measure it through how many features youβve released (input) but rather what outcome did it bring. Did the feature help bring new users by 15%?
When you try to set feature goals, think about the overall business goal and how it will help the product vision. When you stick to these, youβre more likely to avoid getting distracted by adding unwanted features or just blindly following what the users want.
π¦ Tweets
I wanted to share a lot but letβs keep it to a few.π
π PS: Iβm Ritika founder, product marketer and advisor for early-stage startups, find more here or connect with her here. If youβre a first-time founder looking for curated resources, download here. If you enjoyed this post, read the past issues here. You can also promote your product in this newsletter.
A big thanks for reading & sharing!