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
1 Like
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.
3 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.
3 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.
2 Likes
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.
4 Likes
Necro-ing an old thread, turns out a person from my neighborhood growing up who’s friends with my younger brothers is working with Bob Moesta and Andrew Glaser at their current start-up as their head of product. Small world…
Said person:
EDIT: I guess we had something in the water (mostly missed me), Matt Harrison (author of Effective Pandas, Effective Visualization, and other stuff w.r.t. Python) grew up just down the street on the next block.
2 Likes
I’m about to start a cycle of these JTBD interviews, so I bought the Moesta/Engle book recommended here (Demand Side Sales; Jobs to Be Done Handbook is shipping now). Interestingly there’s no Kindle e-book (I got the ebook on Apple Books), and there’s no Audible/Libro audiobook version. The latter might be choice, e.g., to preserve integrity of graphics/diagrams, but the absence of this book on Kindle makes me think it’s not very popular. Do folks who have read the book have thoughts on why that is?
Jobs To Be Done is pretty famous and well-known as a concept covered in Innovator’s Dilemma, but this book goes into waaay more detail to make it useful for sales/marketing/product.
Sales books that are popular (SPIN in a previous generation, Challenger in a more recent one) are pretty solidly adopted. I once had a prospect laugh after a sales call because she recognized some of the questions I was doing from one or both of those books (which obviously doesn’t reflect well on my skill as a salesperson, but she’s a believer in what we do so wasn’t turned off by it).
I like the idea of it not being popular (less arbitrage potential) but wonder if there’s an obvious flaw that I’m missing. If anything is going to be a fairly efficient market, you’d think it’d be sales methodologies, since there’s a huge incentive!
4 Likes
This is odd; I remember buying and reading Demand Side Sales on Kindle. It could be that they’ve taken it off after Amazon made changes to their offer — I’ve heard stories on and off about various authors swearing off Kindle forever after being subject to Amazon abuses (the most salient one for me was Alex Hillman’s Tiny MBA).
Do note that JTBD isn’t really a sales methodology. It’s org design to make sales more effective, but it cuts across marketing, sales, product, and customer support. Perhaps that explains the lack of uptake amongst sales folks.
3 Likes
That seems like a plausible explanation — to that point, it’s hard for me to imagine a sales leader of a big organization implementing this methodology (it requires too many other departments) whereas a sales leader could implement something like Challenger. And it’s hard for me to imagine a sales organization driving Jobs-to-be-done interviews with customers. In other words, the audience for this might be a little too narrow.
Actually the combination of this book and Heart of Innovation has gotten me wondering if there’s a way to structure an enterprise sales organization in a very non-standard way. Most enterprise sales orgs I’ve seen have a fairly consistent structure: SDR/BDR folks doing inside sales calling/emailing lead generation; pure Sales Execs who take leads they get (or bring from their rolodex), move the prospect through the funnel, and are the “closers”; and then Solutions Managers/Solution Architects/Sales Engineers/etc, who are brought in as SMEs/product experts by the Sales Exec as needed, and maybe to help tailor the solution.
But if you could nail authentic demand, and if your team had a really strong understanding of the buyer journey, maybe you’d only need the lead gen folks to bring in new leads and the SME/Solutions Managers to help guide them through the buying journey. The Acquired Epic Systems podcast pointed out that Epic only has eight pure salespeople, which is insane given their size; but maybe it works because they have nailed the two “if’s” above (and because they’re vertically-focused).
2 Likes
I tend to be sceptical of these types of quotes. Atlassian is also quoted as having had no sales people for most of their history, but I was assured by people there that this was not true, but it was differently organized.
If you do have real pull demand with strong pmf, which is the Atlassian model, the aim is to have the demand being inbound so you don’t need leadgen, and combine with product led growth so people start self service, then sales can be about expansion largely.
3 Likes
Yeah I hear that. i didn’t know that Atlassian had that reputation, but it makes sense that any company would have incentive to play down the fact that they need salespeople. And Epic definitely has people who are selling, and I’m sure more than eight of them. But I do believe that they don’t have a pure sales exec in the way that I see at most enterprise-focused companies, instead leaning towards more of the solution architect persona.
The reason I’m intrigued is I’ve found that finding great enterprise salespeople - at least in the vertical of healthcare we’re in - is really hard (like best I’ve heard in terms of successful hiring is 40%, maybe 50% if you’ve got an amazing network); the sales cycles are long (9-15mo); and these salespeople are very expensive even just factoring base and not commission. In summary, you get it wrong often, it takes a while to really know when you’ve gotten it wrong, and it’s an expensive mistake in the meantime.
So I believe there is value if you could minimize the need for the great salesperson (plus more importantly that’s probably a great sign for your product).
One caveat: I don’t have experience with working with Solution Architects/Sales Engineers, so I don’t know if they have the same problems listed above.
1 Like