Competing Against Luck: the question Clayton Christensen left FDEs to ask before every discovery session

“Companies have never known more about their customers, yet their innovation remains hit or miss.” That is roughly how Harvard Business Review opened the article drawn from the book, published in its September 2016 issue, a few weeks before the book came out.

The line fits a Forward Deployed Engineer more closely than you might think. You can sit beside a customer for a week, read every log, interview ten users, and still deploy something nobody opens again after the demo.

Competing Against Luck: The Story of Innovation and Customer Choice explains why that happens. Its answer is a skill you can use in your next customer discovery session.

Who wrote it, and what does it say?

Harper Business published the book on 4 October 2016. It has four authors: Clayton M. Christensen, Taddy Hall, Karen Dillon and David S. Duncan. Christensen is the man behind the theory; Julia Freeland Fisher of the Christensen Institute wrote about the book in the week it launched.

The central argument sounds counter-intuitive. According to the publisher’s description, understanding customers is not what makes innovation succeed; understanding the job is. Customers do not buy products or services. They “hire” them to get something done.

The book promises to turn innovation from a game of chance into predictable growth. The title says as much: competing against luck.

Three ideas worth keeping

The first is the hiring metaphor. The Christensen Institute puts it the same way: people do not simply buy or choose products, they pull them into their lives to make progress. For an FDE, this changes the question from “what features does the customer want” to “what is the customer hiring this system to do”.

The second is the definition of a job, which Yevgeniy Brikman summed up in a 2022 review: a job is the progress a person seeks in a specific circumstance. The two words that matter are “progress” and “circumstance”. Without the circumstance, all you have is a generic need that nobody can measure.

The third is the easiest to miss: according to Freeland Fisher, jobs to be done is a theory of competition. If customers hire a solution for a job, your competitors are everything else they could hire for that job, including a spreadsheet or a member of staff doing it by hand.

What does it look like on a deployment?

In Brikman’s review, the classic example used to introduce jobs to be done is the milkshake. Inside Higher Ed recounts that Christensen built the framework while asking why people bought milkshakes at fast-food restaurants. The question was not “what flavour do customers like” but “what job are they hiring the milkshake to do”.

Imagine you are an FDE at a logistics company, and the customer says: “We need an AI agent to answer drivers’ questions.” That is a feature request. Stop there and you will build a RAG chatbot over internal documents and measure it by answer accuracy.

Now ask the Christensen way: when was the last time a driver needed to ask something, where were they, and what did they do when nobody answered? Suppose the answer is that the driver was standing at the door of a customer who was out, called the call centre, waited a long time, then decided alone. The real job is “make the right decision at the door, without waiting”.

Once the job has a name, the decisions downstream change too. The interface probably has to work one-handed on a phone, something that was nowhere in the original request. Before writing the first line of code, fill in these four boxes:

Step	Write down	In the logistics example
1. Job	Progress in a circumstance	Make the right decision at the door, without waiting
2. Competition	What the customer hires today	A call to the call centre, the driver’s own judgement
3. Metric	Measure progress, tied to the circumstance	Time to decision
4. Check	Does the report to the customer use the new metric?	Not just answer accuracy

The fourth box blocks the most common mistake: finding a new job but keeping the old metric, so the system gets rebuilt while the report still tells the old story. If the metric in the third box says nothing about the circumstance, you have probably not found the job yet.

The framework is not only for products sold to outside buyers. Inside Higher Ed applied it to education, asking what job students hire a university to do. At a customer site, the equivalent question is: what do operations staff hire this internal system to do, and when it is slow, what do they hire instead?

In what order should you read it?

Start with the HBR article “Know Your Customers’ ‘Jobs to Be Done’” (September 2016): it is short and enough to grasp the framework. Then read the Christensen Institute’s Jobs to Be Done page for a compact definition.

If your discovery sessions tend to end with the customer listing features, read the whole book to see the theory applied across many situations. Brikman’s review on ybrikman.com is a good summary to revisit before a customer meeting.

The book suits engineers with two to four years of experience who are about to move into customer-facing roles. Seasoned product people may find it familiar, but the section on competition is still worth reading.

Turn it into an edge when job hunting

When reading an FDE job description, look for lines about customer discovery or clarifying vague customer requirements. If they are there, jobs to be done gives you concrete language to show you can do that work.

On your CV, do not write “worked with stakeholders to gather requirements”. Write a line showing that you reframed the problem: what the original request was, the real job you uncovered, and the metric you switched to as a result. In interviews, tell exactly that story, from the original request to the real job.

Customers will always describe the solution they imagine. The FDE’s job is to ask one more question to find what they actually want to hire.