Bram has hit the nail “right on the head”:http://advogato.org/person/Bram/diary.html?start=97when he says that what users actually want in software and what they actually ask for can often be two completely different things. Most of us who have developed software have probably come across various forms of user driven software design. The central principal behind such development processes is to sit down with your prospective user and work out what they want, such requirements being detailed as Use Cases, or Stories (in XP parlance) or whatever. What people commonly forget is that recording what the user says they want is not really the job, its about working out what they actually want and helping them understand this. Never let your marketing department gather user requirements – you’ll end up attempting to deliver a product too soon packed with fancy features that don’t actually address what the users real requirements are. Don’t let your manager do it either – every added layer of communication between the developer and a user is an opportunity for miscommunication. I know it can be a drag, but making the effort to develop a meaningful business relationship with your user can drastically reduce the chances of feature creep and can help produce software that the user really loves. And a happy user is more likely to be a repeat customer after all…