This person appeared to make hardware manufacturing applications (like CNC machines). In my experience with software like CRM there's a nuance to which domain k

This person appeared to make hardware manufacturing applications (like CNC machines). In my experience with software like CRM there's a nuance to which domain knowledge is important (but I presume also financial software, and to a lesser extent ERP). My experience is more with CRM. In these cases, domain knowledge is still important, but it's more about the curiosities around how a specific sales/marketing/customer support team is structured - how do they divide up leads? Do they compete with each other within the team or are bonuses given to teams? Usually these decisions are informed by domain knowledge. E.g. the customer support of a boutique expensive watch brand would be more of a concierge service (with tickets requiring immediate attention - a delay in response could represent a big loss in sales), while for a mass manufacture cheaper line it would have more of a volume of tickets and human response times might differ. Escalations would therefore need to be programmed differently. To give another example, I can imagine seasonality having a huge impact on how a financial team want their software programmed, and that is informed by domain knowledge. But knowing how watches are made wouldn't help me with understanding 'domain knowledge'. I need to understand how they are sold. The domain that I need to understand is 'how does this sales team work' not 'how does this product work'. I guess what I'm saying is the right kind of domain knowledge to match the task.