4 ms·

Regarding customer feedback: As soon as you reach a certain scale, it gets really hard. For my app, I have hundreds of feature requests, and for 95% of them al

Regarding customer feedback: As soon as you reach a certain scale, it gets really hard. For my app, I have hundreds of feature requests, and for 95% of them all I can say is, that's a nice idea, but I don't have time to do it. For the remaining 5% it'll take me a year or longer to implement them. For customers this looks like I'm unresponsive. When I started out, I often added features in a few days, and customers were thrilled, but that low-hanging fruit is mostly gone now.

alexchamberlain 8y ago
I don't think customers need to see every feature they request actioned, or even actioned quickly. As long as you're shipping new features and communicate both your roadmap and with individual feature requests, I think people understand. I do, however, think you need to balance big featured with quick wins that make a subset of your clients significantly more happy.
- jakobegger 8y ago
  I'm really sceptical about sharing roadmaps. In the beginning, I often talked about planned features, and it often turned out that they took way more time than expected (one of my favorite features is in progress since December 2015). If I share a public roadmap, and then I don't deliver, people will be disappointed. So I've started to only tell people about new features once they are stable enough for testing. I don't want to build up expectations when I'm not sure when/if I can deliver.
  - zerkten 8y ago
    > If I share a public roadmap, and then I don't deliver, people will be disappointed. I agree. Your public roadmap should be conservative, or more oriented towards the type of impact you will be making. The intent of a roadmap is to communicate your focus so that folks outside know the general theme. You then have something to reference in conversations later when someone asks for something that doesn't fit with the theme. Personally I have found any type of feature and expectation discussion easier in person or on a call. I expect feedback over the internet to be poorly phrased or hostile. Expectations break down if you have any type of sales team who are prepared to offer features to close deals. It looks like you make a database management app for the Mac. If I was creating a theme-based roadmap I might choose a theme like "SQL Console Improvements". You can explain that your focus is on that area of the product, but that your focus may change in the future. When you get close to being certain a feature within the theme will be developed then publish that information. You can operate multiple themes depending on resources. This approach can also work for feedback. You can let users know that the next theme on deck is "Optimization Tools" ask for feedback on how users want to improve their SQL queries. Then when you start executing on the theme you have collected feedback that can be incorporated. The flow makes users feel involved in the process. Actually summarizing the feedback in public can be a useful community exercise for expectation setting when everyone thinks they have the most important idea.
VladimirGolovin 8y ago
I fully agree with this. I'm still trying to figure out how to approach this problem. My next attempt would be to establish a formal system for voting for feature requests (such as UserVoice or a Discourse plugin), and focus on a single top-voted feature.
jakelazaroff 8y ago
Side note about your apps: I've used Postico for a year or two now and I really love it! Great job :)
- jakobegger 8y ago
  Thanks!

alexchamberlain 8y ago

I don't think customers need to see every feature they request actioned, or even actioned quickly. As long as you're shipping new features and communicate both your roadmap and with individual feature requests, I think people understand. I do, however, think you need to balance big featured with quick wins that make a subset of your clients significantly more happy.

jakobegger 8y ago
I'm really sceptical about sharing roadmaps. In the beginning, I often talked about planned features, and it often turned out that they took way more time than expected (one of my favorite features is in progress since December 2015). If I share a public roadmap, and then I don't deliver, people will be disappointed. So I've started to only tell people about new features once they are stable enough for testing. I don't want to build up expectations when I'm not sure when/if I can deliver.
- zerkten 8y ago
  > If I share a public roadmap, and then I don't deliver, people will be disappointed. I agree. Your public roadmap should be conservative, or more oriented towards the type of impact you will be making. The intent of a roadmap is to communicate your focus so that folks outside know the general theme. You then have something to reference in conversations later when someone asks for something that doesn't fit with the theme. Personally I have found any type of feature and expectation discussion easier in person or on a call. I expect feedback over the internet to be poorly phrased or hostile. Expectations break down if you have any type of sales team who are prepared to offer features to close deals. It looks like you make a database management app for the Mac. If I was creating a theme-based roadmap I might choose a theme like "SQL Console Improvements". You can explain that your focus is on that area of the product, but that your focus may change in the future. When you get close to being certain a feature within the theme will be developed then publish that information. You can operate multiple themes depending on resources. This approach can also work for feedback. You can let users know that the next theme on deck is "Optimization Tools" ask for feedback on how users want to improve their SQL queries. Then when you start executing on the theme you have collected feedback that can be incorporated. The flow makes users feel involved in the process. Actually summarizing the feedback in public can be a useful community exercise for expectation setting when everyone thinks they have the most important idea.

VladimirGolovin 8y ago

I fully agree with this. I'm still trying to figure out how to approach this problem. My next attempt would be to establish a formal system for voting for feature requests (such as UserVoice or a Discourse plugin), and focus on a single top-voted feature.

jakelazaroff 8y ago

Side note about your apps: I've used Postico for a year or two now and I really love it! Great job :)

jakobegger 8y ago
Thanks!