Understand The Problem Domain

As mentioned earlier, you and your team are the experts in making software, and the customers are the experts in the thing that the software will do. I've cautioned against using that distinction to build the software you want rather than the software that the customers need; should this be taken to mean that the software people stick to software and the customers stick to their problem domain?

No.

You need to know what you're building for, so you need to have some understanding of the problem domain. Yes, this is asymmetric. That's because the situation is asymmetric – you're building the software to solve a problem; the problem hasn't been created so that you can write some software. That's just the way it is, and compromises must come more from the software makers than from the people we're working for. The better you understand the problem you're trying to solve, the more you can synthesize ideas from that domain...