Requirements

Requirements have historically gotten enormous attention. Often when "requirements" are discussed it is related to functional requirements as opposed to non functional requirements that get much less attention. Sadly the discussions on requirements are usually about prioritization or how many you can get which is both wasteful and pointless. From a product perspective the quantity of features is not a relevant proxy for product quality, focusing on features leads to valuing numbers which decrease the focus on iteration and improvements to the critical features already in the product.

Most of the discussions I've seen from stakeholders about features are related to the less important features that aren't really needed in the product, because the important ones are already there or at least already in the minds of the team members to implement. Any external voices about features are needed should be considered and analysed with a very critical eye, commonly persons raising requirements are not representative for the main target customer and might bias your judgement away from improving what is really important.

When stakeholders have requirements you can also expect their view to be self-centered, and this is good, you can pick their brains to understand exactly what they need and why. This is not a reasonable way to get information about what or how to implement, this information should be treated as a piece in a larger puzzle. The basic discussions about what should be done needs to be boiled down to thoughts on why something is needed by a user. Once that has been deduced, then the team can start thinking about common and good solutions to patterns of problems.

No text about requirements is complete without a not on how to track requirements. And for many this means backlog management. I think that much of backlog management has only two purposes, to create a feeling of control and as confirmation that someone has been heard and that the team has considered a feature. The biggest issue is that this also drives towards quantitative thinking rather than qualitative thinking in the product. If your backlog gets big you don't need to manage it, you need to throw it all out and think about what you are actually supposed to do. When have an idea of that thing, start a fresh space for sharing thoughts on the new thing and make sure that it doesn't grow. As a final remark I also dislike the term backlog, orders yet to be fulfilled? I'd much rather have team members spend the effort in thinking and discussing the product future instead.