I dismissed Jobs to be Done.

I couldn't see how to use it. I couldn't see what it added to a solid generative interview. The buzz annoyed me, and the method sat far outside my comfort zone.

Then someone reintroduced me to the idea, and I caught myself being stubborn. A researcher who refuses to learn is a bad researcher. So I bought two books: Jobs to be Done by Tony Ulwick and Competing Against Luck by Clayton Christensen. I devoured both in a single weekend. I came out a convert, itching to run interviews on Monday.

Here's why you should care. If you're building an AI product, your users can leave you in thirty seconds. A new model drops, a sharper wrapper launches, and your churn curve bends the wrong way. Features won't save you. Knowing why people hire you will.

Ask five researchers and you'll get five answers. Some call JTBD a well-branded repackaging of task analysis. Others call it a fresh way to read how users decide. I'll skip the fight and give you the version I use.

Users have something they're trying to get done. They "hire" products and services to make progress toward it.

Everyone wants to be better than they are right now. We chase goals that pull us toward our ideal selves. We buy a product when today's reality doesn't match the future we want. We switch products when our current one stops moving us forward.

Start the way you'd start any generative session. Block 60 to 90 minutes. Give yourself room, because these conversations take time to warm up, especially if the technique is new to you.

Recruit differently, though. I screen for three groups:
- People who just started using your product
- People who just stopped using your product
- People who haven't used your product yet

Each group answers a different question:
- Why do people switch to you?
- Why do people switch away from you?
- What are non-users trying to accomplish, and how do they do it today?
- What pushes and pulls people toward you, or toward a competitor?

Switching behavior is the whole game. You're hunting for the moment someone said, "I need something better."

This is also where JTBD gets hard. You can't just ask, "Why did you switch?" You'll get a tidy, surface-level answer and miss the goal driving the behavior.

Let me show you with my own switch.

I recently moved my entire working life from Notion to Obsidian. The migration hurt. First, I had to export and untangle two thousand pages, and half the formatting broke. Second, I lost weeks rebuilding templates, plugins, and automations. Third, I burned a lot of time testing setups until one actually held up.

Ask me why I did it, and I'll tell you: "Speed, and I want my notes offline." That's true. It's also shallow.

Dig deeper and you'll find the real story. A sync failure once wiped a client brief an hour before a call, and I fumbled through it in front of them. I was embarrassed. I tell clients to own their data and keep their systems portable, yet I stored my own thinking inside someone else's walled garden. That gap nagged me for over a year. I wanted to be the person who practices what he preaches. The cognitive dissonance finally pushed me over the edge.

But if you asked me point blank, I'd never lead with that.

So don't ask point blank. Get users to tell you stories about why they decided to act. You still probe, as you would in generative research, but you probe in a specific way.

My scripts stay bare-bones. I bring a handful of high-level questions and let the participant steer. I chase the switch event, the moment that triggered the change.

I always ask these:
- What other solutions did you consider before trying this product?
- What were you hoping to find in those solutions?
- What problem were you trying to solve?
- Walk me through how you searched.
- Which other solutions have you actually used?
- What did you like and dislike about them?
- If this product didn't exist, what would you do instead?
- What have the people around you tried?
- What do you do now compared to before?

Memory runs on association. People recall stories through places, people, sounds, and smells. So I ask: What time of day was it? Were you at home or at work? Was the TV on? Who was with you? Those details drop people back into the moment, and the feelings come with them.

Once I know the competitors and the shape of the switch, I go for the emotional layer:
- When did you first realize you needed to fix this?
- Did you talk to anyone about your options?
- What was that conversation like?
- Did anyone recommend something?
- What did you imagine using it would feel like?
- What did you want from it?
- Did anything make you anxious or nervous about buying or using it?

As you listen, track four forces:
- Push of the situation: What in their circumstances forced them to look for something new?
- Pull of the new solution: What about it made them want to try it?
- Habits holding them back: Which routines kept them stuck?
- Anxieties about the new solution: What worried them about switching?

This takes practice. Rehearse with teammates or friends before you put real users in the hot seat.

JTBD gave me a new lens on user research and a new way to help companies win. It isn't a magic potion. It's a descriptive theory. It tells you what's happening, not what to build, so you still have to translate insight into product decisions. That translation is where the value lives.

It's also tricky to master. People often don't know why they did what they did, and they can't analyze themselves without bias. Your job is to pull the real story out of them.

When you do, you stop guessing. You build features that speak directly to the progress your users want. You help them become the people they're trying to be. In a market where switching costs nothing, that's the only moat that lasts.

If you want this applied to your product, [Mayur Maheshwari / mayur@studioaccorde.com]. Let's talk about the job your users are really hiring you for.