There are various ways of getting an answer to this question. In the past years, two main approaches have surfaced from the discussions on how to get outcomes defined in a proper way: While agile development is commonly used to steer the discussion about features and requirements of service in development, more and more UX designers are leaning towards formulating job stories for their services and products.
The difference between user stories and job stories
User stories are generally based on personas. Personas are descriptions of stereotypical characters that are equipped with a fictive biography and personality features, describing their motivations, beliefs and ambitions as if they were a real person.
Job stories, on the other hand, are aiming at describing the motivational and situational pain point aspects that lead potential users to using a particular digital service or solution.
Not too rarely, the discussion of the differences between these approaches results in arguments repeating entrenched stereotypes and personal preferences: "You are using the concept of 'personas' wrong.", "What do the job stories contribute that the user stories cannot cover?" and "Both are just an attempt to provide context that cannot be properly captured in a feature list." are just some of the gems you will encounter when you read through the comment columns that appear below blog posts about this topic.
The low-down
Far from attempting to settle the dispute, I've found an alternative technique rather helpful for understanding the merits and the differences of each of the perspectives. I ask the question "What is not allowed to change in each of the underlying concepts without destroying its very foundation?" From there, I can derive complementary attributes to gain a more nuanced understanding of each of the approaches.
For the case of the user stories, it is the person(a) basis, complemented with its underlying identity construct, its related coping mechanism of enhancing personal cohesion, and its task orientation towards satisfying a stable preference.
For the case of the job stories, it is the situation's painfulness, complemented with its high degree of arbitrariness, its underlying coping mechanism of pain alleviation, and its task relation towards a relative situation improvement.
We have found the jobs to be done approach quite helpful for steering away from overly persona-focused approaches.
Designing for multiple outcomes
Here at Frantic, we strive for including diverging principles and ideas, not just lightheartedly discarding them. Using any of the principles found in one of the concepts and applying them to the other approach helps us with re-aligning our perspective: "How does a user story depict the idea of 'a relative situation improvement' - if at all?" - and vice versa: "Does the job story at hand care for 'user's stable preferences'? And if so - how?"
This way we can gain a more thorough understanding of the mechanics in our thinking models.
The principle is illustrated best with this drawing that appeared in an 1899 edition of Popular Science Monthly.
The question "Do you see a rabbit or a duck depicted in the picture?" is an obvious, but a dull and boring question, as it purely aims at identifying "the right" contents of the image. Far more interesting is the moment when the user's perception switches from seeing one image to seeing the other - and back, eventually. In this split-second moment of the Gestaltwechsel, an additional information quality becomes obvious that allows us to frame our design thinking with regard to multiple outcomes.
Jastrow, J (1899, The mind's eye, Popular Science Monthly, 54, January 1899, p 299-312).
Blog