You built the feature. It works. You even wrote a decent onboarding flow. Three weeks later, the usage chart is flat and you are staring at it wondering what you missed.
You probably did not get the code wrong. You got the reason wrong.
That is the problem jobs-to-be-done is good at. It helps you understand why someone changes what they do, not what they say they like in a polite conversation. For a technical founder, that matters because your instincts are usually strongest around the product and weakest around the messy moment before a person decides to switch.
A jobs-to-be-done interview gives you a structure. You are not making small talk and hoping insight appears. You are reconstructing a real decision step by step, like reading a stack trace backwards until you find where the behaviour actually changed.
Use this guide when you want to understand why people adopted you, why they chose a competitor, why they churned, or why they kept using a spreadsheet even after they agreed your product was “better”.
What jobs-to-be-done means
The core idea is simple: people do not buy products because they match a persona. They use products to make progress in a specific situation.
Harvard Business Review’s canonical article by Clayton Christensen and co-authors describes this as customers “hiring” a product to do a job. If the product helps, they keep hiring it. If it does not, they fire it and look for something else.
That framing changes the research question. You are not asking, “What does our ICP want?” You are asking:
- What was happening when this person started looking?
- What made the old way no longer good enough?
- What did they hope would be different?
- What almost stopped them?
- What did they have to give up?
The famous milkshake example makes this concrete. The Re-Wired Group’s guide describes researchers watching morning milkshake buyers and learning that the product was not competing only with other milkshakes. For one group, it was hired for a long commute: it was filling, lasted a while, and could be handled with one hand. The job was not “buy a drink”. It was closer to “make this boring drive bearable and arrive not hungry”.
Your SaaS product has the same hidden context. A founder switching billing tools is not just moving invoices. They may be trying to stop dreading month-end, stop looking unprepared in front of finance, or stop relying on one person who remembers how the spreadsheet works.
That is why Nielsen Norman Group frames jobs-to-be-done as a way to represent user needs born from qualitative research. A job has a functional layer, but it also has emotional and social layers: what the person is trying to do, how they want to feel, and how they want to be seen.
The version of JTBD to use first
There are multiple schools of jobs-to-be-done. The distinction matters less than practitioners sometimes make it sound, but one version is more useful for a founder who needs better interviews this week.
The first school treats the job as an activity or process. Tony Ulwick’s Outcome-Driven Innovation work breaks a job into steps and desired outcomes so teams can measure where a market is underserved. That can be valuable when you already know the domain and need a rigorous product strategy process.
The second school focuses on progress and switching. It asks why a person changed from one way of doing things to another: what pushed them away from the old solution, what pulled them toward the new one, what made them anxious, and what habit held them back.
Start with the switch version. It gives you a practical interview format, works well for B2B SaaS adoption and churn, and keeps you anchored in a decision that actually happened.
The switch interview
A switch interview is a conversation with someone who recently changed something.
They might have:
- signed up for your product;
- upgraded from a free plan;
- switched from a competitor;
- churned from you;
- evaluated you and decided not to buy;
- stayed with a spreadsheet, Slack thread, agency, or internal workaround.
The key word is recently. You want the decision while the texture is still available: the trigger, the meeting, the awkward workaround, the colleague who objected, the point when the old way became too painful. Thirty to sixty days is a useful target for SaaS. Older decisions can still work, but expect more summaries and fewer scenes.
The job of the interview is to walk backwards through the decision. Bob Moesta and Chris Spiek’s JTBD material calls out the timeline: first thought, passive looking, active looking, purchase, and first use. You are trying to reconstruct that path in the participant’s own words.
Do not begin with your product. Begin with the moment their current way of working started to wobble.
The four forces
Every switch is a tug-of-war. The jobstobedone.org guide names four forces:
- Push: the frustration with the current situation.
- Pull: the promise of the new solution.
- Anxiety: the fear that the new choice will not work.
- Habit: the comfort and familiarity of the old way.
Push and pull move someone toward change. Anxiety and habit hold them back.
This is useful because it stops you treating adoption as a single lever. “Make the product better” increases pull, but that is not always the issue. Sometimes people do not switch because migration feels risky. Sometimes the old spreadsheet is bad but known. Sometimes the buyer likes the demo but does not want to spend political capital changing a workflow other teams depend on.
Analytics can show that someone did not adopt. A switch interview can show whether the blocker was weak pull, strong anxiety, or a habit you never acknowledged.
The eight things you are listening for
The Re-Wired Group describes a well-understood job through eight elements:
- the context around the decision;
- the struggling moment;
- the pushes and pulls;
- the anxieties and habits;
- the desired outcome;
- the hiring and firing criteria;
- the trade-offs the person accepts;
- the basic quality the solution must never violate.
You do not need to turn these into a heavy research template. Use them as a listening checklist.
The most important element is the struggling moment: the point when the current way stopped feeling acceptable. If you can describe that moment in your customer’s own words, you will usually understand more than a feature-request backlog can tell you.
For example:
- “Our biggest customer asked for usage data and it took two days to assemble.”
- “The finance lead stopped trusting the invoice export.”
- “Support kept promising customers the same workaround.”
- “The founder was still the only person who knew how renewal risk was tracked.”
Those are buildable moments. “We need better reporting” is not.
Jobs-to-be-done interview questions
Use this structure for a 30-minute switch interview. Keep the order, but change the wording to fit your product.
1. Open with the real decision
Start broad, then anchor fast:
Take me back to when you first started looking for a better way to [do X]. What was going on?
Follow with:
- When was this?
- Where were you?
- Who else was involved?
- What had just happened?
- What made this worth paying attention to then?
You are looking for a scene, not a summary.
2. Find the first thought
Ask:
- When did you first think the old way might not be good enough?
- What triggered that thought?
- Did you do anything immediately, or did it sit in the background?
- Who did you mention it to first?
Most switches begin quietly. The first thought often happens weeks before the visible buying process.
3. Trace the old solution
Before you discuss the new product, understand what it replaced.
Ask:
- How were you handling this before?
- What worked about that?
- What was annoying, risky, or slow?
- What did you have to keep checking manually?
- What would happen if nobody fixed it?
Do not treat the old solution as irrational. If it survived, it was doing some job.
4. Reconstruct the search
Ask:
- What did you look at first?
- What did you rule out quickly?
- What nearly won?
- What did you compare us with?
- What non-software option did you consider?
In B2B SaaS, the competitor is often not another vendor. It is doing nothing, asking an operations person to own it, hiring an agency, or keeping the current ritual alive.
5. Surface anxiety
Ask:
- What almost stopped you?
- What felt risky?
- What did you need to trust before moving forward?
- Who could have blocked the decision?
- What would have made you look bad if it failed?
This is where founders learn why a product that looks better still loses. The participant may like the outcome and still fear migration, data quality, team adoption, procurement, or internal credibility loss.
6. Name the habit
Ask:
- What did you have to give up?
- What do you miss about the old way?
- What was easier before?
- What did the team keep doing out of habit?
Even bad workflows have benefits. They are familiar. They are owned by someone. They have shortcuts. If you do not understand the habit, your onboarding will feel like a lecture from someone who never had to do the work.
7. Get the desired outcome in their words
Ask:
- How did you know the switch was working?
- What changed in a good week?
- What stopped happening?
- What did you feel more confident about?
- What did you tell the team when you explained the decision?
These answers often become your best positioning because they come from the customer’s real progress, not your internal feature language.
Questions to avoid
Some questions make JTBD interviews weaker because they invite opinions, hypotheticals, or politeness.
| Avoid | Ask instead |
|---|---|
| “Would you use this?” | “When did you last run into this problem?” |
| “Would you pay for this?” | “What are you already spending, risking, or working around?” |
| “What features do you want?” | “What were you trying to get done when the current tool fell short?” |
| “Do you like our product?” | “What made you choose it at that point?” |
| “How often do you usually do this?” | “Walk me through the last time it happened.” |
| “Who is our ideal customer?” | “Who felt the pain strongly enough to push for change?” |
Teresa Torres’s story-based interviewing guidance makes the same point: general questions produce summaries, while specific past instances reveal context. “Tell me about the last time” is more useful than “what do you usually do” because it keeps the participant inside a real event.
Two habits that keep the interview honest
Do not defend the product. The moment you explain why a criticism is wrong, you stop learning. The participant will become kinder, vaguer, and less useful. Write down the objection. Fix it later.
Do not accept vague words. When someone says they wanted something “reliable”, “simple”, “flexible”, or “more automated”, ask what that meant in the moment.
Try:
- “What did reliable mean in that situation?”
- “Tell me about a time the old tool was not reliable.”
- “What would you have seen if it had worked properly?”
- “Who noticed when it failed?”
The word is the label. The story underneath is the evidence.
If you can, have a second person listen or review the recording. The Re-Wired Group recommends not interviewing alone because it is easy to hear the thing you hoped to hear. For a small team, that second person can be a co-founder, early employee, or adviser who is willing to challenge your interpretation.
How many interviews you need
Do not pretend this is a survey. You are not trying to estimate a population average. You are looking for repeated causal patterns in a set of recent decisions.
Moesta’s Re-Wired guide frames sample size as practitioner judgement: with varied participants, core jobs can emerge from a small number of interviews, often around ten; newer interviewers may want more. Treat that as experience-based guidance, not a statistical law.
For a technical founder, a practical first batch is:
- 4 customers who recently adopted;
- 3 customers or trials who chose something else;
- 3 customers who churned or stopped using the feature.
That mix lets you hear push, pull, anxiety, and habit from different sides of the same market. If all ten stories point to the same struggling moment, you have a real thread. If every story is different, your segment is probably too broad or your product is being hired for multiple jobs.
Turning interviews into product decisions
After each interview, write a one-page summary with five sections:
- Situation: what was happening when the struggle appeared.
- Old way: what they used before and why it survived.
- Forces: push, pull, anxiety, and habit.
- Outcome: what progress they wanted.
- Product implication: what this should change in positioning, onboarding, roadmap, or sales.
Then convert the strongest pattern into a Job Story. Intercom’s format is useful because it is short enough to survive inside a product team:
When [situation], I want to [motivation], so I can [outcome].
A weak version sounds like a feature request:
When I use billing, I want automated invoices, so I can save time.
A stronger version comes from the interview:
When month-end closes and I am checking usage in three places, I want invoices to generate from trusted product data, so I can send them without worrying finance will find a mistake.
That sentence gives engineering, design, and marketing something real to work with. It names the situation, the motivation, and the emotional outcome.
Where Maren fits
Maren is useful when you know the segment and need more honest, structured conversations than you can run yourself.
You still choose who to talk to. You still decide which switch you care about. You still interpret the evidence. But Maren can run asynchronous conversations, keep people anchored in specific moments, ask neutral follow-ups, and synthesise the themes across many interviews without putting the founder’s hope in the room.
For high-stakes or complex enterprise decisions, run some live interviews yourself too. Watch the hesitation. Hear the internal politics. Then use Maren to broaden the pattern across more recent switchers, churned users, and non-buyers.
The goal is not to outsource judgement. It is to stop making product decisions from polite guesses.
Run one this week
Pick five recent switchers. Ask about one real decision. Walk backwards from purchase to first thought. Listen for push, pull, anxiety, and habit. Unpack every vague word. Do not defend the product.
At the end, you should be able to finish this sentence:
People hire us when [situation] because they need to [make this progress], but they hesitate because [anxiety or habit].
If you cannot finish it yet, keep talking to people.
The best output of a jobs-to-be-done interview is not a bigger backlog. It is a clearer reason to build, a sharper reason to say no, and the customer’s own language for the progress they are trying to make.