Aren’t these labels (job story vs user story) just circling around the same goal of providing good context. I believe the original intent of a good user story was that the “As a…” was a pointer back to some fundamental, re-usable context about the user and the “So that…” part provided context about the motivation or job to be done. Any good PM was providing this and if they left it as a simple, bland sentence with no meat on context or supporting information, they were failing to produce an actionable spec (call it user story, job story, requirement, or whatever). So while I like the Jobs to Be Done framework, I think all this is just a rehash and re-labeling of what a good spec should provide and was where people started years back with a user story framework. A good user story/requirement has supporting context and even Agile calls for there to be some supporting happy and unhappy path acceptance criteria in the “Given…, When…, Then…” form. So this idea of a user story = limited one sentence is a straw-man argument in my view. I read this and I wonder what’s new… and I want my 6min back from Medium.