3 ms·

Something simple like Wunderlist or Asana is a good choice, IMO. The less time you spend dealing with your PM tool, the more time you can spend on actually doin

Something simple like Wunderlist or Asana is a good choice, IMO. The less time you spend dealing with your PM tool, the more time you can spend on actually doing important things. I've also heard this argument if you're running a product, though I'm not sure how on board I am with it: don't record user requests. The important ones will be requested enough that you'll remember it.

win_ini 11y ago
The important ones do keep making it to the top - it's important to have the pattern recognition and telling others that even though we're saying "not now" for a feature...that can change if it comes up more and more often. The hard part is that people don't tell you when the issue occurs again because they "know you already said no to that..." It's a tough line to follow. I direct all feature requests go on a list that CS owns and we review it with our customer team, vp eng, myself and qa in a weekly meeting. We talk about the problems, get shared understanding and we collectively agree if we can say "not now". "Worth looking into". "This is easy let's do it now". "This could be tough or easy - needs more info". This is basically what partly feeds a short backlog (~20 items) that gets prioritized during sprint planning. Plus longer term roadmap stories. Roadmap - a ppt with: Next 3 months (most detail) Next quarter (high level, use cases identified) Next Half (broad themes)