It is a bit sad that people have to be taught this;
I am presuming the product people are a kind of humans too.
But when I see their outputs, maybe this Christensen guy is right.
I tried to adjust the background image on microsoft Teams video calls this morning; the UI I had to use or rather figure out, to achieve that, was a major depression.
(1) the settings menus in teams are well hidden, for reasons unclear to me().
(2) but the _actual_ settings you need are hidden unless you START a meeting call.
(3) but, the _actual_ settings are a long chain of ".. but are you sure you REALLY want to see the ACTUAL settings?",
where you must continue to click 'more settings', 'advanced settings', 'full actual settings' (I am paraphrasing.)
() I suspect what they are though..
Something about dumbing the UI down to the level where
the people in charge of teams can understand them,
plus some kind of fear of UI designs where any given screen or view
contains more than 1 or 2 elements (the second element being "show further settings").
We are dumbing down UI to the level of people with no hands, no eyes, no brains,
which I presume is the target audience. I must have mah minimalism.
The thing I find the most hilarious about all these companies jamming llms in all over the place is that they don't ever put it where it makes the most sense to me - to manage the settings.
They could do away with all these mazes of settings and configurations and just have a little chat thing. You pop open and then tell the AI hey I want to change the background and then it just does it. You could have a huge and complex array of settings that would be a headache to navigate in a typical form format, but a breeze with an llm that has an API into them.
As an aside, another one that I just find hilarious is the LLM implementation into Google sheets. I'll ask it. "Hey how do I do this?" and then it goes "I don't know" and I'm like WTF why is this here
The problem I tend to see is that companies say they're doing JTBD research, but they're actually just running attribute preference surveys (asking customers to rank features, from a list of things the company would like to build, rather than starting off by assuming you don't know what customers require).
Listening to what people say they want (feature preferences) almost always diverges from what they actually want the product to do (a functional, emotional, or social outcome). That gets more complex when we think about that there's different levels by which you can evaluate what someone wants, which in the JTBD word are thought of as jobs as progress (why they're doing the thing), and jobs as outcomes (how they're doing the thing). There's another famous example, which is from Bosch's circular saw evolution. Professionals said they wanted lighter tools (and that's true), but the constraint they experienced as a result of weight was the impacts that had. So you can solve for weight, or you can solve for improved usability. Symptoms vs causes sort of thing.
This is also why product teams should involve marketers, and why marketers should understand research design. The teams who I've seen do this well at this aren't running quick preference tests and A/B tests on features most of the time. They're generally more focused on running continuous feedback loops, where they conduct broader research, then engage in grounded theory style interpretation to understand what they can do, look at field validation to figure out what they should do, and then iterate.
For B2B especially as a side note, if your value proposition is something like accountability or proof of value, but your product's workflows don't make accountability or proving value effortless, fixing that workflow will do more for brand perception than any campaign, because nothing nukes good comms like a poor experience.
>Professionals said they wanted lighter tools (and that's true), but the constraint they experienced as a result of weight was the impacts that had. So you can solve for weight, or you can solve for improved usability.
"I want a lighter hammer, smaller bags of concrete, etc" Drake turning away --> "I want a heavy hammer with a long handle, and big bags plus a dolly/block & tackle" Drake nodding in approval
This example is always cited as different from the "demographics" approach. But it literally started by segmenting the buyers, and then focussing on a previously unrecognised demographic sector (car commuters).
Clay Christensen is smart, and one of the many things he is smart about is marketing Clay Christensen.
Marketers would call your car commuter segment an "occasion." Perhaps more than finding new demographic segments (age/race/income/etc), food bev & QSR look for novel "occasions" like car snack, desk grazing, pre/post-workout, airport indulgence, social apertif, etc to drive sales growth
(One might also think of "functional foods," "mood boosters" etc which are neither an occasion nor a demographic. Perhaps these in particular are closer to a true JTBD)
The problem with general surveys is that you find out what people who don't buy your product think that they might like. Then they don't buy your improved product either.
A second problem is that we're unaware of what we responded to. That's one of the things that A/B testing reveals.
This echoes my experience. I can't sit down at a computer and start doing a new thing with a browser with 15 tabs open from the day before and expect it to go well- it's like waking up and walking right into a room with 5 stereos playing 5 different songs at once and trying to practice guitar.
I'm a big fan of JobsToBeDone, but partially because of this milkshake example, it took me years to grok.
As I see it, the milkshake example isn't about innovation, it's about actually having human-to-human conversations with customers and appreciating customers define their own competitive set, so perhaps closer to Gibson's "the street has its own use for things."
Outside of those two points, I'm not sure what repeatable lessons exist in the milkshake story for innovation, and because of that, it's probably doing more harm than help to JTBD as a concept.
9 comments
[ 2.7 ms ] story [ 25.4 ms ] threadI tried to adjust the background image on microsoft Teams video calls this morning; the UI I had to use or rather figure out, to achieve that, was a major depression. (1) the settings menus in teams are well hidden, for reasons unclear to me(). (2) but the _actual_ settings you need are hidden unless you START a meeting call. (3) but, the _actual_ settings are a long chain of ".. but are you sure you REALLY want to see the ACTUAL settings?", where you must continue to click 'more settings', 'advanced settings', 'full actual settings' (I am paraphrasing.)
() I suspect what they are though.. Something about dumbing the UI down to the level where the people in charge of teams can understand them, plus some kind of fear of UI designs where any given screen or view contains more than 1 or 2 elements (the second element being "show further settings").
We are dumbing down UI to the level of people with no hands, no eyes, no brains, which I presume is the target audience. I must have mah minimalism.
They could do away with all these mazes of settings and configurations and just have a little chat thing. You pop open and then tell the AI hey I want to change the background and then it just does it. You could have a huge and complex array of settings that would be a headache to navigate in a typical form format, but a breeze with an llm that has an API into them.
As an aside, another one that I just find hilarious is the LLM implementation into Google sheets. I'll ask it. "Hey how do I do this?" and then it goes "I don't know" and I'm like WTF why is this here
Listening to what people say they want (feature preferences) almost always diverges from what they actually want the product to do (a functional, emotional, or social outcome). That gets more complex when we think about that there's different levels by which you can evaluate what someone wants, which in the JTBD word are thought of as jobs as progress (why they're doing the thing), and jobs as outcomes (how they're doing the thing). There's another famous example, which is from Bosch's circular saw evolution. Professionals said they wanted lighter tools (and that's true), but the constraint they experienced as a result of weight was the impacts that had. So you can solve for weight, or you can solve for improved usability. Symptoms vs causes sort of thing.
This is also why product teams should involve marketers, and why marketers should understand research design. The teams who I've seen do this well at this aren't running quick preference tests and A/B tests on features most of the time. They're generally more focused on running continuous feedback loops, where they conduct broader research, then engage in grounded theory style interpretation to understand what they can do, look at field validation to figure out what they should do, and then iterate.
For B2B especially as a side note, if your value proposition is something like accountability or proof of value, but your product's workflows don't make accountability or proving value effortless, fixing that workflow will do more for brand perception than any campaign, because nothing nukes good comms like a poor experience.
"I want a lighter hammer, smaller bags of concrete, etc" Drake turning away --> "I want a heavy hammer with a long handle, and big bags plus a dolly/block & tackle" Drake nodding in approval
Clay Christensen is smart, and one of the many things he is smart about is marketing Clay Christensen.
(One might also think of "functional foods," "mood boosters" etc which are neither an occasion nor a demographic. Perhaps these in particular are closer to a true JTBD)
A second problem is that we're unaware of what we responded to. That's one of the things that A/B testing reveals.
As I see it, the milkshake example isn't about innovation, it's about actually having human-to-human conversations with customers and appreciating customers define their own competitive set, so perhaps closer to Gibson's "the street has its own use for things."
Outside of those two points, I'm not sure what repeatable lessons exist in the milkshake story for innovation, and because of that, it's probably doing more harm than help to JTBD as a concept.