Lots of good suggestions about questions to ask, thinking about aligning business and development needs, settings expectations with customers, giving them a cha

Lots of good suggestions about questions to ask, thinking about aligning business and development needs, settings expectations with customers, giving them a chance to pay for development and other 'what are you even doing?' sort of ideas. So instead I thought I'd give a very simple recipe and set of rules how to deal with customer requests that I follow, to try to align with this: - Never promise a feature immediately when receiving a feature request. Say "Thank you for the feedback, we'll discuss this with the development team and get back to you if there's any news regarding this" (tag the user, so you can actually do so) - Never choose to develop a feature until you've gotten at least three separate requests for it. This will help you not over-adapt to random noise, and make sure the product stays relevant to a majority of users. - Never promise a timeline if you choose to promise a feature. Keep stress levels manageable for you and your dev team. - If you have something 'up next' on the roadmap already, you may choose to share the estimate with the inquirer - but favor not doing so, and underline that it's an estimate not a promise if you do. Estimates also become much more reliable if random stuff doesn't get to jump to the top of the priority list all the time. Your roadmap is a priority queue, not a stack - Consider thinking of it as two priority lists. One is for smaller feature requests and improvements, the other for larger projects and system/business needs (e.g. refactoring, features to target new demographics rather than existing users). Not progressing on either list is frustrating for everyone, so think of yourself as a scheduler trying to guarantee progress on both threads. For example you could have a rhythm where it's ~1 month of work on one or two big projects (until completed), then ~1 week of work on smaller feature requests and polish, then repeat. This way you batch up many smaller tasks so you don't incur the cost of context switching for your dev team while they are working on a bigger feature (which typically require deep concentration over many days), you don't block major projects, but you also get to be relatively responsive to customer requests. - Remember that things take time. Your job as a product manager isn't to cater to every user's every need immediately, it is to plot a path through an endless and evolving roadmap in order to 1) Keep the business alive and prospering 2) Keep the development team productive and sane 3) Make customers happy. In that order