One of the questions I’ve been asking myself recently is: So how do we validate the features we’re adding to our roadmap?
It’s become clear to me why it’s important to understand what the user need is, and then solve for that need. But, the truth is that there are thousands of ways you can solve one problem. How then do we decide on the feature or features that will optimally solve the user’s problem?
I don’t just mean optimal for the user, but optimal for us developers too. Put another way, the quickest, cheapest, and easiest features that can deliver the greatest value; against the features that give the user the most value, usability, efficacy, etc.
Methods to filter generated features
Method 1: competitor’s features
An obviously good starting place is by looking at the way competitors are solving the problem. The advantage of this is that you get an understanding of exactly how this new feature could work and contribute to your product.
The disadvantage of this method is that we can easily fall into the trap of comparing apples with oranges. The feature may work exceptionally on the competitor’s product, but not work for your product, brand, or audience.
That’s why the method of testing the competitor’s feature with your audience can be extremely effective.
Method 2: features of apps you’re using
The second method is to reflect on the apps you’re currently using, especially the ones you recently started using because they will likely be the freshest in memory. For example, one of the more recent apps I’ve used was Zapier. I have already written a post about it here, but it’s worth highlighting a few things in this post:
- I started using the app after a recommendation from a leader. They said it could be an effective solution for our operation automation. Put another way, I didn’t go out of my way to select the app, it was more a convenience thing (How did you discover the app).
- My first impression of the app was “wow, this is new” but the interface was extremely straightforward. The app’s learning curve is extremely small, which I really appreciated (How was your first-time experience)?
- As a result of the ease of using the app, I had no reluctance to go back to the app on multiple occasions in the future. (Did you go back to the app again?)
Questions to ask yourself
- How did you discover the app?
- How was your first-time experience?
- Did you go back to the app again?
These are three questions that can be used while doing this analysis on any other app.
Why this method?
The advantage of this method is that it gives you the ability to use the first-principles approach when deciding whether or not a feature is appropriate for your product. So, as opposed to seeing a feature on another app and simply deciding to use it on your product because competitors are using it, this method gives your the ability to take a step back.
Rather than saying, we’re going to add an error message under each incorrect input entered by a user (random feature example), this method gives you the ability to say “we’re going to add an error message under each incorrect input (as opposed to listing everything at the end of the page) because this gives the user the ability to associate the error message with the information entered.
An explanation allows you to discern whether the feature is appropriate for your specific product or audience. For example, if you know that all your users use a desktop and can easily see each of the error messages without having to scroll back and forth (potentially making it easier for them to associate the input with a specific error message), then you would be able to discern that this feature is not relevant for your app or website.
Read the post shared by Liesl Hammer on LinkedIn that inspired this post here.
