I agree with the notion that the customer is extremely important. I do not agree with the idea that me being amongst my team members will inherently make the p

I agree with the notion that the customer is extremely important. I do not agree with the idea that me being amongst my team members will inherently make the product more like what the customer wants. There are logical fallacies riddling the whole article, but perhaps the most important point is that it's not black or white. The truth is, I could be very close to the client AND experience plenty of flow state work sessions. It doesn't necessitate that I diminish the effectiveness of either solution. Flow state does not necessarily create sucky product. For the most part, the analogy of the Ford Focus is entirely off base. How many people go directly in the opposite direction, even with a mild understanding of the end goals and a good sense of design? A better analogy would be that it's far better to get in the F1 and head as fast as you can in 90% the right direction than piddle along in the focus. You can course correct, or perhaps the client will end up changing their mind a bit when they see your solution. Perhaps I'm missing something, but in a project discovery phase, unless the coder is completely out of the loop, it is much more effective to let software designers design solutions to well defined problems. If the failure is in that discovery phase, fix that instead of forcing your programmers to perform at less than their potential.