Yesterday I ran a workshop for seed stage startups about how to use the Job To Be Done framework to raise their chances of achieving product-market fit. The surprise: many seed stage startups are unclear about who their target customer is. A simple Job To Be Done exercise exposes the lack of clarity and helps resolve it.
Here’s the presentation and exercise:
“Job To Be Done” for seed stage startups
Edited excerpt from Does your startup solve a problem? Vitamin or painkiller? by Don Dodge:
One of the questions I ask entrepreneurs when evaluating start-ups is “Is your product a vitamin (nice to have) or a painkiller (got to have it)? Of course everyone wants to think their product is a “must have” painkiller, but very few are.
Many products fall into the vitamin category. Things like productivity tools, content aggregators, mashups, utilities, collaboration applications, measurement and monitoring tools, in fact anything that is a tool, development or otherwise, is by definition a vitamin.
Painkiller products are products that solve for a specific pain point. Sometimes the pain is measurable in terms of ROI, winning sales that could not be won before, or satisfying a regulatory requirement.
There is another set of products that are vitamins (nice to have) until you feel the pain. Then they become painkillers (got to have it). There are actually lots of products that fall into this category.
(1) On vitamins versus painkillers, see also Building a valuable product — a checklist of questions to answer and How to sell your product if it’s a “nice to have”, not a “must have”.
(2) My personal viewpoint: the categorization of products into vitamins and painkillers is flawed and unhelpful. Note that (i) great businesses have been built from “vitamins” (think media and entertainment), (ii) helping a company to increase its revenues is, absurdly, a vitamin, and (iii) the categories are unstable — products can transition from vitamin to painkiller depending on the context and user.
(3) For me, the Job To Be Done framework is far more helpful. The right questions to ask are: What “job” is the user / customer looking to get done (user need)? How valuable is getting that job done for the person (willingness to pay)? How many people have that job (market size)? How well does your product help the person get the job done relative to the alternatives (competitive advantage)?
(4) See: A brief summary of Job To Be Done, with 3 takeaways for product managers.
Edited excerpt from The Dribbblisation Of Design by Paul Adams:
Design is a multi layered process. In my experience, there is an optimal order to how you move through the layers:
1. Outcome. Start with the intended outcome. What will the thing you’re designing make easier or better for people? Most projects without a clearly defined intended outcome don’t end well. At Intercom, we work with Clay Christensen’s Jobs framework for product design. We frame every design problem in a Job, focusing on the triggering event or situation, the motivation and goal, and the intended outcome: When _____ , I want to _____ , so I can _____ .
2. Structure. Next, design the system. Work out the required components to meet the intended outcome, and map the relationship between them.
3. Interaction. After the outcome and system are figured out, design the interaction details. What are the microinteractions? The sequence of behavior and events? What are the UI components, and how will people interact with or manipulate them? How will things move, change or animate? Revisit the system, evolve it to match the interactions. Keep iterating.
4. Visual. Once the outcome, system and interactions are well defined and working (ideally prototyped), design the visual details. Make it look and feel beautiful, enjoyable. Now it’s time for beautiful grids, color, typography, iconography.
I see designer after designer focus on the fourth layer without really considering the others.
(1) Re. “Outcome” as the first stage of product design: see Why product managers should frame every product task as a Job To Be Done.
(2) Re. “we frame every design problem in a Job”: see How to describe your customers’ “Job To Be Done” using a Job Outline.
(3) Cf. Five questions to ensure product designers focus on the Job To Be Done.
Edited excerpt from Why Product Thinking is the next big thing in UX Design by Nikkel Blaase:
A product has a core user experience, which is basically the reason the product exists. It fulfills a need or solves a problem people have. By doing so, the product becomes meaningful and provides certain value. If the problem is non-existent, or the solution doesn’t fit the problem, the product becomes meaningless and people won’t use it. This in turn leads to the failure of the product.
Wrong solutions can be fixed, but non-existent problems aren’t fixable.
So when thinking about products, UX designers should first answer the following questions:
1. What problem are we solving? (User problem)
2. For whom are we doing this? (Target audience)
3. Why are we doing this? (Vision)
4. How are we doing this? (Strategy)
5. What do we want to achieve? (Goals)
Only then does it make sense to think about exactly what we’re doing (Features).
(1) Re. For whom are we doing this? (Target audience): The Job To Be Done framework avoids defining target customers other than as people who have that Job To Be Done. Who those people are and how to find them is more important for marketing and growth hacking than for product managers or UX designers. So I’d replace this question with: How do we find people with this Job To Be Done? See “Inception”, in A framework for growth hacking using Job To Be Done.
(2) Re. How are we doing this? (Strategy): What unique capabilities do we bring to the table? How will they be expressed in the product?
(3) Re. What do we want to achieve? (Goals): Ensure we’re sufficiently ambitious. What would success look like? Define a metric, and make sure it’s a real metric, not a vanity metric. Then, set a stretch goal, rather than what we think we can achieve.
(4) Cf. Why product managers should frame every product task as a Job To Be Done.
Edited excerpt from Don’t design what users want by Michael Sueoka:
One piece of feedback we received was a feature for a user to get an email every single time a specific event occurred for one of their campaigns. Our user wanted to know every time a campaign started, ended, was performing poorly, hit the halfway mark, was off to a bad start, had little traffic, or reached its spending limit.
Now, imagine having 20 mobile campaigns running on any given day and receiving 20-30 emails all within a short time frame. Despite what the user wanted, this would have overwhelmed their inbox with non-actionable items in a non-organized way.
So I set up a handful of video chats and in-person interviews. We distilled all our findings and discovered the user’s one basic need: they simply wanted to know if their campaigns are doing okay.
Getting user feedback is the most important thing any UX designer, engineer, business owner, and product manager could do. But don’t just take that feedback and design a solution based on what the user says. Dig deeper to figure out your user’s root problem.
Don’t try to figure out what the user wants. Try to figure out why they want it.
(1) “The user’s one basic need”, “your user’s root problem”, and “Why they want it” are all other names for: your customers’ Job To Be Done. See A brief summary of Job To Be Done, with 3 takeaways for product managers.
(2) Another technique to uncover the Job To Be Done from a (possibly misguided) feature request is to keep asking “Why does that matter to you?” or just “Why?”. See 5 Whys.
Edited excerpt (with emphasis added) from Slack, I’m Breaking Up with You by Samuel Hulick:
When there was all the talk of you [Slack] killing email, I have to admit I thought it was the email problem you were attacking, not just the email platform. Which is to say, I thought you were providing some relief from the torrential influx of messages, alerts, and notifications I was receiving on a daily basis. “Me + Slack = Fewer distractions and more productivity,” I thought at the time.
I have to say, though, that I’ve since found it to be the opposite. I’m finding that “always on” tendency to be a self-perpetuating feedback loop: the more everyone’s hanging out, the more conversations take place. The more conversations, the more everyone’s expected to participate. This really lowers the bar for what’s considered message-worthy to begin with.
Even your summaries of each week — the ones where you remind me about how our relationship is going — are all predicated on its volume of messages, which was kind of the opposite of what I thought you and I were all about.
(1) This is a poignant example of a company mistaking user engagement for customer success. Samuel adopted Slack because he thought it would make him more productive. But Slack measures its success by user engagement (the volume of messages), which conflicts with its users’ goal to become more productive.
(2) This problem is widespread. The tech industry has mastered how to maximize user engagement, but we often lose sight of the real goal — to empower users to achieve something worthwhile. Scientific studies show that Facebook, the most successful consumer product ever built as measured by daily users, makes people less happy. We’ve made content consumption irresistible with bite-size snacking and alluring headlines, but have dumbed down content in the process. And we’ve developed addictive games which, after extended periods of usage, leave people feeling empty and purposeless.
(3) How can product managers avoid mistaking user engagement for customer success? (i) Research the Job To Be Done and articulate it explicitly. This provides a definition of customer success. (ii) List the key requirements for users to get the job done. (iii) Even if you can’t measure customer success directly, and need to use a proxy for customer success such as user engagement, ensure that every product decision is justified in terms of the Job To Be Done and customer success.
(4) Cf. The key metric for your startup must satisfy these 4 criteria.
Edited excerpt from What people really want — Focus on the job, not the customer by Nikkel Blaase:
People don’t want to buy products. They want to hire products to get a job done. Or as Harvard Business School professor Theodore Levitt puts it: “People don’t want to buy a quarter-inch drill. They want a quarter-inch hole!” People do things because they find themselves with a problem they would like to solve — such as overcoming a boring commute, recovering from a stressful day or hanging framed photos on the wall. When people struggle they look out for solutions to achieve progress in their lives.
The Job-To-Be-Done framework has become popular in product design because it uncovers what causes people to hire products or services. Rather than understanding people by their demographic or socio-economic attributes, such as income or level of education, the framework focuses on satisfying needs by understanding the jobs people want to get done. Uncovering these jobs makes it easier to build the right solutions.
1. Focus on understanding the job people want to get done and find out how the product fits into people’s lives.
2. Sell the product’s outcome, not the product itself: Beautiful, cut grass — not lawnmower or GM seeds.
3. Don’t care about direct competitors. Think about alternatives for achieving the same job and do the job better than any other solution out there.
(1) In my experience, product managers may think they have successfully adopted the Job To Be Done framework simply by describing their project as a Job To Be Done. But unless you devote meaningful time and effort to investigating the Job To Be Done, for example by creating a Job Outline and conducting switch interviews, you’re kidding yourself. In Nikkel’s words, “Focus on understanding the job people want to get done and find out how the product fits into people’s lives”.
(2) For another description of Job To Be Done, see Build your product to explicitly address a “Job To Be Done”.
(3) Re. “Sell the product’s outcome, not the product itself” – cf. Steve Jobs’ approach to marketing.
(4) Re. “Don’t care about direct competitors” – cf. Your biggest competitor may not be who you think it is.
(5) For more, see the section on Job To Be Done in Best practices for startups — a list by topic.
Edited excerpt from Replacing The User Story With The Job Story by Alan Klement:
The problem with User Stories as a framework to think about product is that they make too many assumptions and don’t acknowledge causality. When a task is put in the format of a user story — “As a [type of user], I want [some action], so that [outcome]” — there’s no room to ask ‘Why?’. You’re essentially locked into a particular sequence with no context.
A far better framework is what I call Job Stories, an idea from the really smart guys at intercom. Frame every design problem as a Job, focusing on the triggering event or situation, the motivation and goal, and the intended outcome: When _____ , I want to _____ , so I can _____ . For example, “when an important new customer signs up, I want to be notified, so I can start a conversation with them.”
The Job Stories framework is great because it makes you think about motivation and context, and de-emphasizes any particular implementation. Often, because people are so focused on the who and how, they totally miss the why. When you start to understand the why, your mind is then open to think of creative and original ways to solve the problem.
(1) As Alan Klement shows above, whenever you specify a Job To Be Done, the emphasis is on what the person is trying to achieve, not performance of a task. So it’s easy to ask “Why does the person want to achieve that outcome?”. This question frequently leads you to a better solution than the one you’re considering.
(2) Framing every product task as a Job To Be Done can be powerfully combined with Joe Natoli’s framework for clarifying what your users care about. First, ask what the user is trying to achieve with this page, interface, feature or task (= Job To Be Done); then ask what information they most care about to get that job done (= information architecture).
Edited excerpt from 5 Tips For Writing A Job Story by Alan Klement:
Because personas are a mashup of assumptions and attributes, they can have a destructive effect on product design. They can give a false sense of knowing the customer and can thereby lead to gaps in design. For example, you can’t ask a persona about their anxieties, why they chose Product A vs Product B, what else was going on when they chose Product A vs Product B, or that when they first opened your app they didn’t know what to do first….
Specication of a Job To Be Done can only come from real customer interviews. Before designing a feature or new product, you must talk to real people and uncover all the anxieties and contexts which were in play when they used your or a competitor’s product.
(1) Early stage startups often describe their product as meeting a “market need”. But markets don’t have needs; real people have needs. Just as Alan Klement shows that personas, “a mashup of assumptions and attributes”, can have “a destructive effect on product design”, so too the abstract concept of “market need” can have a destructive effect on your startup’s positioning.
(2) Job To Be Done is a powerful framework for startup positioning, not just for product management. When you think about a Job To Be Done, you are forced to think about a concrete person (= target customer). You can then ask (i) How many other people share this Job To Be Done (= market size)? (ii) What solution do these people currently use to get this job done (= competition, including surprising competition)? (iii) How did the user find that solution (marketing and distribution)? (iv) Does the user currently pay to get this job done (= proven monetization potential)? (v) How valuable is this Job To Be Done for the user (= pricing potential)?
(3) To get to the right answers, clarify what your users ultimately care about. To do that, keep asking “Why does the user care about that?”, until you get to the point where the answer is completely obvious. (Cf. 5 Whys.)
(4) Cf. Documenting your product-market fit hypotheses.
Edited excerpt from Building your growth model and Ladder of Engagement by Josh Elman:
As you are building a growth model for your company, here are the key questions to answer:
Purpose: What is the core purpose of the product?
Users: Who will care about that core purpose?
Inception: How can I get people to hear about this product for this purpose?
Adoption: What does someone need to do to get the product to fulfill this purpose for them?
Habit: How frequently should the person use the product, and how can we get them to adopt the habit?
(1) Cf. Ben Yoskowitz’s framework — (i) Marketing/Growth, (ii) Onboarding, (iii) First User Experience and (iv) Ongoing Engagement — in How to set priorities in product development.
(2) By identifying the product’s Purpose before its Users, the impact is the same as using the Job To Be Done framework: what job does this product do, who wants to do that job, and (once you’ve ascertained that the job is valuable enough and enough people want to get it done) how can we improve our product to better do this job?
(3) This contrasts with the standard customer development framework, where you first identify your target users and then ask what is most valuable to those users. The problem with this is that it’s too unconstrained — your users may care about a lot of things, but many of them have nothing to do with your product. This may create tension between feedback and vision in product management, and lead to premature pivoting.
(4) Due to its importance for product management, I’ve created a category for Job To Be Done. You can also find the posts in my list of startup best practices.
(5) “How frequently should the person use the product, and how can we get them to adopt the habit?” — see (i) The relationship between frequency of habit and customer retention and (ii) How valuable is your product? Google’s “toothbrush test.
Edited excerpt from Doing SaaS Cancellation Interviews (the Jobs-to-be-Done Way) by Ruben @bidsketch:
My favorite way to implement the Job To Be Done framework is by doing “switch interviews”, in which you focus on how the customer stopped using one product and started using another. Here’s how to do switch interviews for cancellations / churn.
Switch interviews typically last 45 minutes, so recruiting people can be a little tricky, particularly someone that just cancelled. We used an incentive ($100 Amazon gift card) and recruited inside the app.
Switch interviews focus on the actual story of someone getting fed up with a product enough to switch to something else. The decision to cancel didn’t take place the day they cancelled, so you can’t just get the story of the day they cancelled. You need to build the entire timeline of key events that led to the cancellation: (i) first thought that the product wasn’t working for them, (ii) started considering alternatives, (iii) a time sensitive event that triggered active looking for an alternative, (iv) evaluated options and actually bought/canceled, (v) when and how they consume or use the product, and (vi) product satisfaction.
Below is our cheat sheet for these interviews:
Setting the stage
Thank them for taking the time and explain that we’re doing these interviews to learn how we can improve Bidsketch. Mention: “We love blunt feedback, so don’t worry about hurting our feelings, it’s not going to happen.”
Tell them: “We’re going to focus on the story of how you started using Bidsketch, first started struggling or not finding it helpful, and then eventually cancelled. So we’re going to ask detailed questions about where you were and what was happening, to just help paint the picture.”
– Why did you initially sign up for Bidsketch? Did you evaluate other tools?
– When was the first time you thought that maybe Bidsketch wasn’t going to work? Or realized that you weren’t using it?
– What happened the last time that you used Bidsketch for a proposal?
– What happened the first time you had a proposal that you didn’t use Bidsketch for?
– Why did you cancel the day that you cancelled? Why that day, and not the day before or after?
– What are you using now? How did you start to prepare to use the new product (export data, etc.)?
– What happened the day you started to move to the new product/solution?
– Why did you start that day and not after?
(1) Here’s the basic framework for Job To Be Done. See the notes there.
(2) Remember that in the “Job To Be Done” framework, an alternative solution for the customer might not be a similar product, but a work-around. So don’t expect customers to switch only to competitive products.
Edited excerpt from Filling in Lean’s Gaps by Alan Klement; it builds on and assumes knowledge of Clayton Christensen’s Job To Be Done:
The Job Outline serves two purposes: (1) It’s a high level guide on how to research customers and what to look for. (2) It’s a succinct document to get everyone involved with the product thinking the same way. It has four parts:
1. Exposition. In story telling (narratives) it often helps to introduce background information which sets the stage before the main plot begins so the audience can quickly understand the context in which everything happens. The same is true for product design. When creating an exposition for a product, consider the dry facts of the situation. Briefly explain the who, what, when and where, but not the why. The goal is to make sure everyone knows the context of the customer’s struggle.
2. Observation. Identify two things: (1) The pre-existing behaviors customers do now and have done in the past. (2) The purchases which customers make and have made in the past. Watch what customers are doing now. It can be visual (physically watching customers), technical (data metics) and general research.
3. Situational Analysis. Explain the challenges customers’ are facing and what is pulling and pushing them to and from different solutions. Then, describe their anxieties and motivations.
4. Job To Be Done. This is not a solution, but a way of thinking about what the solution should accomplish. It’s not a shot in the dark hypothesis, but rather the result of deep thinking and a coalescing of research. A good Job To Be Done will begin with the context the customer is in (Exposition), apply the observations of pre-existing human behaviors (Observation), reduce, or eliminate, the customer’s anxieties and resolve their motivations (Situational Analysis).
(1) A common challenge for product managers is that we know we should ask customers questions and listen to their feedback, but it often feels like we’re groping in the dark with no clear direction. Alan’s Job Outline solves this problem by providing a clear goal and framework for customer development questions: you’re trying to discover the Job To Be Done.
(2) Figuring out the Job To Be Done is vastly harder if your product tries to address multiple needs. For example, Seeking Alpha PRO addresses three Jobs To Be Done (it helps stock pickers find investment ideas, research stocks, and track potentially important analysis of stocks they own). The solution is to focus on one Job To Be Done at a time, starting with what you believe is the most valuable. You might find that you need separate products for separate Jobs To Be Done.
(3) Focusing on a Job To Be Done removes the need to specify who your target customer is, because your target customer is anyone who needs to get this job done. If you discover that there are different jobs to be done, for example Clay Christensen’s example of a milkshake to provide breakfast on a commute and a milkshake to provide a treat for a child, you’ll likely find you have different types of customers.
(4) What questions should you ask your target customers to help complete this Job Outline? See Seven questions to uncover user goals and needs.
Edited excerpt from Clay Christensen’s Milkshake Marketing by Carmen Nobel:
“We realized that the causal mechanism behind a purchase is, ‘Oh, I’ve got a job to be done.’ And it turns out that it’s really effective in allowing a company to build products that people want to buy.”
A fast-food restaurant chain wanted to improve its milkshake sales. One of Christensen’s researchers tried to deduce the “job” that customers were “hiring” a milkshake to do. He spent a full day in one of the chain’s restaurants, carefully documenting who was buying milkshakes, when they bought them, and whether they drank them on the premises.
He discovered that 40 percent of the milkshakes were purchased first thing in the morning, by commuters who ordered them to go. They faced a long, boring commute and needed something to keep that extra hand busy and to make the commute more interesting. They weren’t yet hungry, but knew that they’d be hungry by 10 a.m.; they wanted to consume something now that would stave off hunger until noon. And they faced constraints: They were in a hurry, they were wearing work clothes, and they had (at most) one free hand.
The milkshake was hired in lieu of a bagel or doughnut because it was relatively tidy and appetite-quenching, and because trying to suck a thick liquid through a thin straw gave customers something to do with their boring commute. Understanding the job to be done, the company could then respond by creating a morning milkshake that was even thicker (to last through a long commute) and more interesting (with chunks of fruit) than its predecessor. The chain could also respond to a separate job that customers needed milkshakes to do: serve as a special treat for young children—without making the parents wait a half hour as the children tried to work the milkshake through a straw. In that case, a different, thinner milkshake was in order.
(1) Focusing on a Job To Be Done removes the need to specify who your target customer is, because your target customer is anyone who needs to get this job done. If you discover that there are different jobs to be done, for example Clay Christensen’s example of a milkshake to provide breakfast on a commute and a milkshake to provide a treat for a child, you’ll likely find you have different types of customers.
(2) Cf. The best products satisfy a frequent user need with minimum friction.
(3) Cf. Andy Johns on how to build a winning product.
From What Customers Want from Your Products by Clayton M. Christensen, Scott Cook, and Taddy Hall:
Pierre Omidyar did not design eBay for the “auction psychographic.” He founded it to help people sell personal items. Google was designed for the job of finding information, not for a “search demographic.” The unit of analysis in the work that led to Procter & Gamble’s stunningly successful Swiffer was the job of cleaning floors, not a demographic or psychographic study of people who mop.
Why do so many marketers try to understand the consumer rather than the job? One reason may be purely historical: In some of the markets in which the tools of modern market research were formulated and tested, such as feminine hygiene or baby care, the job was so closely aligned with the customer demographic that if you understood the customer, you would also understand the job. This coincidence is rare, however. All too frequently, marketers’ focus on the customer causes them to target phantom needs.