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.

great breakdown. the gap between "what people say they want" and "what job they're actually hiring the product for" is something i keep running into.

one thing that helped me a lot was realizing my product wasn't competing with other products in the same category at all. the actual competition was boredom, doomscrolling, and the default state of not paying attention to your own day. once you frame it that way, the whole feature prioritization changes because you're solving for a completely different job.

the bosch example is perfect for this: you can keep adding features that address the stated preference, or you can go one level deeper and address the actual constraint. most teams optimize for the former because it's easier to A/B test.

This is all very true. I always try to push for customer interviews to be as much about formulating new hypotheses as they are about validating existing hypotheses.