[nikhilbagadia]

This reminds me of canny.io

We decided against using it because given an option users might vote on features but unsure if they actually want a particular feature or not.

Worried about false positives distracting us, we decided against it.

However, I know a ton of products who still use it and they are happy with it.

[sonio]

Yes canny is more portal based whilst Sleekplan is more focused on a widget basis, you can interact with via $sleek SDK (so that it feels more integrated)

I am totally with you when you say that there is a chance that feature voting will backfire for the whole process. It depends on how you use it.

1. You shouldn't rely on up- and downvotes for feature priorisazion for example. Like I did for "impact scoring" at Sleekplan you could use factors like interaction of users, time staying on an item.

2. You shouldn't ask for solutions or features, You should ask for problems, issues missing functionalities and then collaborate (e.g. in the comments) to find a good solution that's satisfying everyone.

I currently writing a best practice (from my point of view) for the Sleekplan docs.

But having been in this orbit for some time I think that's simply a function of how teams want to handle feedback requests since everyone's needs are a little different.

[varlogix]

I agree to some extent. Unless you can filter the feedback based on the level of the user (plan, MRR from account, user engagement), it can result in some lower importance features being built. Also, making the roadmap public reduces the product team's flexibility to an extent.

[sonio]

Right, but these filters are not quite trivial. How would you filter (MRR by Upvotes, MRR by comments and subscriptions or all). I think it depends, that's one of the reasons I have implemented an impact score combining MRR, user engagement and so.

It's just more simple to filter. Therefore, a feedback item with 10 upvotes can have an impact score of 40, while a feedback with 100 upvotes can have an impact score of 3.