Jobs to Be Done Framework Is More Useful Than Personas(medium.com)
medium.com
Jobs to Be Done Framework Is More Useful Than Personas
https://medium.com/@karti/jobs-to-be-done-for-a-camera-f5bb8c1c5316
5 comments
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.
This helps you figure out if you’re building VSCO or Facetune.
This is a perfect example of where JtbD is stronger than personas. There are lots of people who use both VSCO and Facetune. The thing differentiating those two cases is what they intend to do with a photo, the job to be done. Another simple example of this type is YouTube vs TikTok. How are the personas different?
The case for personas is stronger within a specific task, for example: iMovie vs Final Cut Pro, ffmpeg vs Adobe Media Encoder. Even then it's not the touchy feely aspects of personas that bring value, but instead the basic market segmentation.
This is a perfect example of where JtbD is stronger than personas. There are lots of people who use both VSCO and Facetune. The thing differentiating those two cases is what they intend to do with a photo, the job to be done. Another simple example of this type is YouTube vs TikTok. How are the personas different?
The case for personas is stronger within a specific task, for example: iMovie vs Final Cut Pro, ffmpeg vs Adobe Media Encoder. Even then it's not the touchy feely aspects of personas that bring value, but instead the basic market segmentation.
How’s jobs to be done much different from people just talking about what should the key features of our app be?
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.
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.
Before you can talk about what the key features should be, you should identify what jobs the customer is hiring the product to do. That anchors the discussion; otherwise you'll be talking in a vacuum about whether to build feature X or Y without anchoring it to a job the product needs to do.
The jobs to be done framework too brings the customer into the room. If we're building a photo editor, and I say, "I wouldn't use a feature that makes lips red and removes pimples", then we can talk about the job the photo editor is being hired to do, like "make me look pretty on Instagram". I can put forward my bias like "I don't care about that" and someone can counter that.
The jobs to be done framework too brings the customer into the room. If we're building a photo editor, and I say, "I wouldn't use a feature that makes lips red and removes pimples", then we can talk about the job the photo editor is being hired to do, like "make me look pretty on Instagram". I can put forward my bias like "I don't care about that" and someone can counter that.
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.
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.
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.
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.