BY CHAKRIT LIKITKHAJORN
A few weeks ago Rachel Burger, Senior Content Manager at Capterra wrote about Taskworld:
“If Steve Jobs were to make a minimalist, effective to-do application, this would be it. ”
This made us really happy because we never wanted to compromise on simplicity for the sake of more features. In fact we believe that the two aren’t mutually exclusive.
Putting feature requests directly in product roadmap isn’t enough. You need to understand the root cause of the problem. Users are good at identifying problems but solving them is your area of expertise.
How we evaluate features
Every startup sometimes gets negative feedback on new feature release.
The leads to startups asking some tough questions to themselves.
Should we continue to refine the feature or should we just completely drop it from the product? Did the feature fail because of bad execution or is the entire concept completely flawed?
At Taskworld, we too face these questions from time to time, and it’s always a challenge to answer them, but this is what we have learned to help figure out if the feature is worth more investment.
Create your target personas
At Taskworld, we have 3 user personas, Jeff, Ben and Linda. They are part of our everyday life, quite literally.
Each persona has their own specific characteristics. Ben is the CEO who wants the big picture, Linda wants to manage her team well and Jeff is a creative worker who just focuses on his own to dos.
So how does this help? Let’s say if we develop a feature for Linda persona and the feedback from our customers is not positive, We can probe if people displeased with the feature match Linda’s persona.
If Lindas love the feature but Jeffs feel overwhelmed by it, then the problem is not the feature itself but user experience. In that case, we should not present the feature to Jeffs in the first place. As a result we will hide the feature away from the main screen so that it is only visible to those who want to access it. This refinement will keep the app clean and make the experience better for all personas.
On the contrary if Lindas don’t like the feature and don’t use it at all, we can be certain that the underlying assumption is completely wrong. It’s time to go back to the drawing board.
Features don’t sell, solutions do
It’s easy to believe that adding new features will allow you to sell your app at a higher price. However that’s not the point of having a feature set.
Features are meant to solve problems.
Sometimes feature requests can be solved in a completely different way, leading to a solution that exceeds user’s expectations.
Let me give you an example:
Taskworld, the way it is today is a direct result of user feedback. A year ago, it was a simple kanban tool. A lot of our users requested integration with Slack. After all communication is essential to task management.
However we didn’t directly jump to a conclusion and started working on Slack integration. We studied Slack’s integration with other task management tools and found it below par. It involved separate tabs and the experience wasn’t seamless.
After investigating a bit more, we realized that our users wanted a built in chat and didn’t care too much about a specific app. As a result we started working on a native chat experience in Taskworld.
Taskworld chat became immensely popular and still remains one of our most defining features.
So, here are our key takeaways at a glance:
- Simplicity is the most important feature.
- Don’t blindly follow every feature request, try to understand the root cause of problem.
- Make sure the feature is tested by the right target persona.
- Know when to retreat and go back to drawing board.
So, how do you organize feature requests for your product? Let us know in the comments below.