In agile development, the customers decide which features to implement and when to implement those features. In XP the customers organize this information in the form of story cards. Each story card is assigned a priority and reflects a feature with real value to the business. I've found however that ordering features strictly by business priority may cause thrashing in the design of the code. So, while I still consider business priority to be a very important criterion for selecting what to work on, I also have come to think that technical people should be involved in making these kinds of decisions. In particular, I believe that with some thought, feature development can be organized to encourage rapid convergence of the code. In other words, one should try to avoid a situation in which one starts building a particular piece of functionality which stays in the system for a long time and becomes embedded in the design only to introduce something much later which requires that design to be completely overhauled.
Now, that doesn't mean that one should make the mistake of developing a very general kind of design right from the start, the so called Big Design Up Front (BDUF). However, I think that customers and developers can work together to organize stories to maximize convergence. By convergence, I simply mean that the design of the system accomodates new stories so that their introduction is relatively routine and doesn't require a lot of re-design. As an example (without going into detail), the application I am currently working on handles many different "allocation methods." However, only now are we implementing stories that define more complex topological scenarios, i.e. "This thing which used to connect only to one other thing, now connects to many." From my point of view, this kind of situation represents a example of an opportunity to enhance convergence: Develop the application with just one allocation method, but make sure all of the topological issues are handled early on.
In conclusion, iterative development is the best way to develop an application and BDUF in almost all cases is truly a bad idea. The design should indeed continue to evolve as a software development effort continues. However, by judiciously setting priorities on stories, one can encourage the design to crystallize more quickly.