This is a potential rule-of-thumb subjective metric for assessing how well you’re directing your software development resources:
Does your code read like your conversations?
What this means is, does the code you’re writing overlap closely with the conversations you have about the product and the problems it solves?
For example, if you talk about “free month of foobar with the XYZ subscription”, then it’s probably a good sign if those words appear a lot in the code. Hopefully there are classes and functions that overlap with that.
Code that reads like your conversations is a sign that you’re solving close to the problem domain and focusing on what your users care about.
Similarly, it’s probably a bad sign if the code does not overlap with the conversations you have about the problem domain and its solutions. For example, if the code seems to be focused on databases, queues, disks or other technical concerns that your users don’t care about, then it might be a sign that you’re focusing on the wrong problem domain.
Of course, those things are the problem domain for some users, in which case its natural that they’re the focus. But for most products they are not, and then the language around them becomes a hint that something is not aligned in the development of the product.
This is summed up in The Pragmatic Programmer:
“Program Close to the Problem Domain: Design and code in your user’s language.”