Find the real “jobs to be done” by analyzing what prospects do

Photo by Todd Quackenbush on Unsplash

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:

  1. the person who immediately needs the job to be done (and who would otherwise be using some other substitute to finish the work)
  2. the other people in the organization who work closely with that person and supply inputs and receive outputs from that person
  3. 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.

Intercom on “Jobs to be Done”, p.18

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.

TBM 39B/52: Crawl, Walk, Run, and the Fragility of Frameworks(opens in a new tab)

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:

Gourville’s “Stony Buyers, Eager Sellers” from Intercom’s Jobs to Be Done

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:

  1. Prototype a proof of concept similar to the desired solution: if possible, use something that already exists as a model
  2. Build in a low-stress environment: don’t write changes to any production system
  3. 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.

Thoughts on the Bus Problem


(photo by

What’s the most important thing you do at work?

Most of us, when asked “how do you create job security”, default to explaining a way of interacting with others that only we can do. If you have unique skills, of course you would want to create a solution where you can solve the problem. It’s romantic to think that you – the cowboy or cowgirl – can race into the important situation and solve the problem where no one else can, or do it faster than anyone else.

Described differently, “I am the only one who can get it done on time and under budget” also looks a lot like “I am a bottleneck”, or “my company is now vulnerable to the ‘Bus Problem’, where if I get hit by a bus my company will have absolutely no way to do the things I know how to do. These statements now look a bit different.

A Corollary To What You Do Today

But what if creating personal job security looked completely different and had more to do with creating systems everywhere you go that help everyone else in the company raise their game? In this version of the bus problem, maybe the solution is to make bus schedules (so that all buses run on time), and develop contingency plans (like snow routes) for what happens when there is inclement weather or other unexpected behavior like traffic?

The best way to solve the problem of institutional knowledge sharing is to share that knowledge. Duh. But it means more than simply barfing out that information in whatever messaging suite happens to be the flavor of the month. True knowledge sharing means that you can isolate the facts and share the strategy implications of changing course, that you can write a procedure anyone in your company can follow, and that if you are not in the office the process works without you there.

What does this look like in practice?

Let’s say for the moment that you are responsible for updating the team on a new feature in your product. As a consumer of that information inside of the company, each person in each role needs something different. Sales might need to know if the price of that product changes or if specific customers had been waiting for it. Marketing might need to know if there are marketable features that could be shared with a wide audience. Engineers might want to know if there are new things to test and build. And Customer Support needs to know the typical things customers will ask and how to solve their problems.

Compare your original goal of becoming the only one who can solve a critical problem with the goal of sharing information with everyone in the company at the right time to ensure a productive product release. If you don’t create systems that ensure people on your team know what they need to know before you can tell it to them, you will fail. Your participation in the process should be the reinforcement of the knowledge, rather than the only way they know that information.

Start today by writing down an important thing that no one knows into instructions that person can follow, and then take the day off. Train a trusted resource, take the day off, and see how things went. If you get to “One in a Row” on this problem, you’re ready to tackle the next critical business process you own until the whole business can run without you telling them which buses run next on the schedule.

One of the most difficult product decisions is “not yet”

(Photo courtesy of
I recently had a (great) idea for a product. In my head it made perfect sense – a way to make it easier for people building presentations to get instant help from a trusted freelancer. Surely many people would be excited to try it out. 

The idea went from sketched-out prototype to tech exploration to see if it was possible to execute the thing I was thinking about, and two things happened. First, two very smart people asked whether this is a problem that anyone has,  and whether I had any data to prove the size of the market. Second, I realized I hadn’t done enough work to move from idea to execution.

“Of course,” I said, sharing market validation stats and thinking about channel partners. But then it hit me – I hadn’t yet taken the fundamental step to validating the market need by hand with no tech investment and no real effort spent. Ideas are a dime a dozen until they have some traction.

And it made me consider the optimal way of moving from idea to idea++, or taking the first next step toward validation. “Paper prototyping,” – the effort to simulate the experience of building product without actually building that product – is useful when combined with tests to establish demand. 

In this case, what was needed was a plan to ask people (ideally those I don’t know) to state that 1) they needed help with presentations and 2) that they are willing to pay other people to solve that problem.

One way to test that would be to use an existing site where people request freelance assistance (let’s say Fivvr, Upwork, or similar) and put up an ad for services. The responses to this ad would give one set of signals for demand. Then, the type of work that resulted might help me determine whether the initial hypothesis is worth more thinking. And third, the initial revenue would give clues to the potential profitability of the idea.

Do I know whether I have a great product idea? Not yet. The next step is to validate whether presentations made “good enough” are sufficient for most people, most of the time. If that’s the case, on to the next idea, until there’s a bit more signal that this one is more than a momentary aha!

New things are easier to sell when they seem familiar

Marc Fulgar

Imagine you are selling a new drink (perhaps in a new category) and you’re competing against Coca-cola. You’ve invented a nootropic brain drink that helps you stay calm and alert while coding, and it has a pleasant natural fizz to it. It might even be an unusual color like purple. Taste tests from prospective customers have been successful and the effects bear out from your claim – coders love it! Continue reading “New things are easier to sell when they seem familiar”

A Reminder Hack For Daily Metrics

What if you had a conversation with your metrics about how to improve your business? Or more accurately, what if your voice-enabled agent asked you every day how you were doing?

A simple idea with with big implications

You might start with a simple question, like:

Hey Siri, how many widgets did we sell yesterday?

Ok Google, Which Customers Do I Need to Talk To Today?

And you might proceed to a more complicated idea, like:

Help me write a white paper to encourage more people to try my software today who match the “Small Business” segment.

In a few simple questions that you answer about your business you could determine what to do next, understand how things are going, and earn valuable insights you might not have anticipated.

Meh – you say – not possible. Objectives and key results are based on multiple variables that are difficult to correlate effectively. The metrics they are based on do not collect themselves. In addition, how would you isolate the behavior that drives these metrics?

This is a human-centric way of thinking. Because we’re used to the idea that machines are dumb calculators or not yet capable of building models to make the kinds of decisions we make every day, we discount the future that might happen if we create a model for decision-making that we train every day. Continue reading “A Reminder Hack For Daily Metrics”

Create a free website or blog at

Up ↑

%d bloggers like this: