How and why the Jobs to be Done Framework can help you sell more, faster, and accelerate your understanding of demand.
This is a companion discussion topic for the original entry at https://commoncog.com/jobs-to-be-done-understand-demand
This is a companion discussion topic for the original entry at https://commoncog.com/jobs-to-be-done-understand-demand
Is it intentional that the article doesn’t feature a scenario without an existing product? Or is it just a case where you conduct the interview on people buying a similar product to inform what you should make and it works just as well?
2 Likes
I believe one of the goals generally is to uncover trade-offs people actually make when buying/deciding/adopting. Most (if not all) of Bob Moesta’s JTBD interviews have been about actual purchasing decisions. Based on my experience, you can probably also look at behaviors when people attempt to solve a problem unsuccessfully as well. Typically if it pains enough, they’ll hire something to get it done, and if that something does the job well enough, it usually costs money and therefore it’s a purchasing decision.
If you look at people who contemplate a lot but haven’t actually purchased or committed to something, you’ll gain a lot of data about how they think but those are not grounded in actual attempts at doing anything.
4 Likes
Chris Spiek (one of the founders of the Re-Wired group with Bob) has a substack where he occasionally publishes a JTBD interview and the resulting forces/buyer’s journey.
Most are paywalled, but here’s one of the free ones: Martin's Cold Plunge Jobs to be Done Interview
5 Likes
This is a damn good question. It made me realise that — yes — Spiek and Moesta have talked about doing interviews for a new product (or an impending product launch), but it’s always of the form of “conducting the interview on people buying a similar product.” The mattress interview that’s linked to from the essay, for instance, was “imagine that you’re about to launch a mattress startup (like Casper) …”
So, to cut a long story short: yes, exactly as @minhthanh3145 points out — you need a real purchase decision to use this interview.
I should also note that the interview format is bloody hard. I think I took a month of trial and error and making lots of mistakes before I could get it to work!
5 Likes
This is a question I just thought of: how do you apply JTBD to understand demand with regards to an internal developer platform? As mentioned in another thread, I recently started a new position being a PM for an IDP. I’ve had some experience applying JTBD interviews in a customer-facing-product context (not saying I’m an expert though), but never for internal users.
Is the framing “what caused someone to say today’s the day they’re gonna purchase something” still useful in this context? What’s the “Buying” moment gonna be like for IDP customers, on their switch timeline? I feel like there are still trade-offs that they make, so I still have some hope that JTBD could still be relevant here.
Would appreciate everyone’s inputs on this.
2 Likes
Being a buyer of platform team as a product manager, I have few hypotheses on this.
The struggling moment would be a product is looking to expand or grow in a certain direction and its current tech debt doesn’t allow it to do it. This ensures that moving over to the platform services would be a better option.
The inertia would be reliability of service and troubleshooting if something goes wrong. So, if the platform team invests in great(not good) documentation that allays a developers fear of not having control on the services would benefit as well.
2 Likes
In my experience (as a PM for IDP at Twilio, as mentioned in the other thread), I felt our IDP had a strong advantage because it was basically already-paid-for. By the time a team was actively looking, it would be easy for them to try out the IDP’s product, and they wouldn’t deeply explore alternatives (whether open-source or paid) unless the IDP product was a bad fit in some way. So, we made sure that tech leads / architects knew about our product capabilities as they evolved, so they could apply them to relevant situations.
I wonder if this model might be similar to other situations where something is already-paid-for - like employers encouraging their employees to use their benefits, or other membership programs with optional perks. But at Twilio, we also had the massive stick of mandated usage for certain things, too.
2 Likes
Have there been situations where they’re already using some of their own tools, and that you had to “sell” your platform to them?
For example, a team may already set up their own test automation framework that works for them, but from a platform perspective, it may not make sense for other teams, perhaps because it’s missing crucial test orchestration services or analytics capabilities, and thus another alternative would be preferred.
In my case, I’m not looking to force them to switch (also not possible), so I’m trying to uncover problems with their existing approach (acknowledging that “pain” alone doesn’t make them switch, as @cedric pointed out, but seems like a good place to start?). I’m trying to identify situations in which their current approaches/toolings fall flat to place myself on the path of non-indifference.
1 Like
To be clear: pain is often a good-enough lens for demand-side problems. It is highly likely to be good enough for this one.
3 Likes