Thanks for the kind words. They are indeed very similar, close relatives as you say. Imho here is a subtle difference though. It is related to the actual technique when you try to discover and apply them.
In many cases when I’m doing user interviews or tests people are explicitly giving feedback like: “I wanted to do ‘this’ here instead of ‘that’.” Obviously you need to ask the question “Why?” in these situations. But if you view this kind of users’ feedback from the “jobs-to-be-done” perspective, it’s more likely that it will trigger some action in you. While if you do it from the “problem” perspective you’re likely to overlook this.
Besides this viewing things from the “problem” perspective usually results in creating user stories, those tend to get far away from reality. In case of the “jobs-to-be-done” perspective you’re more likely to create job stories which are bound to the actual user feedback and causation is encoded in them.
So you’re right they are close relatives, but it’s better to be aware of both. Jobs To Be Done is more of a framework that I prefer to use, because you can tie it through the whole product development process.