What do people want from your SaaS? (advanced edition)

This is the third (and last) post of my series on how to discover what people want (so you don't end up creating something that nobody wants). The first post is here and the second one is here.

Here we'll get more advanced and cover how to structure JTBDs (job-to-be-done statements), get to the core JTBD, and so on.

Ask "why" until you get to a human reason

There’s a "magic" question to identify whether the job you think your product is helping people accomplish is the "core" job people hire you for:: “Why?”

Here are some example questions you can ask:

• Why are you trying to determine if a specific information is accurate?
• Why are you hoping to find a home for sale?

Some JTBD (jobs-to-be-done) experts recommend you keep asking "why" until you arrive at a human reason.

For example, suppose a person tells you that the reason why they’'re trying to determine the best price for a product is to save money for the well-being of their kids. This is a human reason and there’s no point asking further questions like: “Why do you want to improve your children's well-being?”

Instead of asking “why”, you can also try with: “What are you trying to achieve when X?” (what are you trying to achieve when you find a home for sale?) to get to one level up.

Or you can just use both of these questions.

To get a better understanding on where your job fits in the big picture, ask people what happens before and after it.

For example, ask what do they do after they’ve accomplished [the job]: “What are you hoping to accomplish after you find a home for sale?”

Also try asking questions related to monitoring whether the job is being done: “How will you monitor whether you’re maintaining employee engagement?”

Other questions:

• “What modifications do you need to do after doing the job to ensure it’s being done successfully?”

• “What must happen after the [job] to ensure it’s successfully carried out?”, -

• “What needs to happen to successfully conclude that the job is done?”

• “What needs to be monitored/verified after the job is done to ensure successful completion?”

• “What problems need to be resolved on occasion after the job is done?”

As for finding out what happens before tjoeb, ask questions like: “What needs to be identified/prepared/set-up/located/confirmed/gathered/retrieved before the [job] (in order to ensure success in getting the job done)? What else? Why?”

If the job to be done is too broad/vague, like “Maintain children safety”, ask: “How do you plan to…[maintain child safety]” to get to lower-level jobs, which you can later run them through the importance/satisfaction phrase.

Here’s an example: The main job-to-be-done is “learn a subject”.

In order to execute this job (learning a subject), you first need to define the subject you’ll learn.

You then need to do things locate information sources for studying, prepare by allocating time on learning and then start the main job (learning the subject)

After you complete this job (learned the subject), or while you’re doing it (learning), you may need to modify and monitor your progress by possibly using new learning material, testing yourself on the progress and so on.

In the end, you need to conclude that the job was done (the subject was learned successfully).

There are potential product ideas in all of these steps. That's the power of de-constructing a job-to-be-done.

Many products fulfill just one of the steps in the overall, big-picture JTBD. For example, many website owners which site received a Google search penalty want to “remove a website from Google search penalty database”

To accomplish this, they need to complete several steps, like:

• Determining the links to remove
• Checking if the links are if they’re still there after attempting to remove them
• Getting website contact data in order to get in touch with the owner

There could be potential product for each of these separate steps. Or one that unifies everything.

Your job when interviewing customers is to find the core job your product is hired for and go from there.

Why Avoid Asking for Features?

One advantage on focusing on a job-to-be-done is that it enables you to be more creative.

A job will give you the problem that needs to be solved.

A feature will give you a proposed solution (which may or may not be the best way to solve the job).

Compare an engineer who gets a “feature request” to “add a button for making the text bold in the text editor” vs. an engineer who gets a “job request” to “emphasize the important points of the article”.

Which statements will spur more creative ideas?

Many people assume that “more features” = “more value” without realizing that a feature can hurt a product if it makes a specific job the product was hired for slower to accomplish.

For example, adding a bunch of fancy features to a drill will usually reduce the time it takes to make a hole.

Without having a clear idea of the JTBD your product is hired for, you’re blind to users needs and it’s easy to make these kinds of mistakes.

Who can blame the drilling company for adding such features if they didn’t know that people just hired their company to “make a hole?”

There's also another thing: People often don’t know what solutions (aka features) are possible for their problem.

I once saw a product which used a sensor technology to detect whether you were close to your car (it pairs with your mobile phone to see if you’re nearby) and automatically unlocks it.

This product greatly reduces the time it took to “open a car door”. I could bet you that nobody would give this idea as a feature request if they didn’t know such sensors existed.

You probably have neat software development skills and people don’t always know what’s possible with them, thus limiting the usefulness of features they request.

How to get to the JTBD if people start requesting features: Immediately follow up with "Why" and "What would you e able to accomplish with [the feature]" to get the bigger JTBD story.

It’s Easier Than You Think To Get This Wrong

People often confuse the difference between a situation/job/benefit.

JTBDs aren't usually be based around products, but around situations.

Don’t ask “What job are people hiring my time-tracking software for”, ask “What job are people trying to accomplish when they find their outsource is taking longer than usual to accomplish some job?”

Distinguish between a situation and a job. “Finding that an employee is spending more than usual to accomplish something” is not a job, it’s a context/situation/trigger that potentially causes a need for some JTBD.

A job would be “keep track of an employee's time when she's working on a project” (for which you can later use minimize/increase statements to find out how to do better).

A little quiz: Which of these 2 is a job-to-be-done: a) Have a smooth hair b) Smoothen my hair

a) is a benefit, not a job. It’s an end state, not a process. b) is a job you’re trying to accomplish. That’s why I highly recommend you use the job template I’ve provided above where you start with a specific action verb.

To make sure your job is a real job and not a benefit, ask yourself: Is this an end state or a process that takes time/effort/money? Can I imagine this happening as a process (you can imagine someone smothening their hair as a process, but you can’t do so for “have a smooth hair” because it’s an end state). Another example is “remote control” vs “control remotely”.

What about this: a) Call an applicant’s recommendation vs. b) Validate employment history. Both seem to follow the job-to-be-done format, yet there’s a huge difference between them. The first is a solution-based job (learn why in the next paragraph). The second is a real job.

A good exercise to distinguish between real jobs and solution-based jobs is to remember that** real jobs remain stable over time**. Ask yourself: 50 years ago, would this be a valid job? 50/100 years ago, where phones weren’t used, a) would be an invalid job, while b) would remain valid. To get to a solution-agnostic job, ask “why” for the solution-based one. Why does some person needs to “get advice from a lawyer” (which is a job, but it mentions a potential solution?) Maybe they need to “solve a marriage dispute” or “avoid a tax issue”. Why does a person needs to “file a complaint” with an airline provider? To “obtain a refund”, that is.

How to Further Deconstruct Your Job-To-Be-Done

Once you find the job your product is trying to get done, how will you know how well it is doing it? How are people measuring success of the accomplishment of that job? How are they measuring the actual value of your and your competitor products? This section will answer those questions.

People don’t usually hire your product because they want to do something. They hire it because they want to do something better and/or cheaper. But what is better? To classify something as “better”, it either needs to be:

• Faster (minimize the time it takes to do something)

• More stable (minimize/increase the chance/likelihood/frequency/number of times something happens. In other words, eliminate unpredictability and increase accuracy).

• Provide more output (increase the number/amount of something. In other words, eliminate waste and inefficiency)

These are measurable ways by which you can see how well a specific job is being done. We will use a statement similar to the job-to-be-done template:

The first part is the direction of improvement. Use minimize/increase for this. Research has shown that inconsistent wording (like using reduce instead of minimize) will produce inconsistent results.

People use “minimize” in 90% of the statements usually, and “increase” in 10%.

The second part is the unit of measure, this is the part where you put the type of “better” you want, like the time it takes/likelihood of occurring/amount of something.

The unit of measure is something that can be measured and thus improved (you can’t improve “fast”, but you can the “time it takes to do x”). The rest are context-specific and depend on the market you’re in.

The reason for using a word like “minimize” and not “eliminate” or “prevent” is that “eliminate” implies a value of zero. People may rate as more important to “minimize” the time it takes to find a suitable employee candidate than to “eliminate” it. Thus, the choice of using words that imply increase/decrease rather than eliminate/maximize.

Let’s suppose we’re creating a SEO tracking software and we’ve identified that people want to “track the ranking of a website” and that’s the primary reason why they use it. How do you come up with these minimize/increase statements from this job alone? You can start by asking the customer the following questions:

• What makes tracking rankings time-consuming/slow?

• What makes tracking rankings error prone/ineffective/unpredictable? What causes this job to go off track?

• What (aspects) make tracking rankings wasteful/inefficient?

Other questions you can use are :

• “What makes this difficult/inconvenient/cumbersome/frustrating/challenging/uncomfortable/problematic?”

• What makes tracking rankings costly?

An easy mistake to make: The 4 questions should be focused around the job your product is hired to do, not the product itself. Suppose the job your product does is “manage social media profiles”. Your exact question should be: “What makes managing social media profiles time-consuming”? not “What makes using [our social media management tool] time-consuming?”

After asking these questions, I might come up with the following statements:

• Minimize the time it takes to write what I need to do
• Minimize the likelihood I will add a duplicate task
• Increase the likelihood I will get the noted task done

These are statements by which you can actually measure how useful your features are once you implement them.

Now, people won’t use this minimize/increase wording during the interview. For example, when asking “What makes managing social media accounts time-consuming?”, they may say something like “I don’t like it when I have to spend 10 minutes logging in and checking what’s new in each profile”. After hearing this, you can say: “So you want to minimize the time it takes to check the latest news on your social media profiles?” and if the answer is yes, write that statement down. Or they may say: “I want to make it easy to see all my social media accounts”, to which you can reply: “So, you want to minimize the time it takes to see your social media accounts” and write that down if you get a confirmation answer.

After you get a bunch of these statements, use the same process as with the JTBDs above to identify the opportunity score using the formula and find which outcomes are most unsatisfied by competitors. For example, if the job is “determine if an employee has a criminal record”, the questions you’d ask would be:

• “When determining if an employee has a criminal record, how important is it that you are able to minimize the likelihood of an information being incorrect from a screening provider?”

• “When determining if an employee has a criminal record, how satisfied are you with your ability to minimize the likelihood of an information being incorrect from a screening provider?”

Use 1-5 for rating scales, just like without our job examples above and apply the opportunity score formula.

This process works best on a more complex job. If the primary job your product is accomplishing is to “Find if a competitor said something negative about my company online”, then there’s not much worth in de-constructing it. Still, you can ask questions like “What makes this costly/time-consuming etc.” to get further insights.

Is There Any Research This Kind of Thinking Works?

I recently came upon a book called "Why People (Don’t) Buy: The Go and Stop Signals". The authors are marketing professors who invented a framework based on all current and past research in consumer behavior on why people buy. According to their research, a certain purchase is driven by two categories of brain signals:

• GO signal (feeling, thought, unconscious response) that motivates the person to buy the product

• STOP signal (feeling, thought, unconscious response) that inhibits the person from buying that product

If the GO signals are significantly greater than the STOP signals, then a purchase occurs.

I found this framework remarkable similar to the job-to-be-done concept.

Basically, the first step they do is a situational analysis to determine the circumstances around the person making the purchase. Which triggers are GO and which are STOP signals? Situational analysis will help us more in discovering the GOAL signals while further probing those goals will help us discover the STOP signals.

The format of the statements they provide is a more vague version of the statement format presented here in the JTBDs. The overall point is the same, though. If you encounter a strong “stop” signal (like the time it takes to sign up), you can convert this into an outcome statement “minimize the time it takes to sign up” and work on that directly.

Also, a consulting firm called Strategyn (from which I borrowed the format of the JTBD statements and the minimize/increase wording) did a study on their clients in which they’ve identified that job-based thinking has 86% success rate in new product development compared to the 10%-30% typical success of most new products.

It’s All About What You Focus On

Many UX principles come from market research, and market research principles come from psychology.

Remember user stories? They came from “demographic targeting” in market research which itself came from the principle of personality psychology.

Then situationism appeared, and the whole notion of jobs-to-be-done in market research, and now job stories are gaining popularity.

I’ve seen people often making novice mistakes of confusing between a job and a situation, which caused Alan Klement (the creator of job stories) do an update of his theory. Job stories are great, but without understanding the big picture (what a job is, how to formulate it, what’s the root job why people buy from you) there’s not much use of them.

Here’s a great example of a job story using the template provided in this article (you may notice it’s missing the “so I can” part of a job story which I think is unnecessary if you use the minimize/increase wording):

There’s a principle called selective attention in psychology. Basically, we’re bombarded all the time with all kinds of information about all kinds of things, and we need to choose what we’ll focus on.

You’re bombarded all the time with feature requests/different insights on what customers want/all kinds of info from talking and interviewing your users. If there’s something I hope this article helped accomplish, I hope it was changing your focus, more specifically, changing your focus from listening what features your users want to what jobs are they trying to accomplish. This simple focus change will dramatically alter the way you approach UX design and thus become way better than the way you are now in giving users what they want.

Good luck!

Further case studies

I found that examples are great ways to learn about this whole JTBD approach. Here are some good resources:

• Designing products around customer jobs
• The jobification of weather apps