More than mattresses: using Jobs-to-be-Done research for software

There’s lots of resources for getting started with Jobs-to-be-Done interview techniques.

Yet most of these apply to physical products. If you work in a software company, you might rightly ask how the hell this relates to your product.

You can read up on why a person bought a mattress, but not why they bought a piece of software. These interview techniques will tell you to hone in on the emotional triggers around a particular point in time that led to a person “hiring” or “firing” a product.

After conducting many, many interviews, we’ve found you can still apply the fundamental Jobs-to-be-Done interview techniques while adapting them to better suit the needs of software design.

Here’s how we do that.

Extracting the first thought

One of the first things you’ll notice about Jobs-to-be-Done interviews is an emphasis on “extracting the first thought” from a purchase or switching decision. For a physical product, this is easy – you can deep dive into the mindset and physical setting the customer might have been in during the time of the purchase.

For a mattress, this might involve questions like:

• When did you start to look for another mattress?
• Where were you when you made this decision?
• Were you with anyone at the time?

When it comes to software, it can be tricky to extract the “first-thought”. Asking “Was it raining on the day you signed up for the calendar app?” is unlikely to jog someone’s memory. We’ve learned the first thought can be multidimensional.

Take enterprise software. From a lack of budget, to a change in management, to multiple tools being used for one job, there are many factors why a company might switch to a new product.

These factors can be used in your interviews – involve functional aspects from within a company, along with emotional triggers from that time.

• What tool were you using before you bought [software]? Were you also involved in buying that?
• What was it like working in [department] for [company] back then?
• Can you remember if anyone else was involved in the decision? What was their role in the company at that time?
• Can you remember how well the [old solution] was working? Was it just your department using it?

The four forces

The forces of progress (push, pull, habit, anxiety) are a way of understanding how people buy products.

In our mattress scenario, the forces could relate to:

• The push of what is happening currently: “This mattress is pretty uncomfortable. I’m waking up multiple times in the night with back pain.”
• The pull of a new solution: “If I get a new mattress, I can sleep better. I’ll be in a better mood at home and at work.”
• The anxiety of what could happen: “What if the new mattress turns out to be just as bad as the old one? I can only try it out for a few moments in the store.”
• The attachment to what you currently have: “I’ve had this mattress since college.”

The reasons for buying software can lean more towards business goals such as increasing engagement or revenue rather than personal goals like increasing your overall happiness (however, if the software is designed well, it will do both). You could argue for software, the purchase decision can be influenced by multiple previous purchases rather than just the push factors of the current tool. In a software scenario, the forces can be:

• The push of what is happening currently: “We’re not converting users at a rate that we’d like. We can’t afford to keep paying so much per month for this tool.”
• The pull of a new solution: “If we switch to a new tool that has more features around conversion, we can start hitting our targets.”
• The anxiety of what could happen: “What if the new tool doesn’t integrate as well as we’d like? We’ve tried three other tools for this job and none have been good enough.”
• The attachment to what you currently have: “We’ve got workflows and integrations set-up and it’d be a pain to get them set up again.”

Building a consideration set

The consideration set involves the time in which a person (or company) is looking at all the possible solutions for a job they want to fulfill through a product. It’s during this time “active” or “passive” looking takes place. Active looking usually stems from a moment of particular frustration the person has been through with the product. Passive looking can be ongoing for weeks/months while the person is uncertain if the product is doing its job well enough.

For software businesses, asking questions around the consideration set can help you uncover if there were situations where multiple people affected the purchasing decision:

• Once you figured out you wanted to buy a new solution, did you do much research to figure out which tool was right for your company? Were you the only one who was looking for something else at that time?
• Where did you first hear about the tool you picked?
• Can you recall how you came to purchase the specific tool you did?
• When you were looking around, did you (or anyone else) try out any other tools? What were they?
• How long did you look around before you clicked “buy” on the [tool’s] website?

The timeline

Creating a timeline of events helps bring the interviewee back through the journey of what brought them to purchase a product. We’ve discovered for software purchases, there are often multiple timelines at work.

In the past, we’ve started interviews with the objective of uncovering why a company switched from Tool A > Tool B. We actually ended up with two timelines; one relating to why a company moved from Tool A > Tool B and then from Tool B > Tool C.

Once again, this is down to there being numerous people involved in the decision for buying software. You’re really looking for the right people to talk to, the main decision maker. There’s so many times you’ll hear: “I wasn’t at [company] when we bought [tool] but I’m the main person who uses it!”.

It’s like interviewing a parent who bought a mattress for their child. Talking to the child to understand how the mattress is working out now is useful information, but really you want to talk to the parent about why they bought the mattress in the first place. Unearthing who the main decision maker behind buying software by asking questions like:

• What year did [company] move to [product]? Were you there at that point?
  • Who decided to make that move? Are they still at the company now? What role are they in?

Knowing who the other decision makers are will give you a broader picture where you need to innovate, and how you can support jobs your product is getting dropped for.

There’s more than mattresses

Jobs-to-be-Done can be great for understanding why companies hire and fire products, and unearthing areas where you can innovate with your product. But remember what works for physical products does not directly translate to software products. Purchases are multi-dimensional, have multiple buyers involved, and are spread across multiple timelines. By adjusting the interview techniques to your own needs, you’ll have a framework that can be applied to any modern software company.

---

Our fourth book, Intercom on Jobs-to-be-Done, is a collection of our best thoughts and ideas on the topic. Get your copy today.