User-centred approach: does it really work?

Many of us have probably witnessed functionality-driven approach failing (or not being hugely successful) because it often overlooks the actual user needs or their workflow. However, I also witnessed projects that employed a user-centred approach failing because developers failed to assess technical risks or overlooking discrepancies in user requirements.
(Also it is equally important to take corporate needs and politics into account, but I will only discuss about the user-centred approach here.)

While I believe user-centred approach is generally good, we must not forget that most users are not trained to design web systems. So when my clients tell me they need such and such functionality, I take it as a metaphor.

If you wonder what I mean, here's an example. One of my clients said 'I need three big buttons in the home page. The first one says "Customers", the second one says "Clients" and the third one "Contact". I want to make the interface as simple as possible.'
While his intention was clear, it was not the best solution simply because not all users politely enter from home page. Instead it needs to work in conjunction with a well-designed global menu. Because, if a client end up in one of the pages for users from some search result, how do they find their way around? Go to the home page? How many users actually have the patience to do that?

There was another case (sorry, this example is a bit techy) in which a client asked for various export functionality for different sets of data in order to import the data to their Customer Relations Management (CRM) system. After building much of the export functionalities, we realised what we actually needed was an API for the CRM so our web application could directly communicate with their CRM.

Clients often do know what they need, but they do not always know the best way of realising it. It is important to listen to them, but their words should not be taken literally.