Find the real “jobs to be done” by analyzing what prospects do
Find the real “jobs to be done” by analyzing what prospects do
"Everything Starts Out Looking Like a Toy" #110
Hi, I’m Greg 👋! I’ve written 100+ essays on product, data, and process for ideas or future product direction, often data between systems. What’s a key topic? System “handshakes”, the expectations for workflow, and the jobs we expect data to do.
Read more: What is Data Operations?
This week’s toy: Emoji Kitchen, which lets you combine emojis you know into brand new weird combinations you might not know yet. I quite like the cowboy robot as shown below. Edition 110 of this newsletter is here - it’s September 12, 2022.
The Big Idea
A short long-form essay about data things
⚙️ Find the real “jobs to be done” by analyzing what prospects do
Why do people buy a new solution? They are often dissatisfied with an existing way of solving their problem, need to solve a new problem, or see something brand new that looks cool. Clayton Christensen calls this search to find a substitute product “looking for a job to be done.”
People don’t simply buy products or services; they pull them into their lives to make progress. We call this progress the “job” they are trying to get done, and understanding this opens a world of innovation possibilities. (Christensen Institute)
The Jobs To Be Done framework is a way to enable the buyer to explain the purpose that caused them to buy new software. It also lets the selling company better align the underlying work required to match the capabilities that the company offers through its software to the real work the buyer needs to be done. We call it a “Job to Be Done” because like a person you would hire to do this work, you have specific requirements and a way to fulfill them to feel satisfied that this software is a good fit to solve this problem for your organization.
The “job” in the case of software often spans the needs of multiple people:
the person who immediately needs the job to be done (and who would otherwise be using some other substitute to finish the work)
the other people in the organization who work closely with that person and supply inputs and receive outputs from that person
the economic buyer who is deciding whether or not to purchase
On the surface, this software buying process seems relatively straightforward. It’s often messy because it’s informed by people indicating what they want to do, not always duplicating what they’ve done in the past. The “software” is really a stand-in for the match between the buyer’s idea of the capability needed and the seller’s assessment of how to match the software to that result.
The team at Intercom created this buyer journey diagram to track the experience of a prospect from initial awareness through consideration to buying and beyond. It does an excellent job of summarizing the timeline for that journey in terms of the stages the customer transits.
What’s missing from this diagram? The process the customer is using today to get the work done, or their description of the process they propose to get the work done. The critical path to deciding what will be good enough to “hire” your product for the Job to be Done is not always described by the job to be done.
Challenges with the Jobs to Be Done Framework
Frameworks are tools and are not complete playbooks for every situation. We know this to be true because the results are not consistent across the board among teams that are trying to innovate. For example, “84% of global executives reported that innovation was extremely important to their growth strategies, but a staggering 94% were dissatisfied with their organizations’ innovation performance.” (“Know Your Customers’ ‘Jobs to Be Done’”, Harvard Business Review, Sept 2016)
What’s the real driver of innovation? Some combination of a good frame, willing and effective facilitators, and people in the organization who want to change. John Cutler, a product evangelist at Amplitude, writes: “You want a framework that describes what people should do when they should do it, and how they should do it.” But that doesn’t usually work, as Cutler describes in this article.
What’s really going on here?
Change management (the selection of a new product) requires people, process, and technology to be coordinated to select the right job to be done and the product to do it.
People overweight the benefits of the solution they have. Innovators overweight the value of their solution. Multiplying these factors gives you a need to produce a really big change to nullify these effects. Gourville’s “Eager Buyers, Stony Sellers” explains it this way:
The process that you follow works when you focus both on breaking through the resistance of the existing solution and identifying the results you need to call the job done. These results are not usually bound by technology, but by the prospect’s belief that you can solve the problem better than they are doing today. To build this trust, you need a safe place for people to explore while getting fast feedback.
This is hard because it’s a leap of faith. For people who want to get their hands dirty and do the work themselves, it means giving them enough access and skill in the platform to prototype a solution and make it work. For people who are not going to do the work themselves, they need to gain confidence that the proof of concept you are building during consideration.
Buyers need to know why the new thing is better. They need to know they can solve the problem they set out to resolve. And they need to stop worrying about the things that could go wrong.
How to find the real Jobs to be Done
Given the constraints that make it hard to follow a framework perfectly, what should you do to enable your prospect (and your sales team)? The prospect needs the space to explain how they want the problem to be solved. You need to know how to translate these requirements into tangible tasks that you get done in your software.
To find the real Jobs to be Done, you need to remove barriers and objections from the prospect.
Here are a few suggestions:
Prototype a proof of concept similar to the desired solution: if possible, use something that already exists as a model
Build in a low-stress environment: don’t write changes to any production system
Prove that you can deliver the result as a proof of concept: produce the result you want to see in production, and do it in a sandbox
When you demonstrate a solution to the buyer that uses their data, looks like a solution they would use, and delivers a favorable result? That’s the Job they want Done.
What’s the takeaway? Jobs to Be Done is a helpful framework to think about delivering results for the prospect while making software selection a buyer-centric process. The framework alone won’t do the trick: you need to align the prospect’s needs with the solution to overcome the 9x effect.
Links for Reading and Sharing
These are links that caught my 👀
1/ Using stable diffusion to draw - Andy Salerno uses computer models to draw starting with very simple prompts. In “How to Draw Anything”, he explains how to go from scribbles to sci-fi images like this one.
What’s really cool about this is that he was able to take simple models and turn them into very detailed examples in almost no time. I’d love to use this as an example to generate backgrounds for slides.
2/ Not all EVs are the same - you might be surprised to learn that the battery alone in the Hummer EV weighs more than a Honda Civic. Creating an electric version of the SUVs many buyers want doesn’t need to mean creating something that’s 1.5 times as heavy as a traditional model. However, when you tack an electric powertrain onto an existing design that’s what you get.
Where are the midsized (or large) electrics that move the right number of people around (4+ and their luggage) and don’t also create new hazards for other drivers? There’s room for improvement here, and consumers are waiting for alternatives that don’t cost 100k or are largely impractical.
3/ Designing better UX - do you pay much attention to the “back” button in your user experience? Vitaly Friedman has an excellent guide to improving what happens when users need to reconsider what they’re doing. Back buttons aren’t just about returning to the previous page - they might also handle undoing transactions, putting data back where it needs to go, and making the user feel comfortable about what happened.
What to do next
Hit reply if you’ve got links to share, data stories, or want to say hello.
Want more essays? Read on Data Operations or other writings at gregmeyer.com.
The next big thing always starts out being dismissed as a “toy.” - Chris Dixon