I did get the exact same gist from your original article.

So knowing that, what is the criteria used to reject proposed Jobs-to-be-Done story? Surely, we can all come up with millions of reasons…

I did get the exact same gist from your original article. Here is my question: I think that Jobs-to-be-Done involve additional effort needed to implement them, compared to the effort needed to implement the corresponding user story. User story is always driven by the bottom line — what’s the benefit to the business. If the product team that proposes the user story cannot justify it from the perspective of the benefit to the business, the proposed user story gets flatly rejected.

So knowing that, what is the criteria used to reject proposed Jobs-to-be-Done story? Surely, we can all come up with millions of reasons why this or that feature can make people’s lives easier, make them happier, etc. That’s all warm and fuzzy, but someone will have to approve the buget needed for implementing those countless Jobs-to-be-Done stories. And the harsh reality is that some of those will have to be rejected, because we live in a world with limited time, resources and budgets.

Like, seriously, where do you draw the line? The very reason why businesses had switched to user story driven development is precisely because of this ability to easily draw the line and focus on MVP. I’m not clear what’s the MVP in the Jobs-to-be-Done situation? I don’t think you’ve tackled that problem here.