Second guessing what the user needs

I often say that my job is to be an advocate for the user within an organization. I shouldn't just document the tasks that the user wants to achieve, I should also push back to the development team to explain when the software presents barriers to achieving tasks.

However, how do we know what real users are trying to achieve with the software? We can make a best guess based on previous experience but, new features are new features and don't necessarily have a precedent. What then?

I've heard it said several times recently that we should be writing the bulk of the user documentation after the product is released and that we should base the tasks we document on needs identified from technical support calls.

Indeed, several large companies are already doing this.

Skype online help

This has parallels with the release early and release often of Agile and Scrum software development where features bubble to the top of a list. I get the feeling that post-release documentation will be the hot topic of 2012.