When and How to Learn More
Perhaps it's essential that development teams first master practices such as test-driven development, continuous integration, refactoring, acceptance test-driven development, test automation, and so onand worry later about a complete understanding of the domain. After all, by using tests at the business-facing level as well as the unit level to guide coding, and working closely with customers throughout each iteration, a team can be pretty successful at providing the business with valuable functionality.
You can't do or learn everything at once, but it's probably important to be aware of what you don't know yet. Even if you have a crack development team that excels at testing and coding, beware of having a false sense of confidence. Only when you know your business inside and out will you realize how much better your team can support it with software.
Next time you meet with a customer to talk about a feature or piece of functionality, broaden the conversation. Ask not only for examples of how this particular feature will be used, but how it fits into the larger picture. What manual processes accompany it? Does it affect another system, or vice versa? A deeper understanding of the business problem you're trying to solve can pay off big in the long term.
I've heard of development teams that physically moved so that they sat side-by-side with their customers. I've also talked with teams whose customers are scattered around the globe; since they can't sit next to the user, they designated technically-savvy domain experts to act as customer proxies, empowered to make the quick decisions vital to efficient software development. However you accomplish it, work with your team to find creative ways to understand your business better.