Take the time to define “what does it do, and for whom does it do it?”

I think there's more to it than this -- it's an issue of managing expectations. and knowing your audience.

Many programmers aren't willing to roll out without the full functionality, for fear they'll be forever judged by first impressions. (and I admit, I've done it more than a few times) For many larger projects, you need to get some of your intended audience involved early, and have them test incrementally, rather than to tell you that the whole thing sucks 2 weeks (or 2 days) before you're supposed to go live with it. Giving them a chance to interact with the system early and make recommendations can help get their buy-in, and they can champion the project to their peers.

You need to really know what it is that people want from the system, and be realistic about what you can deliver given the resources available. If there's something that people really want, but won't be available 'til version 2.0, let them know, and let them know early -- you don't need them badmouthing they system because it's missing some (seemingly minor) functionality that they really wanted. If there are things they truly need, then you either need to make sure it gets into the first public release, or only roll it out to a subset of the audience that doesn't require that function. (which means it also has to play well without whatever systems already exist, and hopefully, people won't have to keep switching back and forth between the old and new systems)

Programmers need to talk to their users -- they know what they want, normally. They might want stuff that we can't give them, but they can let us know what is critical for their work. If we don't understand what the purpose of our systems are in the larger context of their work, we're doomed to fail.