How do you organize your backlog/roadmap/tickets/feature requests?

I regularly review my priorities. I'm a fan of Intercom's RICE system — reach * impact * confidence ÷ effort. I find that, when left up to my own intuition, I underestimate the importance of quick wins (effort) and the percentage of users affected by my feature (reach).

Having a spreadsheet to organize requests is critical. You need some way to sort them by all of the different dimensions that matter. @csallen mentioned RICE, which sounds great.

For Complice (https://www.indiehackers.com/businesses/complice) I started with B×D÷C (breadth*depth/cost) which is basically equivalent but missing the "confidence" parameter. BDC came from Geoff Ralston's blog (http://blog.geoffralston.com/startup-priorities)

• Breadth = number of users affected, on a 1-10 scale where 3=30%
• Depth = how much they're affected, on a 1-10 scale. I square this number before multiplying, because that seemed to make more sense
• Cost = how long it takes to implement. as an indiehacker, I estimate this in units of pomodoros (25-minute work blocks). You might prefer hours.

However, a few things emerged as I used this over the year.

One was that there are dimensions that doesn't capture. I've probably added too many but now I have extra bonuses for whether it affects marketing, onboarding, churn, or reactivation, as well as two additional components:

• how many users have asked for this? which matters separate from how important it is, because users get happy when I can message them and say "I implemented the feature you asked for!"
• how embarrassed do I feel that I haven't done this yet? which is a good check for things that on one level would have a "small" impact but make the app look less pro

The other thing that was vital was recognizing that it's easier to underestimate how long something will take than overestimate it, which prompted me to adjust the equation so that it adds 1 pomo to the "cost" parameter before using it as the denominator. This means that I can still honestly say "yeah I think I can probably fix that bug in 20 minutes" but it's not weighted as such an important thing". Once I did this the sort felt a lot more appropriate.

I also include a "realm" field so I could focus on a particular area for a day and do a bunch of little things.

What I love about this is that when users send in requests I can say "I'll add it to the list" and then whereever the list sorts it is where it goes, so even if the request ends up right at the bottom because I feel like no other users will want that (although that's of course an assumption I'm making!) I still have added it to the list.

And I have the spreadsheet comment-on-able here, and I've shared it with a few users but it isn't actively linked anywhere on the site.

https://docs.google.com/spreadsheets/d/1scpSYCTvZ8bUra09EnIPIypSwkXGvaYINDfr4M4zJD4/edit#gid=2052322474

For tracking my short term & long term plans, I use Trello. One column for 'this week', a couple of other columns for ideas/short-term features/technical improvements, doing, done. I pull from the other columns into 'this week' every Monday, and go from there.

Trello like this is simple enough that you don't get distracted reorganising things, easy to quickly add new ideas to when things come up, and flexible enough to attach screenshots/checklists/github issues/whatever to issues as you need.

For feedback I use github issues, as my product is targeted exclusively at developers. I've got a specific feedback repo (https://github.com/httptoolkit/feedback), and users can post issues in there, and leave 👍 or 👎 on issues to vote for things they care about.

The Github part of the implementation might not work for you, and I'm still playing with the details, but I would definitely recommend separating your personal planning tool from your feedback tool. Feedback is very important, but that doesn't mean your users' priorities are exactly the same as yours! Having a clear split and using your own judgement to connect the two works nicely for me.

https://freshdesk.com/ for customer support.

https://aiveo.ca/ for bug tracking, feature requests etc.

Both the above have free plans for small teams.

• Trello, MailChimp,

For my team of 3 at https://getgreenline.co, we still use Trello even as projects and requirements have gotten more complicated. Early on, we didn't have a choice of which tasks to work on, as server fires and urgent customer requests dictated what we worked on at any given day.

However, now that we now have the luxury of deciding what would be the best feature to work on, I found that using Trello's Calendar power-up has been the single best productivity booster. There's nothing like putting a due date on each card and laying them out day by day for the team to work together on.

Assuming you are software-centered, I would suggest you to check any of the Git web-services such as github, bitbucket or gitlab. They all handle (although in slightly different ways) issues, projects, etc. There are some great resources to learn, like the Open Leadership Traning from Mozilla...

• tool: gitlab ( in the past Jira and redmine), self hosted, with milestone of two weeks, labels and focus on what to do in this milestone
• every day, to be sure to do urgent&important task first
• using issues in gitlab with specific label, moved to a special milestone, then reviewed once a week and planned to corresponding milestone

note: in the past Jira a lot, great tool, improved a lot in years. Also Trello, maybe suitable for small projects but with gitlab it'is right complexity for me.
And absolutely no email, chats, voice etc.. all must go to an issue and be written, so can be share with all the team

Currently using Jira & Confluence

As for my current setup: for the past 2 years of so, I've been developing and maintaining an open-source browser addon for Pocket users, In My Pocket https://inmypocketaddon.com/.

I've been using Trello as my main hub to keep :

• A public roadmap of the project, so that users know what's going on. It's completely disconnected from my other "working" boards.
• A private backlog of everything I could implement someday,
• A private "development" board, with the tickets I work on for the current/next release cycle. When I want to work on a new feature, I move the Trello card from the backlog to this "work in progress" board. Everytime I commit some code to the project, I reference the related private card.

I often receive feature requests or suggestions from users by email, or through store reviews. I keep track of them on my backlog Trello cards.

I also receive feature requests or bug notice through the bitbucket issue tracker... and not sure how to deal with them. I typically add them to my private Trello cards and close the issue, but my private Trello cards are hidden and users can't know if I intend to deal with their feature/issue.