> you have to talk to users... that should be done on your schedule, not on theirs (most of the time) so that when you are done talking to them and you have a g

> you have to talk to users... that should be done on your schedule, not on theirs (most of the time) so that when you are done talking to them and you have a good idea of what to build, you can go crank out a high quality first version. I pretty vehemently disagree with this. Your users are pretty much priority #1. That doesn't at all mean "keep your phone on at night so you can respond immediately", but you should be as accommodating as possible (within reason) to your users. > This version will be on the right track, technically: good architecture, usable performance, well-tested, with minimal bugs. This is a first iteration you can go take to users to get concrete feedback and keep iterating. Most of the time your first version should probably just be essentially tossed. Sinking a bunch of time into it inevitably results in feelings of sunk costs that means you're focused more on "how can we tweak this solution to sorta solve the problem" than "is this fundamentally the right solution to the problem?"