Deciding of features
When working with my apps, I get a lot of feedback (because I ask for it) from my customers. A big win for me as an indie developer is to move fast and implement new features quickly.
The tricky thing can be deciding which requests to consider. My two apps have a relatively small user base, a lot of the good features have sprung out from user requests, but I still want to maintain a focus. Even if you could build everything, the product would be bloated too fast, not a good product.
There will always be more feature requests than you ever can build, and time is your most valuable resource.
Types of requests
There are three types of requests as I can see it:
1. Too narrow
- Feature that needs an entirely new product.
- More or less clone your competitors
- Features opposite of the strength of your product – Your UI is so streamlined, but can you add all these options. No longer streamlined
- A unique use case
These requests are easy to decide and identify and maybe not a good fit.
2. Why didn’t I think of that?
“Why didn’t I think of that”? Great idea! If not on your feature list, add it.
3. In-between
There is also a balance of build features that your customers are not asking for. If you are not, you are not innovating. You still need a vision for your product.
- What is the use case for this feature? What are you going to solve?
- Maybe this is handy for all users? Can Every user get a value of this feature? Ask: “What are you trying to do?”
- Will more than x percent of our users get the value of this?
Never used but need to be there
And lastly, there is a separate category which is a bit special. Some features need to be there. It can be an aspirational feature – never used but looks nice in marketing: like A/B-testing. Or, it can be a feature your closest competitor has.