Misconception of JTBD and product fractal
JTBD is not only terrible phrasing of the idea but also a so misleading term. Correctly put it would be something like ‘smallest possible, but still valuable enough for the users to pay for it JTBD’.
Also, the features (implementations of JTBD) have the same attributes as the product that have these features. So it is a kind of fractal structure that reproduces itself on different levels.
JTBD being poor phrasing and misconceptions coming from it
I was doing features backlog and trying to back and forth different ideas with the architect. He continuously replied to me ‘great idea, but we need more testable one’. So, I deducted that features in engineering perspective are something different to features as users see them. I came to my wife, she’s an engineer and asked her what is the difference between a requirement and a feature. ‘Well, there’s not much, — she answered. — it’s just features are more technical and requirements are more user oriented’. That’s a delightful turn, I thought to myself at the moment.
There’s a clearly direct relation between JTBD, feature, and hypothesis concepts in product management. Feature is something valuable enough for users they are going to pay for. Thus, the feature does some JTBD for the users. And the team makes an experiment to test are they are really going to pay for the implementation or not. When the team has got the key features implemented and relevant hypotheses validated, it has progressed in product-market fit.
But until you got there and still bootstrapping, it limits you with tiny experiments. So, JTBD is not any useful job that your product can perform. It’s the minimal useful and worth-to-pay-for task. It seems to be a minor shift in perspective, but it meant something to me. I started to look at feature backlog development from this lean perspective.
Take, for example (Bryan Jenks, 2020) video with Zettelkasten workflow. JTBD for potential Obsidian plugin for a potential product would not be parse an entire YouTube video transcript and come up with an extracted concepts and links to your knowledge graph, but extracting researchers names and generating the list with their Google Academy profiles. So, not the ‘big marketable feature’, but ‘small swiftly testable engineering feature’. Maybe call it ‘user activity quant’ or like that, because JTBD kind of misleading from the idea of lean thinking? We should keep JTBD small, but useful and constantly ask ourselves, ‘how can we make it smaller and easier to implement?’
JTBD, features, and product
But is there any difference then between product and feature? The feature must be useful, usable, feasible, and viable, so as the product. What’s the difference between these two, if we test that the customer is ready to pay for a single feature?
Well, first of all, some features are just for parity. They are mandatory just to enter the market. The second is the product is not just a collection of features, it is the thing that makes possible the whole business model. Single feature doesn’t.
That brings us the notion of misfit features, and we all encountered them. Set alone these features can be useful, but they have no room for the holistic product set of features. They don’t extend JTBD.
So, meanwhile the product team validates features very much like the whole product, still product is more than just a collection of features. Also, features are innovations in the same sense products are (Rogers et al., 2014, Diffusion of innovations), meaning features probably have the same factors that affect adoption as products do.
Besides obvious intention to take as small bites as possible at least in the beginning of the product development what are the guidelines to come up with lean JTBD definitions? I understand that they should be useful, usable, feasible, and not viable (we don’t care much about that in the beginning of course), but can we go beyond that?
How can we test small bites but still validate the big product vision with such small bites? I don’t have an answer right now.