My thinking about user frameworks reduces to two dimensions: intentions and capabilities.<p>Intentions express what a given population of users is trying to acheive. As a designer you need to situate where your interfaces are relation to that. Jobs to be done is useful for modeling intentions in part because it expressly looks at utility from a subjective (user's or buyer's) perspective and because the metric is simple.<p>Capabilities express what the user knows, is used to, and is motivated to learn. What skills and mindset does a user bring to thinking about and working with your solution. I have found personas useful as a shorthand for modeling capabilities.<p>In both dimensions, intentions and capabilities, there is a mixture across a given target market. You can look at different products as addressing different clusters in that space.<p>From a design/dev perspective, I think about intentions as the benefit side of what we're building, features provide benefits through satisfying intentions, and the capabilities on the cost side, that features should be "free" in terms of the percieved tax that our solution levies in terms of user's effort, attention, or learning.
Jobs to be done is helpful to get a baseline understanding of what problem you want to solve. However personas and more detailed design work will help you understand your audience and their motivations. This helps you figure out if you’re building VSCO or Facetune.
How’s jobs to be done much different from people just talking about what should the key features of our app be?<p>One big benefit of personas is towards bringing the ideal customer into the room when making decisions. Comments from those involved in building the software along the lines ‘well I wouldn’t use that feature’, shift to ‘well what would Anne want?’. Without personas embedded bias of the product team remain unaddressed and undifferentiated.