The CEA events team uses a combination (or variant) of these frameworks to design a “canvas” for each event. I personally use both here and at prior jobs. I’m a strong advocate for knowing your users in general, but am less opinionated about those specific frameworks.
Some thoughts on each:
Personas can end up becoming an end in themselves. You can get sidetracked into creating these elaborate back stories and forget that you’re really just trying to figure out if the widget should be blue or green. It can also be tempting to use multiple personas as a justification for complexity (e.g. because you create one feature per persona instead of one feature for everyone). But there are definitely circumstances in which you are serving a genuinely diverse audience, and it makes sense to segment the audience. I also like them as a way of encouraging focus on the most important things – you can ask how (persona) would want you to prioritize. I usually see them more as an adjunct to some other process. E.g. if you are mapping out your marketing channels, you might create one set of channels per persona.
Jobs to be done generally seem more helpful to me because it keeps your focus on what the user thinks is most important. Sometimes talking about the users pain’s makes more sense, e.g. I hire an accountant to reduce audit risk, rather than the “job” of filling out tax forms. I tend to think about pains when first developing a product (because if you aren’t solving some huge pain point probably no one will use your product) but jobs later in the product lifecycle (because people are already using your product so it’s worth thinking about minor improvements).
The CEA events team uses a combination (or variant) of these frameworks to design a “canvas” for each event. I personally use both here and at prior jobs. I’m a strong advocate for knowing your users in general, but am less opinionated about those specific frameworks.
Some thoughts on each:
Personas can end up becoming an end in themselves. You can get sidetracked into creating these elaborate back stories and forget that you’re really just trying to figure out if the widget should be blue or green. It can also be tempting to use multiple personas as a justification for complexity (e.g. because you create one feature per persona instead of one feature for everyone). But there are definitely circumstances in which you are serving a genuinely diverse audience, and it makes sense to segment the audience. I also like them as a way of encouraging focus on the most important things – you can ask how (persona) would want you to prioritize. I usually see them more as an adjunct to some other process. E.g. if you are mapping out your marketing channels, you might create one set of channels per persona.
Jobs to be done generally seem more helpful to me because it keeps your focus on what the user thinks is most important. Sometimes talking about the users pain’s makes more sense, e.g. I hire an accountant to reduce audit risk, rather than the “job” of filling out tax forms. I tend to think about pains when first developing a product (because if you aren’t solving some huge pain point probably no one will use your product) but jobs later in the product lifecycle (because people are already using your product so it’s worth thinking about minor improvements).
Especially for early-stage products I like the thought experiment of “hair on fire customers.”