I prefer to ask my users “What’s your problem?” instead of “What do you want?”.

I think it’s more interesting to ask people their problem instead of “solutions” ideas.

Cheers!

And yes the very first ipod (2001) was not a huge succes. It was a succes with the apple fanboys. But it isn’t until they added iTunes (2003) and an easy way to move songs to it, that they had the the smashing hit it is today. (So software made a big difference)

And even internally I’m sure they iterate.

The point of agile isn’t to deliver fast (i.e. concentration on new functionality while ignoring everything else). The point is quality: that is delivering what is actually needed (as opposed to what people may think they need) w.r.t. business needs and technical constraints. The main idea is that the development is empirical, driven by experience and feedback – instead of being speculative (“we know what the reality is and this can design perfectly what is to be done”) as the “traditional” methods. Thus non-functional requirements and architecture have equal place as functionality – based on what the constraints and requirements are. (Though some teams may easily forget that.) But the architecture must be agile, empirical – starting with a “simple” architecture to satisfy the top-priority requirements (based on risk and business priority) and evolving based on feedback. The failure of the “traditional architecture” that tries to design everything up-front and success of an agile one is well presented in the Smidig 2011 talk Skalere til Petabytes (http://vimeo.com/32086819).

Regarding the role of architecture in an agile team, this talk is of interest: Arkitektrollen er nødvendig i (smidige) prosjekter! (http://vimeo.com/32086722)