This session talks about how to understand your customers – how they’re behaving, how capable they are of learning and changing, how they make decisions, what they care enough about to pay money or attention to fix. It’s not easy.

In this article, Demetrius Madrigal and Bryan McClain explains why you should not take user feedback or requests for design changes at face value.

Software development teams use the word “customer” a lot. But there are different kinds of customers. Being aware which kind of customer you are talking about can help you to deliver better results. This post explains the difference between two kinds of customers: the ones using your product and the ones who will buy it. You will need to satisfy both, to be successful!

As he is responsible to create the requirements, we set the customer as the sole owner of the definition of success. Therefore, we force the burden of success onto the shoulders of the very person who has come to us, the software developer, for help. If that isn’t evil incarnate? This post is about the fact that in the hands of a master software developer requirements are both carrot and stick.